3 ms·

^^^ Yes. I see LOB apps and web-services being (re-)written in Rust from very high-level langs at great cognitive cost but little runtime benefit. Rust by all

^^^ Yes. I see LOB apps and web-services being (re-)written in Rust from very high-level langs at great cognitive cost but little runtime benefit. Rust by all means should be treated as a better C(++) for applications where is is necessary -- but it rarely is. And most Rust code I see is simple and context/request-bounded - basically it amounts to a overly-complicated version of creating a private heap for the duration of a request, and then throwing it away, as making Rust happy with even mildly interesting data-structures that are expected to be long-running is a chore. C# (per your example) is not orders-of-magnitude away from from C++ perf like Python is, but is w/in a very small constant factor, and often even faster for poorly-written C++ as GC is more efficient than calling copy c'tors where they needn't be called, for example. And if you introduce features such as Span<> (and friends) and ref returns into your C# where you need them, you now how have safe GC-free/reduced code with perf that rivals Rust in the sections of code where you need it, with full GC as a backup.

gameswithgo 6y ago
Well written C# definitely has a performance ceiling that greatly reduces what things need C++ or Rust, but idiomatic C#, what most people actually write, what is taught and encouraged is pretty slow. (lots of linq, arrays of pointers to objects on the heap, that are iterated over with iterators instead of directly, calling virtual functions that are not devirtualized, etc etc etc) One thing I like about Rust is the idiomatic way is usually very close to the fastest way. There are exceptions of course. But it you tend to get steered to efficient solutions.
- thelazydogsback 6y ago
  Agree with all. But if 80% of your code can be performant with "ideomatic' code, 15% needing a bit more attention (such as not making use of certain abstractions, like link-to-objects, etc.), with the other 5% requiring diligent attention (Span, etc.) - then your making gradual perf gains as you wish, all within the same language, runtime, and memory pool. This is much better than a re-write and dealing with FFI, or just as likely, full-on serialization between your old code and Rust code. With that said, there isn't much of an excuse for non-0-cost enumerators, etc. -- given that refactoring tools switch between foreach, linq, indexing or ptr/spanning, you'd think the compiler-chain or jitter could do the same. Roslyn is a better back-end for meta-programming, but it's too bad MS denies us the benefits of surfacing meta-programming to the language or at least tool level, or we'd have tools that could easily convert linq to highly optimized code. You could also have compiler-enforced "levels" of C# code that had restricted features/semantics, such as "alloc-free", etc. - right now the choice is just "default" or "unsafe".
  - bob1029 6y ago
    I think having a mode where LOH allocations are treated as a runtime exception (i.e. with a helpful exception message pointing to the offending object type) could help to guide developers down this path really well. Something like: "LOH allocation detected for object 'MyNamespace.MyObject'. Attempted allocation bytes: 90K (maximum 85,000 bytes)." Then one level up from that restriction would be the totally alloc-free approach you mention which could potentially mean the GC could be put into a special idle/framework-only mode. For alloc-free, I believe you could enforce this at compile time, as opposed to run-time for the LOH condition.
    - DaiPlusPlus 6y ago
      Alloc-free would be nice if the CLR/CLI supported it, but I understand there’s too many major architectural changes required, e.g. to allow class object instances to live in the stack and limit their lifetime to prevent an invalid object reference. Even today you can’t `stackalloc` an array unless you’re using `unsafe`.
- DaiPlusPlus 6y ago
  I’m going to disagree with you that idiomatic C# is somehow unnecessarily “slow”. The performance overhead of a virtual vs non-virtual call on the CLR is negligible - same as with C++. For proof, look at Direct3D which is performance-critical, yet Direct3D’s API is based on COM which is all about vtable-calls. Linq itself is also very decent. I won’t argue that Linq is perfect (e.g. suboptimal list allocations when the total output length can be known in-advance), but its hardly “slow” - certainly not enough to impact any production workloads - you’d only observe a difference between hand-written loops and a Linq expression in a contrived synthetic benchmark.
  - jfkebwjsbx 6y ago
    > Direct3D’s API is based on COM which is all about vtable-calls. It isn’t. It looks like COM, but it isn’t.
    - DaiPlusPlus 6y ago
      Did things change with DX12? Just asking because this article is quite clear about how DirectX is all about COM: https://docs.microsoft.com/en-us/windows/win32/prog-dx-with-com https://docs.microsoft.com/en-us/windows/win32/prog-dx-with-... > The Microsoft Component Object Model (COM) is an object-oriented programming model used by several technologies, including the bulk of the DirectX API surface. For that reason, you (as a DirectX developer) inevitably use COM when you program DirectX.
      - jfkebwjsbx 6y ago
        DirectX yes, Direct3D no. I am not sure about D3D9, but 10 and 11 and 12 are not COM.

gameswithgo 6y ago

Well written C# definitely has a performance ceiling that greatly reduces what things need C++ or Rust, but idiomatic C#, what most people actually write, what is taught and encouraged is pretty slow. (lots of linq, arrays of pointers to objects on the heap, that are iterated over with iterators instead of directly, calling virtual functions that are not devirtualized, etc etc etc) One thing I like about Rust is the idiomatic way is usually very close to the fastest way. There are exceptions of course. But it you tend to get steered to efficient solutions.

thelazydogsback 6y ago
Agree with all. But if 80% of your code can be performant with "ideomatic' code, 15% needing a bit more attention (such as not making use of certain abstractions, like link-to-objects, etc.), with the other 5% requiring diligent attention (Span, etc.) - then your making gradual perf gains as you wish, all within the same language, runtime, and memory pool. This is much better than a re-write and dealing with FFI, or just as likely, full-on serialization between your old code and Rust code. With that said, there isn't much of an excuse for non-0-cost enumerators, etc. -- given that refactoring tools switch between foreach, linq, indexing or ptr/spanning, you'd think the compiler-chain or jitter could do the same. Roslyn is a better back-end for meta-programming, but it's too bad MS denies us the benefits of surfacing meta-programming to the language or at least tool level, or we'd have tools that could easily convert linq to highly optimized code. You could also have compiler-enforced "levels" of C# code that had restricted features/semantics, such as "alloc-free", etc. - right now the choice is just "default" or "unsafe".
- bob1029 6y ago
  I think having a mode where LOH allocations are treated as a runtime exception (i.e. with a helpful exception message pointing to the offending object type) could help to guide developers down this path really well. Something like: "LOH allocation detected for object 'MyNamespace.MyObject'. Attempted allocation bytes: 90K (maximum 85,000 bytes)." Then one level up from that restriction would be the totally alloc-free approach you mention which could potentially mean the GC could be put into a special idle/framework-only mode. For alloc-free, I believe you could enforce this at compile time, as opposed to run-time for the LOH condition.
  - DaiPlusPlus 6y ago
    Alloc-free would be nice if the CLR/CLI supported it, but I understand there’s too many major architectural changes required, e.g. to allow class object instances to live in the stack and limit their lifetime to prevent an invalid object reference. Even today you can’t `stackalloc` an array unless you’re using `unsafe`.
DaiPlusPlus 6y ago
I’m going to disagree with you that idiomatic C# is somehow unnecessarily “slow”. The performance overhead of a virtual vs non-virtual call on the CLR is negligible - same as with C++. For proof, look at Direct3D which is performance-critical, yet Direct3D’s API is based on COM which is all about vtable-calls. Linq itself is also very decent. I won’t argue that Linq is perfect (e.g. suboptimal list allocations when the total output length can be known in-advance), but its hardly “slow” - certainly not enough to impact any production workloads - you’d only observe a difference between hand-written loops and a Linq expression in a contrived synthetic benchmark.
- jfkebwjsbx 6y ago
  > Direct3D’s API is based on COM which is all about vtable-calls. It isn’t. It looks like COM, but it isn’t.
  - DaiPlusPlus 6y ago
    Did things change with DX12? Just asking because this article is quite clear about how DirectX is all about COM: https://docs.microsoft.com/en-us/windows/win32/prog-dx-with-com https://docs.microsoft.com/en-us/windows/win32/prog-dx-with-... > The Microsoft Component Object Model (COM) is an object-oriented programming model used by several technologies, including the bulk of the DirectX API surface. For that reason, you (as a DirectX developer) inevitably use COM when you program DirectX.
    - jfkebwjsbx 6y ago
      DirectX yes, Direct3D no. I am not sure about D3D9, but 10 and 11 and 12 are not COM.