6 ms·

Benchmarks would be required to prove it, but I could actually see .NET outperforming Rust in a few scenarios. First, C# can be written in a way that stack allo

Benchmarks would be required to prove it, but I could actually see .NET outperforming Rust in a few scenarios. First, C# can be written in a way that stack allocates almost everything (much like Rust) and second, the runtime information and JIT compilation may allow it to make better optimisations.

Yoric 5y ago
I'm a big Rust fan but I fully expect that C# can beat Rust in some benchmarks and actually in some useful scenarios. However, claiming outright that .Net outperforms Rust feels like an apple-to-petticoat comparison.
DoctorOW 5y ago
Only if you're including compile time in the benchmarks. Binary to binary, JIT is a great example of Rust having a compile-time optimization that .NET implements at runtime.
- Yoric 5y ago
  Well, some optimizations can only be implemented at runtime, so comparing Rust and C# without knowing the actual scenario doesn't seem to make much sense.
- woodruffw 5y ago
  Optimizing compilers and JITs are difficult to compare directly: JITs have optimization pressures (e.g., selecting instructions/register slots as rapidly as possible) that AOT compilers don't (and vice versa), and (similarly) tend to have simpler IRs. In general, even the best JIT is going to underperform an AOT optimizing compiler for those reasons. Microbenchmarks (and compiler quality) will always vary, but the macro picture is difficult to change.
pcwalton 5y ago
> the runtime information and JIT compilation may allow it to make better optimisations. In practice this mostly means speculative devirtualization. This is absolutely true for C++, which tends to use virtual methods a lot, but Rust doesn't use virtual methods much. Moreover, profile-guided optimization (PGO), which Rust supports [1], allows the Rust compiler to take advantage of these speculative sorts of optimizations just as .NET does. Granted, PGO is annoying to set up compared to the .NET VM, which "just works". PGO'd Rust is deployed in production, though. [1]: https://doc.rust-lang.org/rustc/profile-guided-optimization.html https://doc.rust-lang.org/rustc/profile-guided-optimization....
- darksaints 5y ago
  I'm not sure about this specific case of Rust vs .NET, but the theoretical benefits of JITs never really seem to play out in practice, except for dynamic languages that can get really big improvements by using types speculatively. I think that one of the things that JIT proponents seem to miss is that JIT compilers have practical limits to the scope of analyses and optimizations that can be done...quick, single pass analyses, basic inclining, etc. An AOT isn't relying on competing with runtime resources to analyze and optimize code, and it can take a lot of time to do whatever it needs to. I've found that AOT with PGO is the performance holy grail for just about any use case.
  - int_19h 5y ago
    There's one big benefit that JIT brings to the table that is not at all theoretical: it can devirtualize and inline across shared libraries. This doesn't matter if you link everything statically, of course, but that's not always desirable. (Another benefit is that it allows for generic virtual methods, but that's only indirectly a perf thing.)
  - hackerfromthefu 5y ago
    With .NET it's been really interesting watching the journey to greater and greater performance - there's been so many performance optimizations that weren't implemented for 1-2 decades. So .. watch this space, possibly JIT performance will get improved more when they run out of lower hanging fruit.
celdon25 5y ago
> the runtime information and JIT compilation may allow it to make better optimisations That's a very, very slim "may", at least before .NET 6 (I don't keep up with .NET anymore.) https://web.archive.org/web/20100627105951/http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/451845.aspx https://web.archive.org/web/20100627105951/http://blogs.msdn...
deleted 5y ago
[deleted]
tialaramex 5y ago
> C# can be written in a way that stack allocates almost everything (much like Rust) I'd be surprised if this works in practice because the String processing in C# is surely going to keep making Heap objects ? You're immediately in a better place here in Rust because people (sensibly) keep developing standards encoded in UTF-8 and so the bytes on the wire are Rust's built-in str type, whereas C# needs to turn them into UTF-16 and store that somewhere as a String.
- briHass 5y ago
  > I'd be surprised if this works in practice because the String processing in C# is surely going to keep making Heap objects ? The new Span<T>, specifically Span<char>, stuff allows you to slice and read strings without creating new objects, and string has both a c-tor for a (readonly) span and a Create method that takes a delegate that allows you to fill the string already allocated on the heap.
  - tialaramex 5y ago
    I didn't know about Span<T>, but it makes sense to give C# slices somehow. However so far as I've seen while writing C# popular APIs want an actual String and they won't take these slices as a substitute? The ergonomics seem poor. Maybe I'm mistaken and magically my C# code which says "string" everywhere is actually converted at runtime to use Span<char> and go real fast? But it doesn't look like it. The Rust APIs really do take the slice reference &str, it's just normal in Rust to say &str unless you very specifically want a mutable String for some reason (e.g. you're going to insert stuff into it)
- dehrmann 5y ago
  I'm not sure if .NET can do this, but Java is similar, and it can do escape analysis to keep more things on the stack.
littlestymaar 5y ago
> First, C# can be written in a way that stack allocates almost everything (much like Rust) While it works (and game developers using Unity tend to use that A LOT to get decent performances), it's also an enormous pain in the ass because you lose most of the “modern” features of C#.

Yoric 5y ago

I'm a big Rust fan but I fully expect that C# can beat Rust in some benchmarks and actually in some useful scenarios. However, claiming outright that .Net outperforms Rust feels like an apple-to-petticoat comparison.

DoctorOW 5y ago

Only if you're including compile time in the benchmarks. Binary to binary, JIT is a great example of Rust having a compile-time optimization that .NET implements at runtime.

Yoric 5y ago
Well, some optimizations can only be implemented at runtime, so comparing Rust and C# without knowing the actual scenario doesn't seem to make much sense.
woodruffw 5y ago
Optimizing compilers and JITs are difficult to compare directly: JITs have optimization pressures (e.g., selecting instructions/register slots as rapidly as possible) that AOT compilers don't (and vice versa), and (similarly) tend to have simpler IRs. In general, even the best JIT is going to underperform an AOT optimizing compiler for those reasons. Microbenchmarks (and compiler quality) will always vary, but the macro picture is difficult to change.

pcwalton 5y ago

> the runtime information and JIT compilation may allow it to make better optimisations. In practice this mostly means speculative devirtualization. This is absolutely true for C++, which tends to use virtual methods a lot, but Rust doesn't use virtual methods much. Moreover, profile-guided optimization (PGO), which Rust supports [1], allows the Rust compiler to take advantage of these speculative sorts of optimizations just as .NET does. Granted, PGO is annoying to set up compared to the .NET VM, which "just works". PGO'd Rust is deployed in production, though. [1]: https://doc.rust-lang.org/rustc/profile-guided-optimization.html https://doc.rust-lang.org/rustc/profile-guided-optimization....

darksaints 5y ago
I'm not sure about this specific case of Rust vs .NET, but the theoretical benefits of JITs never really seem to play out in practice, except for dynamic languages that can get really big improvements by using types speculatively. I think that one of the things that JIT proponents seem to miss is that JIT compilers have practical limits to the scope of analyses and optimizations that can be done...quick, single pass analyses, basic inclining, etc. An AOT isn't relying on competing with runtime resources to analyze and optimize code, and it can take a lot of time to do whatever it needs to. I've found that AOT with PGO is the performance holy grail for just about any use case.
- int_19h 5y ago
  There's one big benefit that JIT brings to the table that is not at all theoretical: it can devirtualize and inline across shared libraries. This doesn't matter if you link everything statically, of course, but that's not always desirable. (Another benefit is that it allows for generic virtual methods, but that's only indirectly a perf thing.)
- hackerfromthefu 5y ago
  With .NET it's been really interesting watching the journey to greater and greater performance - there's been so many performance optimizations that weren't implemented for 1-2 decades. So .. watch this space, possibly JIT performance will get improved more when they run out of lower hanging fruit.

celdon25 5y ago

> the runtime information and JIT compilation may allow it to make better optimisations That's a very, very slim "may", at least before .NET 6 (I don't keep up with .NET anymore.) https://web.archive.org/web/20100627105951/http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/451845.aspx https://web.archive.org/web/20100627105951/http://blogs.msdn...

deleted 5y ago

[deleted]

tialaramex 5y ago

> C# can be written in a way that stack allocates almost everything (much like Rust) I'd be surprised if this works in practice because the String processing in C# is surely going to keep making Heap objects ? You're immediately in a better place here in Rust because people (sensibly) keep developing standards encoded in UTF-8 and so the bytes on the wire are Rust's built-in str type, whereas C# needs to turn them into UTF-16 and store that somewhere as a String.

briHass 5y ago
> I'd be surprised if this works in practice because the String processing in C# is surely going to keep making Heap objects ? The new Span<T>, specifically Span<char>, stuff allows you to slice and read strings without creating new objects, and string has both a c-tor for a (readonly) span and a Create method that takes a delegate that allows you to fill the string already allocated on the heap.
- tialaramex 5y ago
  I didn't know about Span<T>, but it makes sense to give C# slices somehow. However so far as I've seen while writing C# popular APIs want an actual String and they won't take these slices as a substitute? The ergonomics seem poor. Maybe I'm mistaken and magically my C# code which says "string" everywhere is actually converted at runtime to use Span<char> and go real fast? But it doesn't look like it. The Rust APIs really do take the slice reference &str, it's just normal in Rust to say &str unless you very specifically want a mutable String for some reason (e.g. you're going to insert stuff into it)
dehrmann 5y ago
I'm not sure if .NET can do this, but Java is similar, and it can do escape analysis to keep more things on the stack.

littlestymaar 5y ago

> First, C# can be written in a way that stack allocates almost everything (much like Rust) While it works (and game developers using Unity tend to use that A LOT to get decent performances), it's also an enormous pain in the ass because you lose most of the “modern” features of C#.