3 ms·

Hm, if you don't actually need a sandbox then I think just using the C# run-time makes a lot of sense. I also like C#, but I've never been in a situation to try

Hm, if you don't actually need a sandbox then I think just using the C# run-time makes a lot of sense. I also like C#, but I've never been in a situation to try the fairly new AOT support. Sounds like a good idea, though. C# is a very good language.

brucehoult 3y ago
C# runtime is HUGE and not ported to everything. The compilation step to native code takes a significant amount of time.
- logicprog 3y ago
  Good to know. That solidifies my plan to embed the dotnet runtime in my engine and load JIT code, not compile C# to AOT and then run that through an emulation layer
- Rohansi 3y ago
  Do you mean compiling the .NET runtime (CoreCLR) itself or AOT compiling C# code? Because I recently tried AOT compiled C# and that builds quickly. And you don't generally need to compile the .NET runtime when embedding it because you can just load the builds they ship.
  - brucehoult 3y ago
    Simply running a DotNET dll. I just tried a basic "Hello World" program compiled to a CIL .dll and to RV64 machine code, on my x86 Linux machine (original ThreadRipper 2990WX) and then running it through different JIT/interpreters. Wall time: DotNET: 0.061s qemu-riscv64: 0.006s Spike: 0.031s Qemu is JIT with Linux syscall layer built in (in native code). Spike is a RISC-V interpreter with Linux syscall layer provided by interpreted RISC-V "pk" So the DotNET JIT has quite a high overhead for startup, or one-time code. For very compute-intensive code DotNet has an advantage. e.g. on my own primes benchmark (https://hoult.org/primes.txt https://hoult.org/primes.txt, https://hoult.org/primes.cs https://hoult.org/primes.cs) DotNET: 3.5s qemu-riscv64: 10.2s gcc: 9.7s (i.e. defaulting to -O0) gcc -O1: 3.2s DotNET beats emulated RISC-V here, but the RISC-V emulator (with RISC-V code compiled with -O1) is pretty much as fast as a lazy person compiling C to native x86 gets.
    - Rohansi 3y ago
      Oh, so you meant startup time for the runtime, JIT, etc. then. That's not exactly relevant to usage in game engines here because it is only done once. If you want to compare startup times you should be using .NET's AOT compilation so it doesn't need to load the full runtime or do any JIT compilation. See here: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

brucehoult 3y ago

C# runtime is HUGE and not ported to everything. The compilation step to native code takes a significant amount of time.

logicprog 3y ago
Good to know. That solidifies my plan to embed the dotnet runtime in my engine and load JIT code, not compile C# to AOT and then run that through an emulation layer
Rohansi 3y ago
Do you mean compiling the .NET runtime (CoreCLR) itself or AOT compiling C# code? Because I recently tried AOT compiled C# and that builds quickly. And you don't generally need to compile the .NET runtime when embedding it because you can just load the builds they ship.
- brucehoult 3y ago
  Simply running a DotNET dll. I just tried a basic "Hello World" program compiled to a CIL .dll and to RV64 machine code, on my x86 Linux machine (original ThreadRipper 2990WX) and then running it through different JIT/interpreters. Wall time: DotNET: 0.061s qemu-riscv64: 0.006s Spike: 0.031s Qemu is JIT with Linux syscall layer built in (in native code). Spike is a RISC-V interpreter with Linux syscall layer provided by interpreted RISC-V "pk" So the DotNET JIT has quite a high overhead for startup, or one-time code. For very compute-intensive code DotNet has an advantage. e.g. on my own primes benchmark (https://hoult.org/primes.txt https://hoult.org/primes.txt, https://hoult.org/primes.cs https://hoult.org/primes.cs) DotNET: 3.5s qemu-riscv64: 10.2s gcc: 9.7s (i.e. defaulting to -O0) gcc -O1: 3.2s DotNET beats emulated RISC-V here, but the RISC-V emulator (with RISC-V code compiled with -O1) is pretty much as fast as a lazy person compiling C to native x86 gets.
  - Rohansi 3y ago
    Oh, so you meant startup time for the runtime, JIT, etc. then. That's not exactly relevant to usage in game engines here because it is only done once. If you want to compare startup times you should be using .NET's AOT compilation so it doesn't need to load the full runtime or do any JIT compilation. See here: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...