Adding solution for cb0s

[cb0s]

Check List:

• [x] Tests pass (./test.sh <username> shows no differences between expected and actual outputs)

• [x] All formatting changes by the build are committed

• [x] Your launch script is named calculate_average_<username>.sh (make sure to match casing of your GH user name) and is executable

• [x] Output matches that of calculate_average_baseline.sh

• [x] For new entries, or after substantial changes: When implementing custom hash structures, please point to where you deal with hash collisions (line number)

• Execution time:

• Execution time of reference implementation:

Performance

On a AMD Ryzen 9 7950X with 64GB DDR5-CL28-5800MHz RAM and a PCIe Gen4 SSD, my algorithm completed in ~2.0s+/-0.1s on 32 threads. I compared it to thomas_wue's solution which runs in a little less than one third of the time that's why I hope I will be below 10 sec. on the testing machine without using anything like Unsafe or applying crazy bitmasks for less comparisons.

[gunnarmorling]

Hey @thomaswue, I am repeatedly running into this error when executing ths one for the 1B rows file:

Validating calculate_average_cb0s.sh -- measurements_1B.txt
Picking up existing native image 'target/CalculateAverage_cb0s_image', delete the file to select JVM mode.
Fatal error: Failed to leave the current IsolateThread context and to detach the current thread. (code 12)

Any idea what could be causing this? Couldn't find anything relevant so far.

[gunnarmorling]

So as stated above, this fails in native mode, it's not clear to me what's happening. It passes on the JVM in 00:10.284. Happy to add that to the leaderboard for the time being, I am not sure how to resolve the issue with the native GraalVM binary. Let me know if you'd like to have the JVM result added.

[wirthi]

Note: we are tracking that Fatal Error in GraalVM as ticket GR-51694 and try to reproduce it.

[thomaswue]

@cb0s This could be related to the process running out of memory before shutdown. I believe you are running with epsilon GC. Maybe there is too much allocation and a collecting GC would be required?

[cb0s]

Sorry for the late response. We currently have exams at uni...

I would love if you, @gunnarmorling , could add my JVM result to the leaderboard for the time being. I have to admit, it's the first time I am playing around with GraalVM.

[cb0s]

I did some more digging... Yes @thomaswue I am using the epsilon GC. When I used another GC it worked again. I believe, when I tested it, I must have been using a different GC mechanism. Funny enough, the pure Java solution is faster than the GraalVM solution. I added some more arguments making this solution a tiny bit faster. I will commit the changes now, and then this PR should be ready to merge @gunnarmorling . :)

[cb0s]

Some additional stuff I noticed while testing.

1. CPU isn't fully utilized sometimes (I think the IO reading is a bottleneck and more direct read process (i.e. through unsafe or something) could improve the performance quite a bit.
2. I think the more interesting part for those trying to reproduce the GraalVM error: for quicker and easier comparison and hashing, every time I parsed one line, I create a RawName record - a wrapper for the underlying byte[]-array. These however (obviously) are not cleaned up afterwards, that's probably why epsilon GC won't work. An idea (which I am not sure, if I can test before the end of this contest) would be to make the wrapper class obsolete and therefore having a smaller memory footprint.

[gunnarmorling]

All looking good now, 00:13.729 now with the JVM. Good luck for your exams :)