You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: entries/abouchez/README.md
+25-18Lines changed: 25 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,35 +22,40 @@ Here are the main ideas behind this implementation proposal:
22
22
23
23
-**mORMot** makes cross-platform and cross-compiler support simple - e.g. `TMemMap`, `TDynArray`,`TTextWriter`, `SetThreadCpuAffinity`, `crc32c`, `ConsoleWrite` or command-line parsing;
24
24
- 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;
25
-
-Process file in parallel using several threads - configurable via the `-t=` switch, default being the total number of CPUs reported by the OS;
26
-
- 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;
25
+
-File is processed in parallel using several threads - configurable via the `-t=` switch, default being the total number of CPUs reported by the OS;
26
+
- 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;
27
27
- Each thread manages its own `Station[]` data, so there is no lock until the thread is finished and data is consolidated;
28
28
- 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;
29
-
- 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);
30
-
- On Intel/AMD/AARCH64 CPUs, *mORMot* uses hardware SSE4.2 opcodes for this crc32c computation;
31
-
- Store values as 16-bit or 32-bit integers, as temperature multiplied by 10;
32
-
- Parse temperatures with a dedicated code (expects single decimal input values);
29
+
- 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);
30
+
- On Intel/AMD/AARCH64 CPUs, *mORMot* offers hardware SSE4.2 opcodes for this crc32c computation;
31
+
- 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;
32
+
- Values are stored as 16-bit or 32-bit integers, as temperature multiplied by 10;
33
+
- Temperatures are parsed with a dedicated code (expects single decimal input values);
33
34
- 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;
34
35
- 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);
35
36
- 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);
36
-
-Can optionally output timing statistics and resultset hash value on the console to debug and refine settings (with the `-v` command line switch);
37
-
-Can optionally set each thread affinity to a single core (with the `-a` command line switch).
37
+
-It can optionally output timing statistics and resultset hash value on the console to debug and refine settings (with the `-v` command line switch);
38
+
-It can optionally set each thread affinity to a single core (with the `-a` command line switch).
38
39
39
40
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 ;)
40
41
41
42
## Why L1 Cache Matters
42
43
43
-
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.
44
+
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.
44
45
45
46
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.
46
47
47
-
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. ;)
48
+
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. ;)
48
49
49
50
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.
50
51
51
52
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.
52
53
53
-
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.
54
+
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.
55
+
56
+
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.
57
+
58
+
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?
54
59
55
60
## Usage
56
61
@@ -70,8 +75,10 @@ Options:
70
75
-h, --help display this help
71
76
72
77
Params:
73
-
-t, --threads <number> (default 16)
78
+
-t, --threads <number> (default 20)
74
79
number of threads to run
80
+
-c, --chunk <megabytes> (default 4)
81
+
size in megabytes used for per-thread chunking
75
82
```
76
83
We will use these command-line switches for local (dev PC), and benchmark (challenge HW) analysis.
77
84
@@ -110,14 +117,14 @@ This is the expected behavior, and will be fine with the benchmark challenge, wh
110
117
111
118
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):
Processing measurements.txt with 20 threads, chunkmb=4 and affinity=false
122
+
result hash=85614446, result length=1139418, stations count=41343, valid utf8=1
116
123
done in 2.36s 6.6 GB/s
117
124
118
-
ab@dev:~/dev/github/1brc-ObjectPascal/bin$ ./abouchez measurements.txt -t=10 -v -a
119
-
Processing measurements.txt with 20 threads and affinity=true
120
-
result hash=8A6B746A, result length=1139418, stations count=41343, valid utf8=1
125
+
ab@dev:~/dev/github/1brc-ObjectPascal/bin$ ./abouchez measurements.txt -v -a
126
+
Processing measurements.txt with 20 threads, chunkmb=4 and affinity=true
127
+
result hash=85614446, result length=1139418, stations count=41343, valid utf8=1
121
128
done in 2.44s 6.4 GB/s
122
129
```
123
130
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!
0 commit comments