[nmaludy]

If i'm understanding the repository correctly, it looks like each language reads from a file, does some I/O printing to console, then computes the value, then some more console printing and exits.

In my opinion, the comparisons could be better if the file I/O and console printing were removed.

[nheer]

Author here — yep, you understood the repository correctly.

My Python version is a good example of the structure: read rounds.txt, run the loop, print the result, exit. I’m timing the whole program with hyperfine.

I agree that for a “pure compute” microbenchmark you could remove file I/O and console output. I kept them mainly because:

- It gives every language the same simple interface (same input, same output) and acts as a basic correctness/sanity check.

- The benchmark runs 1 billion iterations. The file read and a single print happen once per run, so that overhead is tiny compared to the loop, and the results stay comparable in practice.

That said, I’m not against a compute-only / quiet mode. Since hyperfine already handles timing externally, the real work is implementing and maintaining a consistent --quiet / --no-io variant across 50+ languages.

If someone wants to contribute that (even starting with a subset), I’m happy to review PRs.

[Twirrim]

I'm not sure why the contents of rounds.txt isn't just provided as some kind of argument instead of read in from a file. Given all the other boilerplate involved, I would have expected it to be trivial to add relevant templating.

[cgh]

Zig could include the file at compile-time with @embedFile.

[Twirrim]

So could Go (https://pkg.go.dev/embed), Rust (https://doc.rust-lang.org/std/macro.include_str.html) and a number of other languages in the set.

[AndyKelley]

this would provide the optimizer the unfair chance to replace the entire application with a compile time constant

[gus_massa]

The idea of using a file is to force the program to use that number as an unknown value at compile time.

[igouy]

command line arguments would be unknown at compile time.

[gavinray]

I'm fairly sure I can speed the JVM implementations up a significant amount by MMAP'ing the file into memory and ensuring it's aligned.

[pjscott]

I'm not too familiar with the JVM so perhaps I'm missing something here: how would that help? The file is tiny, just a few bytes, so I'd expect the main slowdown to come from system call overhead. With non-mmap file I/O you've got the open/read/close trio, and only one read(2) should be needed, so that's three expensive trips into kernel space. With mmap, you've got open/stat/mmap/munmap/close.

Memory-mapped I/O can be great in some circumstances, but a one-time read of a small file is one of the canonical examples for when it isn't worth the hassle and setup/teardown overhead.