Julia programs now shown on benchmarks game website



Well, I’m not sure if that would actually apply, since it’s a 1:1 port from the leading C++ solution and there isn’t even any official memory pool implementation in Julia (and mostly doesn’t need to be?).
My “memory pool” trick even ended up simpler than the C++ version that uses a dedicated memory pool library, so I’d find it pretty irritating if the solution wouldn’t get accepted :wink:


Isaac Gouy @igouy-guest commented 1 week ago

It is unfortunate that Go does not provide a pool/arena/… and obviously storozhukBM/arena is exactly what I ask people not to do.

Go does provide GC.



That’s a pretty weird attitude, considering that the “pool” basically comes with no extra effort and is even less verbose than in a language that doesn’t have a GC and hence would need much better pool support.

What annoys me is, that the argument is to “benchmark the GC”, but still includes languages without GC… So a language with equally powerful tools for memory management as a language without GC ends up worse off, just because it happens to have a GC.
So either everyone should be allowed to use all tricks, or languages without GC should be excluded.


Chapel programming language has GC, but the performance shows good on the benchmarks game website


Chapel’s performance looks comparable to a fast Julia solution without memory pool.
But if I remember correctly, the memory pool solution in Julia is almost the same speed as the fast C++ solution - which is ~4x faster!


Would making each implementation a separate module and making use of precompilation be of any help, provided that Julia also get a compilation step in benchmarking?

I was also considering to publish results (perhaps only the current best vs. Julia) that considers the startup and JIT overhead if there is no licensing issue.


I started extracting parts of PackageCompiler into a single file to compile an executable from the julia script - which should end up in a very comparable solution to compiling a C program. If that works out, we should be able to remove the JIT overhead.


I hate to be the guy defending Java, but there have been millions of dollars poured into making it go fast, and it’s no slouch in the performance department anymore.

In particular, I think type-unstable Julia is going to be slower than poorly-written Java in most cases. Of course, I’m not denying that well-written Julia is usually faster–and “scary-code” Julia is as fast as anything out there.


Non-GCed languages get an unfair advantage and if the binary trees benchmark was fair, C++ would use smart pointers and be ranked slightly below Python.

However, it’s still a useful GC benchmark for the languages that don’t cheat. If we can beat Haskell or SBCL’s GC on the binarytrees benchmarks with the Julia GC, that’s already a major achievement.


Done the compilation to an executable: https://github.com/KristofferC/BenchmarksGame.jl/pull/35