It's not just that. Basic patterns in C# are known to have pathological performance problems (implicit boxing, implicit heap allocations) that you simply don't run into programming in C or C++. These are things that tank performance in day-to-day programming that do not show up in carefully tuned benchmarks.
Source: Helped profile lots of C# games (not IL2CPP with Unity, although that's pretty bad IMO as well), not pleased with what I saw.
This is a bold claim. Please provide evidence that the most current .NET implementation (.NET Core 3.1) is slower than any JavaScript implementation.
This doesn't pass the smell test since you're comparing an ahead-of-time statically typed approach to a dynamic scripting language, both of which have had highly tuned JIT implementations, both of which are using garbage collection. You can implement things poorly in C#, sure, but you're making a much stronger claim of consistently poor performance.
Saying 'dude trust me' is not a source.
C# currently 1st place in this webserver benchmark. Ahead of C/C++/Go/Java/D.
No offense to JavaScript, I like it and it has its uses. But surely your OP is joking when saying JavaScript is faster than C#. Even after all the performance improvements that V8 received.
I feel like it's possible to write careful C# for performance. It just won't be entirely idiomatic. Things like buffer re-use, ordinary techniques you'd need to apply manually for C and C++ in similar domains too.
It really doesn't matter how much headache it saves you in debugging. The problem simply cannot be solved at the required level of performance if you use C#.
>When the project reaches significant compatibility, other emulators can take ideas from its code and port them to C/C++/Rust/assembly if they desire to do so.
The only legitimate use of this project is as a research bed for future emulators, so I agree with you there.
Of course, there's always performance left on the table when you write in a language like C# or Java (and even a little performance matters a lot when it comes to emulation), but the memory safety that C# can provide over C++ can save the developers a lot of debugging.
I think such an application can perform perfectly well in a hardware generation or two and until that point compatibility matters more than speed anyway; that's where ease of development will shine. Running an unplayable game well is not a very interesting project for end users.
When the project reaches significant compatibility, other emulators can take ideas from its code and port them to C/C++/Rust/assembly if they desire to do so.