4 ms·

Embedded systems often have real time constraints that don't mix well with most garbage collectors. That being said, there are plenty hobby (and commercial) pr

Embedded systems often have real time constraints that don't mix well with most garbage collectors. That being said, there are plenty hobby (and commercial) projects where .NET is perfect.

londons_explore 7y ago
True, but one mans 'realtime' is very different than another. Most microcontrollers today don't even have cycle-accurate memory access guarantees, so it's impossible to do timing more accurate than tens of nanoseconds. Things requiring low latency and accurate timing always end up hardware assisted (USB controllers, PWM hardware, UART serializers, and a million more examples).
- learc83 7y ago
  For the vast majority of realtime tasks accuracy of a few tens of nanoseconds is fine, but random 50ms delays for GC aren't.
  - pjmlp 7y ago
    That is why Java variants for embedded soft real time deployments have completely different kind of GC implementations like something as OpenJDK or IBM J9, and expose regions and access to unamaged memory. Likewise .NET's support for value types and low level programming also means not everything needs to be GC-allocated.
    - learc83 7y ago
      That's all true. But at some point if you really need to avoid GC, you end up writing in a subset of C# that is so limited, it's really just C. Most people don't have those kinds of performance considerations. I use C# for soft realtime all the time, but in the instances when I have done actual realtime embedded work, I just used C.
- blackguardx 7y ago
  Do you have a source for that? Are you talking about accessing internal SRAM, internal Flash, or external memory?
  - londons_explore 7y ago
    Any architecture with a CPU cache is generally not cycle accurate (since at the time you compile your code you can't fully predict if your data will be in the cache or not). Many pipelined architectures do not define in datasheets exactly what can cause a pipeline stall - usually they provide rough guidance, but not information about corner cases. Branch prediction likewise is rarely fully defined in the datasheets. Some architectures have some operations which are data dependant - for example, "division takes 6-8 cycles". The software developer can't be sure it will be 6, 7, or 8, and if they were to measure performance, they'd be relying on undefined performance behaviour, since a new revision of the same model of chip could change performance. Also, most architectures with DMA aren't cycle accurate because the SRAM is single-ported, so you get a CPU stall if you happen to read memory in the same cycle as a hardware device needs more data.
moron4hire 7y ago
Even when writing C or C++ for an MCU, you're going to avoid heap allocation as much as possible, so the same design is going to lead to a .NET app that has no GC collections as well. I write VR apps in C# for a living. Avoiding the GC is not that hard.
- learc83 7y ago
  I write games in C#, but I've worked in embedded systems. The thing is most methods for avoiding GC are just round about ways of doing manual memory management. And games are soft realtime, so a dropped frame every now and then is generally acceptable. Also look at the new Unity DOTS stuff. They are building their own high performance subset of C# where memory layout and data locality are first class concerns and adding in mechanisms for manual memory management.
  - moron4hire 7y ago
    In VR, dropped frames are quite noticeable. Even with Asynchronous Time Warp, while you won't get hitches in your view of the scene, you get hitches in anything that is animated. So, for example, waiving your controller around, it'll start to skip around. And you're always waiving the controller around. Nobody is a stone-still statue. It's not really "round about ways of doing manual memory management". You can heap-allocate as much as you want, as long as you aren't doing it in a critical hot path. Object pooling is good practice, regardless of language and runtime, for real time anything. I do my major allocations and deallocactions during scene transitions, where the view is faded out already because making visible scene transitions in VR is nausea-inducing on its own. And from a project management perspective, I've found it best to avoid using as much of Unity's built-in stuff as possible. Most of what they create are just garbage reimplementations of stuff that already exists in the .NET ecosystem. I'm long-term going to get off of Unity. I'll eventually be building my own system on top of Xamarin, as I excise more and more of Unity out of my projects. I've already had to code my way around so many of their systems just to make quality apps that don't hiccup when things load that I don't really have a lot left to do. All of the VR vendors provide C APIs for interfacing with their systems, which are the actual, first-class systems. Providing a P/Invoke layer on top of that won't be too hard. And Xamarin already provides wrappers around ARKit and ARCore. Shader-wise, there's not enough processing budget to do anything but very basic shaders that I already know how to write, anyway. Any of the more advanced shaders that work well in VR are open-source. Light baking can be done in Blender directly. Unity's Audio pipeline is really bad. I have 50% of a reimplementation already. And again, spatialization is provided by the VR vendors, so there is very little of Unity's own code running in my audio systems anymore. Sure, I wouldn't have learned how to do all of this stuff if I hadn't started with Unity, but once you get into trying to build scalable apps with pleasant user experiences, you have to ditch so much of Unity's built in stuff that it starts to look less and less like a good value proposition to continue to put up with the rest of their stuff, considering how buggy it can be.
fortran77 7y ago
We run Erlang on bare metal for "soft real time" applications and there's no problem with it.
- yellowapple 7y ago
  Whoa. The only project I know of that allowed that is GRiSP. Is that what y'all are using? Or is this some even-more-exotic bare-metal Erlang implementation?
  - fortran77 7y ago
    There's a loader/booter based on RTEMS. Very similar to GRiSP, but not on GRiSP platform. There's also LING for Erlang on Xen which isn't supported much but some still use it.
    - yellowapple 7y ago
      I'll have to check out RTEMS. Knew about Ling / Erlang-on-Xen, but figure that's a bit different from proper bare-metal deployment (though I guess so RTEMS would be), given that it expects Xen running underneath.
- learc83 7y ago
  Plenty of people, myself included, write games in C#. But it's soft realtime so occasional frame drops aren't a huge deal. And we are constantly doing our own manual memory management with things like object pooling to avoid the GC whenever possible.
  - fortran77 7y ago
    Exactly! The Rust people run around telling everyone that GC is evil, but I am quite productive in F# and Erlang with a GC language, and it's a breeze to program on these platforms. There are many games in C# that even run on iPhones and are very performant.

Embedded systems often have real time constraints that don't mix well with most garbage collectors. That being said, there are plenty hobby (and commercial) projects where .NET is perfect.

londons_explore 7y ago

True, but one mans 'realtime' is very different than another. Most microcontrollers today don't even have cycle-accurate memory access guarantees, so it's impossible to do timing more accurate than tens of nanoseconds. Things requiring low latency and accurate timing always end up hardware assisted (USB controllers, PWM hardware, UART serializers, and a million more examples).

learc83 7y ago
For the vast majority of realtime tasks accuracy of a few tens of nanoseconds is fine, but random 50ms delays for GC aren't.
- pjmlp 7y ago
  That is why Java variants for embedded soft real time deployments have completely different kind of GC implementations like something as OpenJDK or IBM J9, and expose regions and access to unamaged memory. Likewise .NET's support for value types and low level programming also means not everything needs to be GC-allocated.
  - learc83 7y ago
    That's all true. But at some point if you really need to avoid GC, you end up writing in a subset of C# that is so limited, it's really just C. Most people don't have those kinds of performance considerations. I use C# for soft realtime all the time, but in the instances when I have done actual realtime embedded work, I just used C.
blackguardx 7y ago
Do you have a source for that? Are you talking about accessing internal SRAM, internal Flash, or external memory?
- londons_explore 7y ago
  Any architecture with a CPU cache is generally not cycle accurate (since at the time you compile your code you can't fully predict if your data will be in the cache or not). Many pipelined architectures do not define in datasheets exactly what can cause a pipeline stall - usually they provide rough guidance, but not information about corner cases. Branch prediction likewise is rarely fully defined in the datasheets. Some architectures have some operations which are data dependant - for example, "division takes 6-8 cycles". The software developer can't be sure it will be 6, 7, or 8, and if they were to measure performance, they'd be relying on undefined performance behaviour, since a new revision of the same model of chip could change performance. Also, most architectures with DMA aren't cycle accurate because the SRAM is single-ported, so you get a CPU stall if you happen to read memory in the same cycle as a hardware device needs more data.

moron4hire 7y ago

Even when writing C or C++ for an MCU, you're going to avoid heap allocation as much as possible, so the same design is going to lead to a .NET app that has no GC collections as well. I write VR apps in C# for a living. Avoiding the GC is not that hard.

learc83 7y ago
I write games in C#, but I've worked in embedded systems. The thing is most methods for avoiding GC are just round about ways of doing manual memory management. And games are soft realtime, so a dropped frame every now and then is generally acceptable. Also look at the new Unity DOTS stuff. They are building their own high performance subset of C# where memory layout and data locality are first class concerns and adding in mechanisms for manual memory management.
- moron4hire 7y ago
  In VR, dropped frames are quite noticeable. Even with Asynchronous Time Warp, while you won't get hitches in your view of the scene, you get hitches in anything that is animated. So, for example, waiving your controller around, it'll start to skip around. And you're always waiving the controller around. Nobody is a stone-still statue. It's not really "round about ways of doing manual memory management". You can heap-allocate as much as you want, as long as you aren't doing it in a critical hot path. Object pooling is good practice, regardless of language and runtime, for real time anything. I do my major allocations and deallocactions during scene transitions, where the view is faded out already because making visible scene transitions in VR is nausea-inducing on its own. And from a project management perspective, I've found it best to avoid using as much of Unity's built-in stuff as possible. Most of what they create are just garbage reimplementations of stuff that already exists in the .NET ecosystem. I'm long-term going to get off of Unity. I'll eventually be building my own system on top of Xamarin, as I excise more and more of Unity out of my projects. I've already had to code my way around so many of their systems just to make quality apps that don't hiccup when things load that I don't really have a lot left to do. All of the VR vendors provide C APIs for interfacing with their systems, which are the actual, first-class systems. Providing a P/Invoke layer on top of that won't be too hard. And Xamarin already provides wrappers around ARKit and ARCore. Shader-wise, there's not enough processing budget to do anything but very basic shaders that I already know how to write, anyway. Any of the more advanced shaders that work well in VR are open-source. Light baking can be done in Blender directly. Unity's Audio pipeline is really bad. I have 50% of a reimplementation already. And again, spatialization is provided by the VR vendors, so there is very little of Unity's own code running in my audio systems anymore. Sure, I wouldn't have learned how to do all of this stuff if I hadn't started with Unity, but once you get into trying to build scalable apps with pleasant user experiences, you have to ditch so much of Unity's built in stuff that it starts to look less and less like a good value proposition to continue to put up with the rest of their stuff, considering how buggy it can be.

fortran77 7y ago

We run Erlang on bare metal for "soft real time" applications and there's no problem with it.

yellowapple 7y ago
Whoa. The only project I know of that allowed that is GRiSP. Is that what y'all are using? Or is this some even-more-exotic bare-metal Erlang implementation?
- fortran77 7y ago
  There's a loader/booter based on RTEMS. Very similar to GRiSP, but not on GRiSP platform. There's also LING for Erlang on Xen which isn't supported much but some still use it.
  - yellowapple 7y ago
    I'll have to check out RTEMS. Knew about Ling / Erlang-on-Xen, but figure that's a bit different from proper bare-metal deployment (though I guess so RTEMS would be), given that it expects Xen running underneath.
learc83 7y ago
Plenty of people, myself included, write games in C#. But it's soft realtime so occasional frame drops aren't a huge deal. And we are constantly doing our own manual memory management with things like object pooling to avoid the GC whenever possible.
- fortran77 7y ago
  Exactly! The Rust people run around telling everyone that GC is evil, but I am quite productive in F# and Erlang with a GC language, and it's a breeze to program on these platforms. There are many games in C# that even run on iPhones and are very performant.