3 ms·
> In C, Zig, Rust, C++ (hardish) I can sit down with pen and paper and map out the layout of memory and take informed decisions on cache locality, access patter
by gwbas1c 3y ago
> In C, Zig, Rust, C++ (hardish) I can sit down with pen and paper and map out the layout of memory and take informed decisions on cache locality, access patterns, etc.
When direct control over your memory is important, you're better off using those languages. When working with idiomatic C#, you really don't think about direct memory management. The garbage collector is excellent, and in many cases, it can outperform systems like reference counting.
The primary critical tradeoff with C#'s garbage collector is memory footprint. When you directly control your memory, you can free it as soon as it's not needed. (We can typically say that the extra RAM is cheaper than developer time... Until it's not, and then "map out the layout of memory" becomes worth it.)
The secondary critical tradeoff with C#'s garbage collector is that you don't want to write a general-purpose library like SQLite in C#. (You wouldn't want to suck .Net into a Python or Java process.)
But, assuming you're writing a typical web application, server-side batch processing system, desktop application, ect, these tradeoffs often work out in your favor with C#'s garbage collector. (But, if you're running your code on 1000s of memory-constrained servers, "map out the layout of memory" may be cheaper in the long run.)
And, yes, in C# you can do direct memory management with things like unsafe code (pointers and pointer arithmetic,) and structs. In my experience, the one time I did a deep dive into those optimizations, they had no advantage over "idiomatic" C# when I hooked up a profiler.
- pjmlp 3y agoWell, it is a matter of knowing how to take advantage of them. https://devblogs.microsoft.com/dotnet/grpc-performance-improvements-in-net-5/ https://devblogs.microsoft.com/dotnet/grpc-performance-impro... Or just browse the performance improvements blog posts, https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/ https://devblogs.microsoft.com/dotnet/performance-improvemen... https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/ https://devblogs.microsoft.com/dotnet/performance_improvemen... https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/ https://devblogs.microsoft.com/dotnet/performance-improvemen...
- gwbas1c 3y agoI did direct memory management in C# before those techniques were available. (It was a .Net Framework 4.x application.)
- pjmlp 3y agoYeah, and many of these techniques require assistance from the new .NET Core runtime, e.g. Span is not reckognised as a intrisic by the .NET Framework Jit. I also applied similar techniques with C++/CLI on .NET Framework, for a RPC framework, network packet processing optimization, and they surely helped.
- gwbas1c 3y ago> In my experience, the one time I did a deep dive into those optimizations, they had no advantage over "idiomatic" C# when I hooked up a profiler. What I'm really getting at is the attitude that some people who come from manual memory management backgrounds come in with when they start with C#. They're so used to manually controlling everything that sometimes they slip into pointers, unsafe, ect, out of habit. IE, they're really useful in performance critical areas, and even then, you need a profiler to prove that they're worth it. In my case, I was writing a filesystem that had a driver and a user-mode piece. The user-mode piece was in C#, so I initially wrote parts of it with pointers, ect. I used the profiler to "prove" that the extra effort was worth it early into the project... And it wasn't. I was surprised, to put it mildly.
- pjmlp 3y agoAh, in that regard I fully agree with you. Oberon did it for me, then given my interests, computer archeology in alternative computing models, most of which failed more due to human reasons than technical ones. Although maybe having started with Timex 2068 BASIC/Z80, Turbo Basic, Turbo Pascal, having done Clipper as well, also tainted me in what to expect in regards to productivity.