| ▲ | davikr 11 hours ago |
| This does not seem like a realistic benchmark target. |
|
| ▲ | mrkeen 11 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | behnamoh 11 hours ago | parent [-] | | > This code is just iterations... Which is what the average programmer out there writes. Therefore, I think this is actually a good realistic benchmark. | | |
| ▲ | steveBK123 10 hours ago | parent | next [-] | | Precisely - its bad code, which is what most code is! | | | |
| ▲ | elzbardico 9 hours ago | parent | prev [-] | | What the average programmer out there writes is just a tip on the iceberg of what gets executed. And an incredibly small tip. |
|
|
|
| ▲ | moralestapia 9 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | deanCommie 10 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | PaulHoule 10 hours ago | parent | next [-] | | 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. | | |
| ▲ | bob1029 9 hours ago | parent | next [-] | | 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. | |
| ▲ | MrLeap 5 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | vitus 7 hours ago | parent | prev [-] | | > * 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... |
|
