Add elh's Go solution

[elh]

My approach was focused on optimizing the file reading by aggressively minimizing memory allocations. I had the most fun optimizing this flow and then just added concurrency at the end. The only interesting bits are a simple custom parseFloatFast function and using unsafe.String in read-only use cases to avoid allocation of strings.

I think it might be competitive. There is a pretty funny lesson to be learned here that everyone's solution is the fastest on their own machine 😄

1/18 Timing Update

Improved on my machine to 5.5s after adjusting buffer sizes using hyperfine testing. Tuned for 2023 Macbook M2 Pro

Benchmark 1: ./bin/1brc-go 2>&1
  Time (mean ± σ):      5.479 s ±  0.144 s    [User: 38.371 s, System: 1.801 s]
  Range (min … max):    5.376 s …  5.733 s    5 runs

Original Timing

Top Java and Go solutions measured on a 2023 Apple M2 Pro Macbook with 10 cores and 16GB RAM.

#	Result (m:s.ms)	Implementation	JDK	Submitter	Notes
1	00:06.876	link	🔷 Go 1.21.5	Eugene Huang	Mine! 👈
2	00:07.602	link	🔷 Go 1.21.5	Corlin Palmer	Go implementation
3	00:13.765	link	21.0.1-graal	Roy van Rijn	GraalVM native binary
	00:13.989	link	21.0.1-graal	Artsiom Korzun
	00:14.044	link	21.0.1-graal	Thomas Wuerthinger	GraalVM native binary
	00:14.464	link	🔷 Go 1.21.5	Alexander Yastrebov	Go implementation
	00:14.839	link	21.0.1-graal	Marko Topolnik
	00:14.949	link	21.0.1-open	merykittyunsafe
	00:16.075	link	🔷 Go 1.21.5	Jan-Otto Kröpke	Go implementation

<sub>* Measured w/ Docker Desktop turned off which was a drag with its 1GB RAM VM.
* Table and final benchmark were generated with different measurements_1B.txt files. Table was run on a measurements_1B.txt file generated around a week ago.</sub>

Shoutout to @AlexanderYastrebov who's push on supporting language-agnostic solutions motivated me to work on mine. And shoutout to @gunnarmorling. Excited to share with coworkers :)

Check List:

• Tests pass (./test.sh <username> shows no differences between expected and actual outputs)
• All formatting changes by the build are committed
• Your launch script is named calculate_average_<username>.sh (make sure to match casing of your GH user name) and is executable
• Output matches that of calculate_average_baseline.sh
• For new entries, or after substantial changes: When implementing custom hash structures, please point to where you deal with hash collisions (line number) -- no custom hash used

• Execution time: 7.10s 5.48s
• Execution time of reference implementation: 167.08s

[elh]

Thanks for organizing all of this @gunnarmorling. Just clarifying that I understand this project is for Java only. I only share my solution like this because of @AlexanderYastrebov 's awesome work and the supportive convo you all have been having on his PR.

Totally understand that priorities are elsewhere. Cheers!

[gunnarmorling]

Hey, sorry for the delay here. I'll get back to it once done with the Java entries for the official leaderboard. Thx for hanging in and the nudge!

[gunnarmorling]

So I couldn't test it on the official eval instance, as I don't have Docker running there. But I tested it on a Hetzner CCX33 (i.e. the original eval instance) and there it runs in ~13 sec, vs. 00:03.074 for the fastest entry on the leader board. Thx a lot for participating!