abouchez / mormot: new -c option, new rouding method and README enhancements

entries/abouchez/README.md

@@ -22,35 +22,40 @@ Here are the main ideas behind this implementation proposal:
 
 - **mORMot** makes cross-platform and cross-compiler support simple - e.g. `TMemMap`, `TDynArray`,`TTextWriter`, `SetThreadCpuAffinity`, `crc32c`, `ConsoleWrite` or command-line parsing;
 - The entire 16GB file is `memmap`ed at once into memory - it won't work on 32-bit OS, but avoid any `read` syscall or memory copy;
-- Process file in parallel using several threads - configurable via the `-t=` switch, default being the total number of CPUs reported by the OS;
-- Input is fed into each thread as 64MB chunks: because thread scheduling is unbalanced, it is inefficient to pre-divide the size of the whole input file into the number of threads;
+- File is processed in parallel using several threads - configurable via the `-t=` switch, default being the total number of CPUs reported by the OS;
+- Input is fed into each thread as 4MB chunks (see also the `-c` command line switch): because thread scheduling is unbalanced, it is inefficient to pre-divide the size of the whole input file into the number of threads;
 - Each thread manages its own `Station[]` data, so there is no lock until the thread is finished and data is consolidated;
 - Each `Station[]` information is packed into a record of exactly 16 bytes, with no external pointer/string, to leverage the CPU L1 cache size (64 bytes) for efficiency;
-- Maintain a `StationHash[]` hash table for the name lookup, with crc32c perfect hash function - no name comparison nor storage is needed with a perfect hash (see below);
-- On Intel/AMD/AARCH64 CPUs, *mORMot* uses hardware SSE4.2 opcodes for this crc32c computation;
-- Store values as 16-bit or 32-bit integers, as temperature multiplied by 10;
-- Parse temperatures with a dedicated code (expects single decimal input values);
+- A O(1) hash table is maintained for the name lookup, with crc32c perfect hash function - no name comparison nor storage is needed with a perfect hash (see below);
+- On Intel/AMD/AARCH64 CPUs, *mORMot* offers hardware SSE4.2 opcodes for this crc32c computation;
+- The hash table does not directly store the `Station[]` data, but use a separated `StationHash[]` lookup array of 16-bit indexes (as our `TDynArray` does) to leverage the CPU caches;
+- Values are stored as 16-bit or 32-bit integers, as temperature multiplied by 10;
+- Temperatures are parsed with a dedicated code (expects single decimal input values);
 - The station names are stored as UTF-8 pointers to the memmap location where they appear first, in `StationName[]`, to be emitted eventually for the final output, not during temperature parsing;
 - No memory allocation (e.g. no transient `string` or `TBytes`) nor any syscall is done during the parsing process to reduce contention and ensure the process is only CPU-bound and RAM-bound (we checked this with `strace` on Linux);
 - Pascal code was tuned to generate the best possible asm output on FPC x86_64 (which is our target) - perhaps making it less readable, because we used pointer arithmetics when it matters (I like to think as such low-level pascal code as [portable assembly](https://sqlite.org/whyc.html#performance) similar to "unsafe" code in managed languages);
-- Can optionally output timing statistics and resultset hash value on the console to debug and refine settings (with the `-v` command line switch);
-- Can optionally set each thread affinity to a single core (with the `-a` command line switch).
+- It can optionally output timing statistics and resultset hash value on the console to debug and refine settings (with the `-v` command line switch);
+- It can optionally set each thread affinity to a single core (with the `-a` command line switch).
 
 If you are not convinced by the "perfect hash" trick, you can define the `NOPERFECTHASH` conditional, which forces full name comparison, but is noticeably slower. Our algorithm is safe with the official dataset, and gives the expected final result - which was the goal of this challenge: compute the right data reduction with as little time as possible, with all possible hacks and tricks. A "perfect hash" is a well known hacking pattern, when the dataset is validated in advance. And since our CPUs offers `crc32c` which is perfect for our dataset... let's use it! https://en.wikipedia.org/wiki/Perfect_hash_function ;)
 
 ## Why L1 Cache Matters
 
-Taking special care of the "64 bytes cache line" is quite unique among all implementations of the "1brc" I have seen in any language - and it does make a noticeable difference in performance.
+Taking special care of the "64 bytes cache line" does make a noticeable difference in performance. Even the fastest Java implementations of the 1brc challenge try to regroup the data in memory.
 
 The L1 cache is well known in the performance hacking litterature to be the main bottleneck for any efficient in-memory process. If you want things to go fast, you should flatter your CPU L1 cache.
 
-Min/max values will be reduced as 16-bit smallint - resulting in temperature range of -3276.7..+3276.8 which seems fair on our planet according to the IPCC. ;)
+Min/max values have been reduced as 16-bit `smallint` - resulting in temperature range of -3276.7..+3276.8 which seems fair on our planet according to the IPCC. ;)
 
 As a result, each `Station[]` entry takes only 16 bytes, so we can fit exactly 4 entries in a single CPU L1 cache line. To be fair, if we put some more data into the record (e.g. use `Int64` instead of `smallint`/`integer`), the performance degrades only for a few percents. The main fact seems to be that the entry is likely to fit into a single cache line, even if filling two cache lines may be sometimes needed for misaligned data.
 
 In our first attempt (see "Old Version" below), we stored the name into the `Station[]` array, so that each entry is 64 bytes long exactly. But since `crc32c` is a perfect hash function for our dataset, it is enough to just store the 32-bit hash instead, and not the actual name.
 
-Note that if we reduce the number of stations from 41343 to 400, the performance is much higher, also with a 16GB file as input. The reason is that since 400x16 = 6400, each dataset could fit entirely in each core L1 cache. No slower L2/L3 cache is involved, therefore performance is better. The cache memory seems to be the bottleneck of our code. Which is a good sign.
+We tried to remove the `StationHash[]` array of `word` lookup table. It made one data read less, but performed almost three times slower. Data locality and cache pollution prevails on absolute number of memory reads. It is faster to access twice the memory, if this memory could remain in the CPU caches. Only profiling and timing would show this. The shortest code is not the fastest with modern CPUs.
+
+Note that if we reduce the number of stations from 41343 to 400 (as other languages 1brc projects do), the performance is much higher, also with a 16GB file as input. My guess is that since 400x16 = 6400, each dataset could fit entirely in each core L1 cache. No slower L2/L3 cache is involved, therefore performance is better.
+
+The cache memory seems to be the bottleneck of our code. Which is a good sign, even if it may be difficult to make it any faster. But who knows?
 
 ## Usage
 
@@ -70,8 +75,10 @@ Options:
   -h, --help          display this help
 
 Params:
-  -t, --threads <number> (default 16)
+  -t, --threads <number> (default 20)
                       number of threads to run
+  -c, --chunk <megabytes> (default 4)
+                      size in megabytes used for per-thread chunking
 ```
 We will use these command-line switches for local (dev PC), and benchmark (challenge HW) analysis.
 
@@ -110,14 +117,14 @@ This is the expected behavior, and will be fine with the benchmark challenge, wh
 
 On my Intel 13h gen processor with E-cores and P-cores, forcing thread to core affinity does not make any huge difference (we are within the error margin):
 ```
-ab@dev:~/dev/github/1brc-ObjectPascal/bin$ ./abouchez measurements.txt -t=10 -v
-Processing measurements.txt with 20 threads and affinity=false
-result hash=8A6B746A,, result length=1139418, stations count=41343, valid utf8=1
+ab@dev:~/dev/github/1brc-ObjectPascal/bin$ ./abouchez measurements.txt -v
+Processing measurements.txt with 20 threads, chunkmb=4 and affinity=false
+result hash=85614446, result length=1139418, stations count=41343, valid utf8=1
 done in 2.36s 6.6 GB/s
 
-ab@dev:~/dev/github/1brc-ObjectPascal/bin$ ./abouchez measurements.txt -t=10 -v -a
-Processing measurements.txt with 20 threads and affinity=true
-result hash=8A6B746A, result length=1139418, stations count=41343, valid utf8=1
+ab@dev:~/dev/github/1brc-ObjectPascal/bin$ ./abouchez measurements.txt -v -a
+Processing measurements.txt with 20 threads, chunkmb=4 and affinity=true
+result hash=85614446, result length=1139418, stations count=41343, valid utf8=1
 done in 2.44s 6.4 GB/s
 ```
 Affinity may help on Ryzen 9, because its Zen 3 architecture is made of identical 16 cores with 32 threads, not this Intel E/P cores mess. But we will validate that on real hardware - no premature guess!

entries/abouchez/src/brcmormot.lpr

@@ -47,13 +47,13 @@   TBrcMain = class
     fEvent: TSynEvent;
     fRunning, fMax: integer;
     fCurrentChunk: PByteArray;
-    fCurrentRemain: PtrUInt;
+    fCurrentRemain, fChunkSize: PtrUInt;
     fList: TBrcList;
     fMem: TMemoryMap;
     procedure Aggregate(const another: TBrcList);
     function GetChunk(out start, stop: PByteArray): boolean;
   public
-    constructor Create(const fn: TFileName; threads, max: integer;
+    constructor Create(const fn: TFileName; threads, chunkmb, max: integer;
       affinity: boolean);
     destructor Destroy; override;
     procedure WaitFor;
@@ -183,7 +183,7 @@ procedure TBrcThread.Execute;
 
 { TBrcMain }
 
-constructor TBrcMain.Create(const fn: TFileName; threads, max: integer;
+constructor TBrcMain.Create(const fn: TFileName; threads, chunkmb, max: integer;
   affinity: boolean);
 var
   i, cores, core: integer;
@@ -193,6 +193,7 @@ constructor TBrcMain.Create(const fn: TFileName; threads, max: integer;
   if not fMem.Map(fn) then
     raise ESynException.CreateUtf8('Impossible to find %', [fn]);
   fMax := max;
+  fChunkSize := chunkmb shl 20;
   fList.Init(fMax);
   fCurrentChunk := pointer(fMem.Buffer);
   fCurrentRemain := fMem.Size;
@@ -217,11 +218,6 @@ destructor TBrcMain.Destroy;
   fEvent.Free;
 end;
 
-const
-  CHUNKSIZE = 64 shl 20; // fed each TBrcThread with 64MB chunks
-  // it is faster than naive parallel process of size / threads input because
-  // OS thread scheduling is never fair so some threads will finish sooner
-
 function TBrcMain.GetChunk(out start, stop: PByteArray): boolean;
 var
   chunk: PtrUInt;
@@ -232,9 +228,9 @@ function TBrcMain.GetChunk(out start, stop: PByteArray): boolean;
   if chunk <> 0 then
   begin
     start := fCurrentChunk;
-    if chunk > CHUNKSIZE then
+    if chunk > fChunkSize then
     begin
-      stop := pointer(GotoNextLine(pointer(@start[CHUNKSIZE])));
+      stop := pointer(GotoNextLine(pointer(@start[fChunkSize])));
       chunk := PAnsiChar(stop) - PAnsiChar(start);
     end
     else
@@ -310,23 +306,6 @@ procedure AddTemp(w: TTextWriter; sep: AnsiChar; val: PtrInt);
   w.Add(AnsiChar(val - d10 * 10 + ord('0')));
 end;
 
-function Average(sum, count: PtrInt): PtrInt;
-// sum and result are temperature * 10 (one fixed decimal)
-var
-  x, t: PtrInt; // temperature * 100 (two fixed decimals)
-begin
-  x := (sum * 10) div count; // average
-  // this weird algo follows the "official" PascalRound() implementation
-  t := (x div 10) * 10; // truncate
-  if abs(x - t) >= 5 then
-    if x < 0 then
-      dec(t, 10)
-    else
-      inc(t, 10);
-  result := t div 10; // truncate back to one decimal (temperature * 10)
-  //ConsoleWrite([sum / (count * 10), ' ', result / 10]);
-end;
-
 function ByStationName(const A, B): integer; // = StrComp() but ending with ';'
 var
   pa, pb: PByte;
@@ -354,6 +333,11 @@ function ByStationName(const A, B): integer; // = StrComp() but ending with ';'
     result := 1;
 end;
 
+function ceil(x: double): PtrInt; // "official" rounding method
+begin
+  result := trunc(x) + ord(frac(x) > 0);  // using FPU is fast enough here
+end;
+
 function TBrcMain.SortedText: RawUtf8;
 var
   c: PtrInt;
@@ -385,7 +369,7 @@ function TBrcMain.SortedText: RawUtf8;
           p := fList.StationName[n^];
           w.AddNoJsonEscape(p, NameLen(p));
           AddTemp(w, '=', s^.Min);
-          AddTemp(w, '/', Average(s^.Sum, s^.Count));
+          AddTemp(w, '/', ceil(s^.Sum / s^.Count));
           AddTemp(w, '/', s^.Max);
           dec(c);
           if c = 0 then
@@ -409,7 +393,7 @@ function TBrcMain.SortedText: RawUtf8;
 
 var
   fn: TFileName;
-  threads: integer;
+  threads, chunkmb: integer;
   verbose, affinity, help: boolean;
   main: TBrcMain;
   res: RawUtf8;
@@ -427,6 +411,8 @@ function TBrcMain.SortedText: RawUtf8;
   Executable.Command.Get(
     ['t', 'threads'], threads, '#number of threads to run',
       SystemInfo.dwNumberOfProcessors);
+  Executable.Command.Get(
+    ['c', 'chunk'], chunkmb, 'size in #megabytes used for per-thread chunking', 4);
   help := Executable.Command.Option(['h', 'help'], 'display this help');
   if Executable.Command.ConsoleWriteUnknown then
     exit
@@ -438,11 +424,11 @@ function TBrcMain.SortedText: RawUtf8;
   end;
   // actual process
   if verbose then
-    ConsoleWrite(['Processing ', fn, ' with ', threads, ' threads',
-                  ' and affinity=', BOOL_STR[affinity]]);
+    ConsoleWrite(['Processing ', fn, ' with ', threads, ' threads, chunkmb=',
+      chunkmb, ' and affinity=', BOOL_STR[affinity]]);
   QueryPerformanceMicroSeconds(start);
   try
-    main := TBrcMain.Create(fn, threads, {max=}45000, affinity);
+    main := TBrcMain.Create(fn, threads, chunkmb, {max=}45000, affinity);
     // note: current stations count = 41343 for 2.5MB of data per thread
     try
       main.WaitFor;