Benchmark (for assemblers and compilers)

[jj2007]

Thanks, Timo. How do you build it (I get an error "POLINK: error: Unresolved external symbol '_DSVRead'")?

[TimoVJL]

compile DSVRead_Test1.c and DSVRead.c and link those object files.
msvcrt_main.c is optional, just to avoid crt.

[jj2007]

OK, it works now, thanks :icon14:

[TimoVJL]

And the winners of this silly test are msvc and Clang.

Code Select Expand

DSVRead_Test1msvcX64.exe
DSVRead: 103ms
Rows: 43654 Cols: 248
116ms
234 matches 171 values, average 15.996

DSVRead_Test1Clang8_64.exe
DSVRead: 104ms
Rows: 43654 Cols: 248
117ms
234 matches 171 values, average 15.996
We need a test processing UTF-8 strings in loops.

[jj2007]

And the winners of this silly test are msvc and Clang

Yes indeed:

Code Select Expand

Core i5
msvcX64
C compiler: Microsoft Visual C/C++ Version: 1916 Toolset: 191627026
DSVRead: 61ms
68ms

Clang8_64
DSVRead: 62ms
69ms

PellesC
C compiler: Pelles, Version 900
DSVRead: 68ms
74ms

msvcX32
C compiler: Microsoft Visual C/C++ Version: 1916 Toolset: 191627026
DSVRead: 76ms
82ms

gcc8X64
C compiler: MingW64 6.0
DSVRead: 74ms
83ms

pcc32
C compiler: Microsoft Visual C/C++ Version: 600
DSVRead: 79ms
85ms

Gcc32
DSVRead: 84ms
93ms

We need a test processing UTF-8 strings in loops.

This is a test processing UTF-8 strings in loops... 8)

[TimoVJL]

We need a test processing UTF-8 strings in loops.

This is a test processing UTF-8 strings in loops... 8)

something like case insensitive searches, a speed killer.

[hutch--]

Depends how you do it, a table set up to handle both cases is one way, the other is to convert the string to a single case then do a normal search.

[jj2007]

Count how many lines contain the word "family", case-insensitive? There is one line that contains family 2x, therefore the line count is 1480 but the Count() on the full content is 1481.

[TimoVJL]

A small test with words "internet users":

Code Select Expand

int WINAPI StrCmpW(WCHAR *psz1, WCHAR *psz2);
#pragma comment(lib, "user32.lib")
#pragma comment(lib, "shlwapi.lib");
int StrCmpUTF8(char *szStr, WCHAR *szStr2)
{
WCHAR wczStr[1024];
int nLen = MultiByteToWideChar(CP_UTF8, 0, szStr, -1, wczStr, sizeof(wczStr)/sizeof(WCHAR));
CharLowerBuffW(wczStr, nLen);
return StrCmpW(szStr2, wczStr);
}
result

Code Select Expand

C compiler: Pelles C, Version 800
DSVRead: 129ms
Rows: 43654 Cols: 248
process: 61ms total: 190ms
234 matches

Code Select Expand

int StrCmpIUTF8(char *szStr, WCHAR *szStr2)
{
WCHAR wczStr[1024];
MultiByteToWideChar(CP_UTF8, 0, szStr, -1, wczStr, sizeof(wczStr)/sizeof(WCHAR));
return StrCmpIW(szStr2, wczStr);
}

Code Select Expand

C compiler: Pelles C, Version 800
DSVRead: 121ms
Rows: 43654 Cols: 248
process: 33ms total: 154ms
234 matches

[jj2007]

Good :t

Here is a Utf8 text file for download which I will remove later on. Grab it...

Code Select Expand

  NanoTimer()
  Let esi=FileRead$("Chinese.txt")
  PrintLine NanoTimer$(),  Str$(" for %i occurrences of '神 說'", Count(esi, "神 說", LastFileSize))

Code Select Expand

2944 µs for 76 occurrences of '神 說'

[TimoVJL]

with chinese.txt

Code Select Expand

TestLoadFileChClang8_64.exe
load: 5ms
process: 10ms, found 76
total: 15ms

TestLoadFileChmsvcX64.exe
load: 5ms
process: 16ms, found 76
total: 21ms

[jj2007]

Pretty big differences, astonishing.

Code Select Expand

TestLoadFileChClang8_64.exe
load: 7ms
process: 14ms, found 76
total: 24ms

TestLoadFileChmsvcX64.exe
load: 2ms
process: 8ms, found 76
total: 12ms

TestLoadFileChpocc8.exe
load: 2ms
process: 12ms, found 76
total: 16ms

TestLoadFileChpocc9.exe
load: 2ms
process: 10ms, found 76
total: 14ms

TestLoadFileChpocc864.exe
load: 2ms
process: 8ms, found 76
total: 11ms

TestLoadFileChpocc964.exe
load: 2ms
process: 8ms, found 76
total: 12ms

[TimoVJL]

Yes, a pointless test.
The winner was gcc 8.2 x64

Code Select Expand

load: 5ms
process: 5ms, found 76
total: 11ms

Code Select Expand

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#ifdef USE_MALLOC
#include <stdlib.h>
#endif
#pragma comment(lib, "kernel32.lib")

int __cdecl main(int argc, char **argv)
{
LONGLONG freq, t1, t2, t3;
HANDLE hFile;
QueryPerformanceFrequency((LARGE_INTEGER *) & freq);
QueryPerformanceCounter((LARGE_INTEGER*)&t1);
if ((hFile = CreateFile("chinese.txt", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL)) == INVALID_HANDLE_VALUE)
return 1;
DWORD nRead, nMax;
nMax = GetFileSize(hFile, NULL);
#ifdef USE_MALLOC
char *pFile = malloc(nMax + 1); // malloc buffer
*(pFile + nMax) = 0; // EOF marker
#else
HANDLE hHeap = GetProcessHeap();
char *pFile = HeapAlloc(hHeap, HEAP_ZERO_MEMORY, nMax + 1);
#endif
ReadFile(hFile, pFile, nMax, &nRead, NULL);
CloseHandle(hFile);
if (nRead != nMax) return 2;
QueryPerformanceCounter((LARGE_INTEGER*)&t2);
char *pc = pFile;
char *pKey = u8"神 說";
int nFound = 0;
char *pcs = pKey;
while(*pc) {
while(*pc) {
if (*pc++ != *pcs) {
if (!*pcs) // end of search string
nFound++;
pcs = pKey; // reset search
break;
} else pcs++;
}
}
QueryPerformanceCounter((LARGE_INTEGER*)&t3);
printf("load: %dms\n", (int)((t2-t1) * 1000 / freq));
printf("process: %dms, found %d\n", (int)((t3-t2) * 1000 / freq), nFound);
printf("total: %dms\n", (int)((t3-t1) * 1000 / freq));
return 0;
}


[jj2007]

Yes, a pointless test.

Because UTF8 behaves exactly like plain ANSI: a sequence of bytes. On my machine, gcc8_64 wins this test (attention, some return "found 0"):

Code Select Expand

TestLoadFileChClang8_64.exe
load: 2ms
process: 7ms, found 76
total: 9ms

TestLoadFileChmsvc.exe
load: 2ms
process: 8ms, found 0
total: 10ms

TestLoadFileChmsvcX64.exe
load: 2ms
process: 7ms, found 0
total: 10ms

TestLoadFileChgcc8X64.exe
load: 2ms
process: 4ms, found 76
total: 7ms

DSVRead_Test1gcc8_64.exe
load: 2ms
process: 4ms, found 76
total: 7ms

TestLoadFileChpocc8.exe
load: 2ms
process: 6ms, found 0
total: 8ms

TestLoadFileChpocc9.exe
load: 2ms
process: 10ms, found 0
total: 13ms

TestLoadFileChpocc864.exe
load: 3ms
process: 6ms, found 0
total: 9ms

TestLoadFileChpocc964.exe
load: 2ms
process: 7ms, found 0
total: 10ms

Which is still over a factor 2 slower than assembly, though ;)

[TimoVJL]

Reason for that was a missing UTF-8 BOM from source file, so compilers handle differently source file without it.
Test files updated.

msvc have an option /utf-8 for bypassing that.

Which is still over a factor 2 slower than assembly, though ;)

Good for you  ;)