This does not seem like a realistic benchmark target.
Perhaps it's unrealistic in the sense that this is unrealistically-optimisable code.
Real-world code has closures, allocations, and pointer-dererencing. This code is just iterations, additions and modulus.
> This code is just iterations...
Which is what the average programmer out there writes. Therefore, I think this is actually a good realistic benchmark.
Precisely - its bad code, which is what most code is!
What's a Github repository with good code?
All code is bad, some is useful
What the average programmer out there writes is just a tip on the iceberg of what gets executed. And an incredibly small tip.
The other problem with it is that there are other variables involved besides pure speed, which is CONSISTENCY of speed.
Folks are always surprised to see just how fast Java is able to perform on benchmarks - it has a reputation as such a slow language then how come it's able to execute almost as fast as C++?
But Java's problem isn't execution performance. It's:
* Startup performance. It takes time to instantiate the JVM. That matters for some, not for others.
* Consistent performance. This is the nature of Garbage Collection. It can surprise you when it executes you and drop a performance blip when you least expect it.
Most developers who think they need the fastest performance actually need CONSISTENT performance more than the fastest.
> * Consistent performance. This is the nature of Garbage Collection. It can surprise you when it executes you and drop a performance blip when you least expect it.
This has been getting much better in Java in recent years. Shenandoah has been the default since Java 15, and we've been seeing further improvements since then.
> Processing thread stacks concurrently gives us reliable sub-millisecond pauses in JDK 17.
https://developers.redhat.com/articles/2021/09/16/shenandoah...
Shenandoah was deemed production-ready in OpenJDK 15, but G1 remains the default collector in 23.
I stand corrected. I probably got confused by the statement that Shenandoah is bundled by default as of JDK 12.
I even see some video games (say Dome Keeper) that periodically go out to lunch even on a top of the line gaming PC and understand that kind of game is often written in C# which has a garbage collector. Thing is I remember playing games on the much weaker PS Vita that were written in C# but I never remember pausing like that.
VR games are now the frontier of gaming (in terms of the industry outdoing itself) and there you're approaching hard real time requirements because it is so awful to get seasick. I appreciate it.
I think it might have more to do with the specific implementation than the tool.
Most incarnations of C# offer a GC.Collect method and an ability to configure the threading model around collections. Used properly, you can keep maximum delays well-bounded. You still have to work your ass off to minimize allocations, but when some do inevitably occur due to framework internals, etc., you don't want to have to clean up 3 hours worth of it at once. Do it every frame or scene change.
These hitches (in unityland anyways) usually mean the dev is allocating a lot of short lived objects in their render loop. Even little heuristics like keeping the new keyword out of Update() and using object pools prevent the majority of things like this for us over on the unity side.
Dome Keeper's dev Bippinbits is a Godot studio. Some comments on their opinions that I can't read until I dig out my twitter login lol. https://x.com/Bippinbits/status/1702351798302851398
Godot has some perf warts still being churned out, so I don't know what all they've got to do to finesse around them. Even if GDScript was greasy gcc lightning, it's really easy to crunch yourself into some compromises when you're trying to eat your way out of the bottom of ticket mountain before Nextfest or you starve or whatever. Small team gamedev is wild.
I am wondering also if my big computer with 64G is part of the problem: if I allocated less RAM to the process I wonder if the GC breaks would be shorter but more frequent.
Javas problem is a culture of overly generic solutions (vendor neutral!) that then try to fix architectural performance issues by liberally adding caching. This makes both the startup time and consistency way worse than it needs to be.
Nor does it pretend to be.
It's literally just "1 Billion nested loop iterations", methods and results.
You make of that whatever you want.