As sibling comments indicate, the overhead of C# isn't what it used to be and certainly isn't comparable to other languages like Python/Ruby/PHP.
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.
C# is consistently a worse performer than most javascript runtimes currently, and it's not much better than Python, Ruby, and PHP.
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.
> C# is consistently a worse performer than most javascript runtimes currently
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.
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.
At least C# has things like the struct keyword to prevent heap allocations for simple data structures. I don't know if recent Java has caught up with this, but it was one of the innovative features MS came up with for .NET to avoid unnecessary overhead.
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.
A large part of C#'s advancements are that additional abstractions have been added in .NET Core to make at least some of those concepts a bit more idiomatic, especially around passing segments of memory around.
>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.
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.