4 ms·

minecraft is not faster on GraalVM AOT nor will be every Unity Game out there. C++ is faster but not because it is AOT, it's because it is a lower level languag

minecraft is not faster on GraalVM AOT nor will be every Unity Game out there. C++ is faster but not because it is AOT, it's because it is a lower level language which is more brittle and less permissive/dynamic. AOT on high level languages reduce throughput for most uses, even with PGO.

Shadonototra 4y ago
Unity games now ship with IL2CPP, to benefit from AOT compilation, the language and its constructs remains the same, gone are the stutters people were experiencing Minecraft was rewritten in C++ to increase performance on lower end devices and overall general performance (no longer need to warmup JVM to remove the stutters during gameplay, lower downtime for restarts in realm based servers) https://old.reddit.com/r/Minecraft/comments/i27zzo/5_ways_the_slow_minecraft_problem_can_be_fixed/ https://old.reddit.com/r/Minecraft/comments/i27zzo/5_ways_th... We can talk all day about high/low level languages, JIT/GC introduce overhead, that's it When you only have 8ms for your framebudget at 120hz, every bit make the difference The rest is handled on the GPU anyways, AOT compiled ;)
- SemanticStrengh 4y ago
  > Unity games now ship with IL2CPP, to benefit from AOT compilation No that is cheating, IL2CPP is a C# to C++ transpiler.. Which is similar to writing a C++ program, interesting technology though. However it's true Unity also has a Burst compiler which is AOT is release mode and output LLVM IR. Look that is interesting and that is exactly where I wanted the conversation to go. GraalVM is generally slower on AOT than on JIT. I expect the same from .NET 7 AOT (haven't checked but is likely true) Unity Burst is interesting because it leverage an infrastructure that has received an enormous number of human resources and optimizations for AOT (LLVM). However Unity does not allow to benchmark Burst vs modern .NET JIT so it's very possible that Burst is in many cases slower than .NET JIT. This can't be verified easily and I'm not aware if Burst can be used outside of Unity but I guess one could write the same microbenchmark for both, it's just that no-one did it. However, Unity has gained a lot of technical debt because its own tooling (and Mono) are stuck on .NET 4.x They are apparently actively seeking to update their support and will leverage CoreCLR to some extent so maybe once it will be done, comparisons will become easier and they might or not replace Burst by regular CoreCLR, time will tell. https://forum.unity.com/threads/gdc-2022-the-future-of-net-and-unity.1255956/ https://forum.unity.com/threads/gdc-2022-the-future-of-net-a... https://forum.unity.com/threads/net-6-support.1059992/ https://forum.unity.com/threads/net-6-support.1059992/ > Minecraft was rewritten in C++ C++ is faster because it is lower level, my point is Minecraft do not use Java AOT. and as said many of minecraft stutters are avoidable GC pauses. It's true 8ms is a tight budget indeed hence why ZGC is a key advance, a place where C# is currently inferior to java. > The rest is handled on the GPU anyways, AOT compiled Haha nice try, I appreciate the tentative but I'm not sure you're being right. regarding the topic of compiling shaders for a 2D GUI, using a JIT is a key advantage, see e.g. https://github.com/blend2d/blend2d https://github.com/blend2d/blend2d As for GPU drivers (handling openGL/etc) I think its a mix of both but I have forgotten the things I had read about them on phoronix Most game emulators strongly benefit from JITs shaders too.
  - pjmlp 4y ago
    Just like C++ and Objective-C were cheating when they came into the world, as C macro processors? Are we using two weights here?
  - DeathArrow 4y ago
    As for which is faster, I have a counter argument to your claims that JIT code runs faster than AOT compiled code for the same language. C++/CLI is slower than normal C++. Of course, sometimes JIT is faster. I remember gcj compiled code was plenty of times slower than code running under JVM. I think there is no easy way to conclude which is faster, AOT or JIT. Garbage collection also takes its toll. Looking at most benchmarks Go which is AOT compiled does not fare better than JIT-ed C# or Java. For .NET I suspect there won't be much difference speedwise between AOT and JIT. But AOT vs JIT has some other aspects. Like with Blazor who, at first, ran under a .NET virtual machine which ran under WebAssembly Virtual Machine. With AOT, things are simpler.
    - SemanticStrengh 4y ago
      > C++/CLI is slower than normal C++ 1) IIRC CLI is managed AKA garbage collected (BTW managed C++ is common practice e.g. chromium) 2) human resources, c++/cli has received much less optimization effort than LLVM/GCC/C# as for Java https://github.com/oracle/graal/issues/1069#issuecomment-473649871 https://github.com/oracle/graal/issues/1069#issuecomment-473... Go is the proof that GC-ed languages can be fast via AOT so it is not the discriminating factor. I suspect C++ with a GC is not much faster than JITed C# and the rest would be explained by other language brittleness such as e.g. the vtable hell, monomorphisation, etc Also weirdly, LLVM and GCC have received much more optimization human resources than openjdk and coreclr > But AOT vs JIT has some other aspects. Like with Blazor who, at first, ran under a .NET virtual machine which ran under WebAssembly Virtual Machine. With AOT, things are simpler. well yes for this special case
      - WorldMaker 4y ago
        > IIRC CLI is managed CLI compiles to MSIL and runs on the CLR, so yes, very managed by default. > c++/cli has received much less optimization effort than LLVM/GCC/C# C++/CLI also found no regular users and people have been warned not to use it from even just months after its original release. From certain perspectives: It has really only had the one release in 17 years and been a "legacy tool" for most of that time. (Possibly two releases if you count C++/CX, though that doesn't run on the CLR and is its own weird one-off thing for COM weirdness.)

Shadonototra 4y ago

Unity games now ship with IL2CPP, to benefit from AOT compilation, the language and its constructs remains the same, gone are the stutters people were experiencing Minecraft was rewritten in C++ to increase performance on lower end devices and overall general performance (no longer need to warmup JVM to remove the stutters during gameplay, lower downtime for restarts in realm based servers) https://old.reddit.com/r/Minecraft/comments/i27zzo/5_ways_the_slow_minecraft_problem_can_be_fixed/ https://old.reddit.com/r/Minecraft/comments/i27zzo/5_ways_th... We can talk all day about high/low level languages, JIT/GC introduce overhead, that's it When you only have 8ms for your framebudget at 120hz, every bit make the difference The rest is handled on the GPU anyways, AOT compiled ;)

SemanticStrengh 4y ago
> Unity games now ship with IL2CPP, to benefit from AOT compilation No that is cheating, IL2CPP is a C# to C++ transpiler.. Which is similar to writing a C++ program, interesting technology though. However it's true Unity also has a Burst compiler which is AOT is release mode and output LLVM IR. Look that is interesting and that is exactly where I wanted the conversation to go. GraalVM is generally slower on AOT than on JIT. I expect the same from .NET 7 AOT (haven't checked but is likely true) Unity Burst is interesting because it leverage an infrastructure that has received an enormous number of human resources and optimizations for AOT (LLVM). However Unity does not allow to benchmark Burst vs modern .NET JIT so it's very possible that Burst is in many cases slower than .NET JIT. This can't be verified easily and I'm not aware if Burst can be used outside of Unity but I guess one could write the same microbenchmark for both, it's just that no-one did it. However, Unity has gained a lot of technical debt because its own tooling (and Mono) are stuck on .NET 4.x They are apparently actively seeking to update their support and will leverage CoreCLR to some extent so maybe once it will be done, comparisons will become easier and they might or not replace Burst by regular CoreCLR, time will tell. https://forum.unity.com/threads/gdc-2022-the-future-of-net-and-unity.1255956/ https://forum.unity.com/threads/gdc-2022-the-future-of-net-a... https://forum.unity.com/threads/net-6-support.1059992/ https://forum.unity.com/threads/net-6-support.1059992/ > Minecraft was rewritten in C++ C++ is faster because it is lower level, my point is Minecraft do not use Java AOT. and as said many of minecraft stutters are avoidable GC pauses. It's true 8ms is a tight budget indeed hence why ZGC is a key advance, a place where C# is currently inferior to java. > The rest is handled on the GPU anyways, AOT compiled Haha nice try, I appreciate the tentative but I'm not sure you're being right. regarding the topic of compiling shaders for a 2D GUI, using a JIT is a key advantage, see e.g. https://github.com/blend2d/blend2d https://github.com/blend2d/blend2d As for GPU drivers (handling openGL/etc) I think its a mix of both but I have forgotten the things I had read about them on phoronix Most game emulators strongly benefit from JITs shaders too.
- pjmlp 4y ago
  Just like C++ and Objective-C were cheating when they came into the world, as C macro processors? Are we using two weights here?
- DeathArrow 4y ago
  As for which is faster, I have a counter argument to your claims that JIT code runs faster than AOT compiled code for the same language. C++/CLI is slower than normal C++. Of course, sometimes JIT is faster. I remember gcj compiled code was plenty of times slower than code running under JVM. I think there is no easy way to conclude which is faster, AOT or JIT. Garbage collection also takes its toll. Looking at most benchmarks Go which is AOT compiled does not fare better than JIT-ed C# or Java. For .NET I suspect there won't be much difference speedwise between AOT and JIT. But AOT vs JIT has some other aspects. Like with Blazor who, at first, ran under a .NET virtual machine which ran under WebAssembly Virtual Machine. With AOT, things are simpler.
  - SemanticStrengh 4y ago
    > C++/CLI is slower than normal C++ 1) IIRC CLI is managed AKA garbage collected (BTW managed C++ is common practice e.g. chromium) 2) human resources, c++/cli has received much less optimization effort than LLVM/GCC/C# as for Java https://github.com/oracle/graal/issues/1069#issuecomment-473649871 https://github.com/oracle/graal/issues/1069#issuecomment-473... Go is the proof that GC-ed languages can be fast via AOT so it is not the discriminating factor. I suspect C++ with a GC is not much faster than JITed C# and the rest would be explained by other language brittleness such as e.g. the vtable hell, monomorphisation, etc Also weirdly, LLVM and GCC have received much more optimization human resources than openjdk and coreclr > But AOT vs JIT has some other aspects. Like with Blazor who, at first, ran under a .NET virtual machine which ran under WebAssembly Virtual Machine. With AOT, things are simpler. well yes for this special case
    - WorldMaker 4y ago
      > IIRC CLI is managed CLI compiles to MSIL and runs on the CLR, so yes, very managed by default. > c++/cli has received much less optimization effort than LLVM/GCC/C# C++/CLI also found no regular users and people have been warned not to use it from even just months after its original release. From certain perspectives: It has really only had the one release in 17 years and been a "legacy tool" for most of that time. (Possibly two releases if you count C++/CX, though that doesn't run on the CLR and is its own weird one-off thing for COM weirdness.)