3 ms·

I think the article is pointing out that C# offers many of the benefits of low level languages like C/C++, including some control over memory layout, passing by

I think the article is pointing out that C# offers many of the benefits of low level languages like C/C++, including some control over memory layout, passing by ref, calling conventions with P/invoke, and soon, SIMD intrinsics.

Gibbon1 8y ago
I tend to think being able to locate, describe and manipulate objects in native memory tends to define a low level language as is the ability to control latency. These are the reasons most garbage collected languages aren't low level. Garbage collection traditional means you can't meet hard latency contracts. And by definition you have no control over where garbage collected objects are in memory.
- nearbuy 8y ago
  You can actually do some of that by pinning objects in unsafe blocks along with using the FieldOffset attribute. This is where the term "low level" is a bit ambiguous and relative. If you're trying to bit bang some serial protocol on a microcontroller with tight timings, C# and the GC are going to give you a hard time. But even C might give you a hard time here. I've had to drop down to inline assembly because it's much easier to count the cycles it'll take and insert a few nops where necessary to get the timing right. Then, if you're on a non-realtime OS like Windows or Linux, no language is going to give you hard latency constraints. Going further, it would be difficult to bit bang with tight timing constraints on x86 altogether due to speculative execution. So from that perspective, C, x86, and modern operating systems might all be too high level to achieve your goal. But for other goals, you might have a different answer. One interesting example was Xbox 360 games. Game developers have traditionally used C++, because they have performance and latency constraints: if you're targeting 60 fps, you don't want any frames taking more than 16.6 ms. Indie developers had to use C# to make games for the 360. Unfortunately, the .Net Compact Framework it used had an old, slow, non-generational GC, which would cause hitches. So games would do one of two things to avoid hitches. Either they'd design their games to make zero allocations per frame, or they'd design their memory layout to be very simple so the GC would run fast. Structs are very helpful here because they don't generally allocate on the heap. So was C# low level enough for game development on the Xbox 360? I'd say mostly. It gave you some hassle with the GC, but ultimately you had enough control over performance and latency to make it work.

Gibbon1 8y ago

I tend to think being able to locate, describe and manipulate objects in native memory tends to define a low level language as is the ability to control latency. These are the reasons most garbage collected languages aren't low level. Garbage collection traditional means you can't meet hard latency contracts. And by definition you have no control over where garbage collected objects are in memory.

nearbuy 8y ago
You can actually do some of that by pinning objects in unsafe blocks along with using the FieldOffset attribute. This is where the term "low level" is a bit ambiguous and relative. If you're trying to bit bang some serial protocol on a microcontroller with tight timings, C# and the GC are going to give you a hard time. But even C might give you a hard time here. I've had to drop down to inline assembly because it's much easier to count the cycles it'll take and insert a few nops where necessary to get the timing right. Then, if you're on a non-realtime OS like Windows or Linux, no language is going to give you hard latency constraints. Going further, it would be difficult to bit bang with tight timing constraints on x86 altogether due to speculative execution. So from that perspective, C, x86, and modern operating systems might all be too high level to achieve your goal. But for other goals, you might have a different answer. One interesting example was Xbox 360 games. Game developers have traditionally used C++, because they have performance and latency constraints: if you're targeting 60 fps, you don't want any frames taking more than 16.6 ms. Indie developers had to use C# to make games for the 360. Unfortunately, the .Net Compact Framework it used had an old, slow, non-generational GC, which would cause hitches. So games would do one of two things to avoid hitches. Either they'd design their games to make zero allocations per frame, or they'd design their memory layout to be very simple so the GC would run fast. Structs are very helpful here because they don't generally allocate on the heap. So was C# low level enough for game development on the Xbox 360? I'd say mostly. It gave you some hassle with the GC, but ultimately you had enough control over performance and latency to make it work.