Last refresh

[pedrosakuma]

Hello Victor,

I know is very close to the official cut time.
I submitted a PR on 1brc-bench with my repository.

Thanks in advance.

[buybackoff]

I know is very close to the official cut time.

Actually, there is no official cut off time for me. That even sounds weird to me. I'm not affiliated with the Java competition. And they were unwelcoming enough to make me not even trying. What I liked about this challenge is that no one just blindly copied others' solutions and everyone kept their original designs to a big extent. For me the main constraint was that I understood the code and given lot's of free time I had a chance to come up with something similar. Or something obvious that I just forgot. These things I could reuse. But never I would reuse SIMD simultaneous 4-number parsing by @noahfalk and similar stuff.

So my cut off time is dictated by my own time constraints and availability of big machines for the final benchmarking. I'm going to a 3-days vacation tomorrow evening, but I will have time during the day tomorrow for extensive benchmarking. Feel free to update your solution, let's say before 14PM UTC tomorrow, if it's not just verbatim copy of someone's code. Same for @kpocza. Maybe even later. But I may lose access to the big machines after that vacation.

I'm still waiting when @RagnarGrootKoerkamp updates his fastest-Rust but not compliant code, the comparison would be very interesting anyway.

And @austindonisan has had some issues with 10K dataset. I had to disable it 2 commits ago (tweak hash sizes... was failing on 4 cores). It looked OK as of the last commit yesterday for some combination of cores/threads, but since it was disabled I could not run it through all combinations.

[buybackoff]

Two more things. Since this issue is called "Last refresh", some final touches remain.

I include repos as submodules here: https://github.com/buybackoff/1brc-bench/tree/main/src

I'm going to run many benchmarks tomorrow on 2 AMD / 2 Intel machines and AWS m6/7g.metal Graviton. I have two issues.

1. License. @lehuyduc @austindonisan @dzaima @RagnarGrootKoerkamp @CameronAavik @kpocza @NimaAra @mtopolnik (Rust) do not have any license. It would be nice if every submodule in my repo had one of MIT/Apache/BSD. I may be reluctant to keep a proprietary submodule there, even if I understand that probably the intent was FOSS from the beginning.

2. ARM compatibility. I believe native and some .NET solutions are out (FYI @xoofx and @nietras it looks like you are fine on M1/2 Macs given the benchmarks Alexandre did on M1 Pro. Should I expect this to work on Gravitons? Or that was Rosetta emulation?). I use only Vector256 API and that should be accelerated on ARM as well. I'm not sure about Rust, but from a quick search it looks like it should work. Anyway if you do not use anything x64/x86 specific and could just use x-arch Vector or other API that would be nice. Since Java does not have easy access to SIMD and they had to reinvent the wheel with parallel int64 reads I expect most Java solutions will just work on ARM, that's a positive thing of a constrained environment. I would love to have more things to compare in ARM.

[dzaima]

Added a license to my repo (forgot to do so before!).

I could probably get an aarch64 port made without too much trouble, though we'll have to see if I get around to it today, tomorrow, or ever.

[noahfalk]

But never I would reuse SIMD simultaneous 4-number parsing by @noahfalk and similar stuff.

In case you were worried on my behalf, I'm happy to have anyone reuse anything that appears useful from my entry :) Of course as the curator of these cross-language 1BRC results its totally your call on how distinctive you want each entry to be before you decide to include it.

[NimaAra]

I have added the MIT license now on master.

[buybackoff]

In case you were worried on my behalf, I'm happy to have anyone reuse anything that appears useful from my entry :) Of course as the curator of these cross-language 1BRC results its totally your call on how distinctive you want each entry to be before you decide to include it.

@noahfalk I was talking for myself. Frankly, I did not have time to grok your solution in every detail, especially the SIMD 4-in-1 number parsing. But I could have copied your main loop and adapt it to my other parts without groking its every detail. It would be of zero interest to me and would bring zero fun. Actually on many cores, e.g. 64+, we are sometimes becoming competitive. You are consuming memory so aggressively on each core, so probably (my ungrounded theory) too many cores do not help.

[buybackoff]

@noahfalk You use AVX directly a lot. Do you think it's feasible to just use Vector256? So that we may have a chance for reasonable perf on ARM?

[noahfalk]

You are consuming memory so aggressively on each core, so probably (my ungrounded theory) too many cores do not help

Yeah, I could easily believe that. I never tested or tuned it for operation above 8 threads so it makes sense to me that it doesn't do as well there.

Do you think it's feasible to just use Vector256? So that we may have a chance for reasonable perf on ARM?

Some of those places probably are replaceable with Vector256 without changing the generated code, but unfortunately not all of them. In particular:

• MultiplyAddAdjacent doesn't have a Vector256 equivalent I'm aware of
• There is a Vector256.Shuffle(), but it is dramatically slower. I think it was generating a large number of instructions that would correctly handle shuffling across the 128bit lane boundary whereas the Avx2.Shuffle() fast hardware intrinsic doesn't support shuffling across that boundary.

Probably the easiest option is to exclude my entry from any ARM benchmarks with a note that it used architecture specific intrinsics. If anyone wanted to try porting my approach to ARM I'm happy to have them do that but I don't plan to tackle it myself.

[kpocza]

License added.

ARM support is a good question for me. If the tests fail, I can check it on my Raspberry Pi if it supports .NET 8.

There is an extension for VS, which can show geneeated assembly code at function level. You may use it to check what Avx2 is generated for certain Vector operations (and other parts as well).

[mtopolnik]

I added the license as well.

[austindonisan]

I added a license, too. Some last minute improvements, too, so please pull the latest copy.

I'm pretty confident it's bugfree and should work on the 10K data set now. The 10k set is only taking 2.4x as long now which might make it competitive?

I don't expect it to work on ARM (well at least). My entire codebase is centered around 256bit vectors.

[buybackoff]

@NimaAra your code does not work in the bench setup, probably because the input file is a symlink there. See @kpocza fix for that: kpocza/1brc@9ccfe6a

[nietras]

@xoofx and @nietras it looks like you are fine on M1/2 Macs given the benchmarks Alexandre did on M1 Pro. Should I expect this to work on Gravitons? Or that was Rosetta emulation?

Should work fine on ARM. No simulation. Most cross-platform Vector256 (which is impl on ARM as 2 x Vector128). My impl has fallback when no Avx2 and only used for a specific hash optimization. On ARM likely not run as well as not optimized particularly for that.

[NimaAra]

Symlink support added to master albeit not tested.

[buybackoff]

Done! Try to digest 2540 files now :)
buybackoff/1brc-bench@41fb2bb