3 ms·
> the fastest, heavily-optimised Java solution runs in just under a second on my machine I don’t understand how this is possible. The file in question has 13GB
by michalsustr 3y ago
> the fastest, heavily-optimised Java solution runs in just under a second on my machine
I don’t understand how this is possible. The file in question has 13GB, while the fastest commonly available SSDs are 12400 MB/s. Am I missing something?
- gozzoo 3y agomost of the file remains in the OS disk cache after the first run
- whyever 3y agoMy guess: If you run the benchmark several times, the OS will cache the file in RAM.
- dietr1ch 3y agoBenchmarking this gets tricky once you realize that the file might be entirely cached if the computer has enough RAM.
- deleted 3y ago[deleted]
- klyrs 3y agoHah, we use different computers. I was thinking, this might be tricky if you aren't careful to keep the file entirely cached in RAM.
- chii 3y agothat might be a sustained single threaded read performance. What if the method of access was concurrent from different parts of the file, and was operating system cached?
- mainde 3y agoI think this bit in the baseline section applies to the Java one too >Note that that’s a best-of-five measurement, so I’m allowing the file to be cached. Who knows whether Linux will allow all 13GB to be kept in disk cache, though presumably it does, because the first time it took closer to 6 seconds.
- nsteel 3y agoYea, I assumed that. Which makes the parallel version improvements still interesting but surely it's very artificial. You can't processes all the data at the same time if you don't have it all yet.
- codegladiator 3y agothere are no disk file read times in the original rules. file is in memfs.
- maximus-decimus 3y agoIf he runs the test multiple times, the file should all be cached in RAM after the first run.
- Keyframe 3y agoactual 1brc runs with data in RAM disk, he could've/should've done the same.