3 ms·

> Pouring effort into C++ does not guarantee safety. Indeed, but porting to C# does. For many practical applications, modern C# is already a language with C pe

> Pouring effort into C++ does not guarantee safety. Indeed, but porting to C# does. For many practical applications, modern C# is already a language with C performance. The only large area where C# lags behind is SIMD. They made a good progress in .NET 3 and 5, but still somewhat worse than C/C++ with intrinsics. Here’s a library which implements media player component for ARM Linux: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo#performance https://github.com/Const-me/Vrmac/tree/master/VrmacVideo#per... It calls native code to present decoded video frames with GLES, and decode audio with third-party DLLs. Also consumes kernel C APIs like V4L2, ALSA, message queues from librt.so, and a few things from libc.so. Everything else is in C#: file I/O, containers parsing, decoders configuration, multithreading, buffering, A/V sync. The performance is same as VLC player which is written in C.

wffurr 6y ago
C# ties you to CLR and is also garbage collected by default. That’s very different from C++ and Rust both.
- Const-me 6y ago
  > C# ties you to CLR C++ and Rust have runtimes as well. For C++ that’s normally a DLL like libstdc++ or msvcrt. CLR is larger but still reasonable, for 64-bit Windows VC_redist.x64.exe is 14 MB, dotnet-runtime-3.1.13-win-x64.exe is 25 MB. > and is also garbage collected by default By default yes, but that’s avoidable. Modern .NET with their spans, value tuples, ref structs, ArrayPool, etc., make it relatively easy to write C# code which doesn’t allocate much. Or even at all, as you can see on the link in my previous comment.
  - pianoben 6y ago
    I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite everything that isn't already defined in terms of `Memory` or `Span`, you can do it, but that's a _tall_ order. Even supposing you still mange to write a whole program that doesn't allocate dynamic memory, or that quickly stabilizes around a finite `ArrayPool`. You're still pulling in all the runtime GC machinery. Further, the minute someone _else_ contributes code, you run the risk of allocating again. As much as I love C#, _this isn't its niche_.
    - Const-me 6y ago
      > vast majority of extant .NET APIs encourage or require allocating memory dynamically A lot of APIs in modern .NET already supports spans. They can be backed by anything, not just GC-managed memory. For that project, some of these spans are backed by the memory mapped by V4L2 or ALSA API calls. Others are backed by unmanaged buffers allocated on startup with Marshal.AllocHGlobal. For small temporary stuff I use stackalloc, e.g. both mp4 and mkv use tons of variable-length encoded integers. > the minute someone _else_ contributes code, you run the risk of allocating again. Good point. On the other hand, someone else contributing code can introduce any bugs at all, not just GC-related performance issues. > As much as I love C#, _this isn't its niche_. A while ago some people were saying the same about C, and were instead coding assembly :-)
  - jayd16 6y ago
    Relevant to the topic, annoyingly, you still can't cancel a task without a ton of garbage.
    - Const-me 6y ago
      You can easily forget pending tasks. That’s a single line of code like this: task.ContinueWith( t => { }, TaskContinuationOptions.OnlyOnFaulted ); However, graceful cancellation is indeed hard. Doable in .NET but not easy, you gonna need to manually pass these cancellation tokens all the way down. Do you have an example of a language/runtime/etc where the cancellation's easy? It's easy to kill processes from the outside, but even for threads it's borderline impossible without horrible side effects.
      - jayd16 6y ago
        I don't. I don't use Rust but I'm quite sad I can't use this system in C# without paying for a stacktrace/exception. Cancellation tokens sure...but many libraries will still throw the cancellation exception.
SAI_Peregrinus 6y ago
Last I checked STM32 microcontrollers can't run .Net, and thus can't use C#. They can run Rust. Rust's embedded and OS-level capabilities are a big point in its favor, particularly over something like C#.
- Const-me 6y ago
  Indeed, you need a reasonably capable OS kernel to use .NET runtime. And enough RAM. And I wouldn’t want .NET for hard realtime use cases. Even in embedded, for some products the tradeoff is good enough. A while ago I’ve shipped embedded software that uses .NET Core and runs on RK3288, worked quite well for us. BTW, do you have good experience with Rust on bare metal STM32? I would expect STM-supported C toolset and libraries to be generally better?
  - SAI_Peregrinus 6y ago
    I find the Rust embedded-hal to be quite good. STM's HAL code is a horrible inefficient mess, though their LL library isn't bad. I'd much rather use Rust's hal crates and probe-run. That said, CubeMX's configuration tool is very nice. But that's used (hopefully) once at board bringup and never again, so not worth sticking with C for.
- pjmlp 6y ago
  Depends, .NET => https://www.wildernesslabs.co/hardware https://www.wildernesslabs.co/hardware Oberon => https://www.astrobe.com/boards.htm https://www.astrobe.com/boards.htm Java https://www.microej.com/ https://www.microej.com/ https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc

wffurr 6y ago

C# ties you to CLR and is also garbage collected by default. That’s very different from C++ and Rust both.

Const-me 6y ago
> C# ties you to CLR C++ and Rust have runtimes as well. For C++ that’s normally a DLL like libstdc++ or msvcrt. CLR is larger but still reasonable, for 64-bit Windows VC_redist.x64.exe is 14 MB, dotnet-runtime-3.1.13-win-x64.exe is 25 MB. > and is also garbage collected by default By default yes, but that’s avoidable. Modern .NET with their spans, value tuples, ref structs, ArrayPool, etc., make it relatively easy to write C# code which doesn’t allocate much. Or even at all, as you can see on the link in my previous comment.
- pianoben 6y ago
  I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite everything that isn't already defined in terms of `Memory` or `Span`, you can do it, but that's a _tall_ order. Even supposing you still mange to write a whole program that doesn't allocate dynamic memory, or that quickly stabilizes around a finite `ArrayPool`. You're still pulling in all the runtime GC machinery. Further, the minute someone _else_ contributes code, you run the risk of allocating again. As much as I love C#, _this isn't its niche_.
  - Const-me 6y ago
    > vast majority of extant .NET APIs encourage or require allocating memory dynamically A lot of APIs in modern .NET already supports spans. They can be backed by anything, not just GC-managed memory. For that project, some of these spans are backed by the memory mapped by V4L2 or ALSA API calls. Others are backed by unmanaged buffers allocated on startup with Marshal.AllocHGlobal. For small temporary stuff I use stackalloc, e.g. both mp4 and mkv use tons of variable-length encoded integers. > the minute someone _else_ contributes code, you run the risk of allocating again. Good point. On the other hand, someone else contributing code can introduce any bugs at all, not just GC-related performance issues. > As much as I love C#, _this isn't its niche_. A while ago some people were saying the same about C, and were instead coding assembly :-)
- jayd16 6y ago
  Relevant to the topic, annoyingly, you still can't cancel a task without a ton of garbage.
  - Const-me 6y ago
    You can easily forget pending tasks. That’s a single line of code like this: task.ContinueWith( t => { }, TaskContinuationOptions.OnlyOnFaulted ); However, graceful cancellation is indeed hard. Doable in .NET but not easy, you gonna need to manually pass these cancellation tokens all the way down. Do you have an example of a language/runtime/etc where the cancellation's easy? It's easy to kill processes from the outside, but even for threads it's borderline impossible without horrible side effects.
    - jayd16 6y ago
      I don't. I don't use Rust but I'm quite sad I can't use this system in C# without paying for a stacktrace/exception. Cancellation tokens sure...but many libraries will still throw the cancellation exception.

SAI_Peregrinus 6y ago

Last I checked STM32 microcontrollers can't run .Net, and thus can't use C#. They can run Rust. Rust's embedded and OS-level capabilities are a big point in its favor, particularly over something like C#.

Const-me 6y ago
Indeed, you need a reasonably capable OS kernel to use .NET runtime. And enough RAM. And I wouldn’t want .NET for hard realtime use cases. Even in embedded, for some products the tradeoff is good enough. A while ago I’ve shipped embedded software that uses .NET Core and runs on RK3288, worked quite well for us. BTW, do you have good experience with Rust on bare metal STM32? I would expect STM-supported C toolset and libraries to be generally better?
- SAI_Peregrinus 6y ago
  I find the Rust embedded-hal to be quite good. STM's HAL code is a horrible inefficient mess, though their LL library isn't bad. I'd much rather use Rust's hal crates and probe-run. That said, CubeMX's configuration tool is very nice. But that's used (hopefully) once at board bringup and never again, so not worth sticking with C for.
pjmlp 6y ago
Depends, .NET => https://www.wildernesslabs.co/hardware https://www.wildernesslabs.co/hardware Oberon => https://www.astrobe.com/boards.htm https://www.astrobe.com/boards.htm Java https://www.microej.com/ https://www.microej.com/ https://www.aicas.com/wp/ https://www.aicas.com/wp/ https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc