5 ms·

"Managed memory is free. Not as in free beer, as in free puppy." Dev manager of Exchange used that line in a talk. Never were more insightful words spoken. Dev

"Managed memory is free. Not as in free beer, as in free puppy." Dev manager of Exchange used that line in a talk. Never were more insightful words spoken. Devs will move from C++ where they obsess about every allocation to .NET and they'll totally forget that allocation is expensive no matter what the platform or runtime.

rjbwork 9y ago
>they'll totally forget that allocation is expensive no matter what the platform or runtime. Well, it's easier to do in a managed language. When you literally don't have to agonize or obsess over every allocation because you aren't responsible for cleaning it up (unmanaged held resources withstanding), you tend not to do so. P.S.: You're always free to drop down into C or C++ if you want to get some speed, but of course you need to clean up after yourself there. A friend of mine wrote a good guide on doing so, if anyone cares https://github.com/TheBlackCentipede/PlatformInvocationIndepth/blob/master/main.pdf https://github.com/TheBlackCentipede/PlatformInvocationIndep...
- Nuzzerino 9y ago
  >You're always free to drop down into C or C++ if you want to get some speed Wouldn't C# with structs and pointers do the job in many cases? I've been able to get 50-fold increases in speed through heavy optimizations, without switching to another language. Using C or C++ solely for a "speed boost" over C# is not only unnecessary, but it creates more problems than it solves. If you don't know how to optimize within C# (as a C# developer), how are you going to succeed in writing efficient C++ code? Once you learn the nuances and limitations of making optimizations in C#, then you should start looking into how and when other languages such as C can wisely be used. To name an example, C makes it easier to micromanage assembly instructions (can be done in C# too, but not in a very practical way, and yes I mean assembly and not IL). C also contains more syntax and features which are suitable for bitwise micromanagement, whereas with C# it can be more awkward.
  - pjmlp 9y ago
    Yes they would, and the C# 7 improvements taken from Midori experience make it much better. I think in general it is a culture problem. Those of us that embraced managed languages, including for systems programming (Oberon, D, ...), know that we can be productive 99% of the time and just have to care how to do speed boost tricks on that 1% using profiler and low level language tricks. In C and C++ communities there is a sub-culture of thinking too much ahead of time how much each line of code costs, thus speeding too much time with design decisions that actually have zero value in the context of the application being delivered. The problem is not taking those decisions, rather taking them without validating if they are right with a profiler, or regard to the goals that have to be met for the application. Beyond which any low level fine tuning, while fun, is needless engineering.
    - sterlind 9y ago
      Midori was so beautiful. I think it would have succeeded as a .Net runtime replacement with picoprocesses. it frustrates me that we didn't open-source it.
      - pjmlp 9y ago
        As believer in GC enabled system programming languages, I do feel it was indeed a missed opportunity, specially to change the mind of those that think C and C++ are the only way to write OSes.
  - eni 9y ago
    Can you please point to any resources that talk about heavy optimization options in c#. That 50-fold increase you talk about is very interesting. I would like to learn more.
    - pjmlp 9y ago
      Here is a list, not easy to track all of them down, but maybe as keywords to easy googling. - structs - unsafe code - stack allocation in unsafe code (think alloca()) - attribute annotations for packing and inline calls across assemblies - ref parameters - ref returns - readonly ref parameters - Span<> and Memory<> - Native memory allocation via MarshalInterop, SafeHandles - Buffer and ArraySegment - SIMD (with RyuJIT) - Profiled code cache for JIT code background generation between executions (System.Runtime.ProfileOptimization)

rjbwork 9y ago

>they'll totally forget that allocation is expensive no matter what the platform or runtime. Well, it's easier to do in a managed language. When you literally don't have to agonize or obsess over every allocation because you aren't responsible for cleaning it up (unmanaged held resources withstanding), you tend not to do so. P.S.: You're always free to drop down into C or C++ if you want to get some speed, but of course you need to clean up after yourself there. A friend of mine wrote a good guide on doing so, if anyone cares https://github.com/TheBlackCentipede/PlatformInvocationIndepth/blob/master/main.pdf https://github.com/TheBlackCentipede/PlatformInvocationIndep...

Nuzzerino 9y ago
>You're always free to drop down into C or C++ if you want to get some speed Wouldn't C# with structs and pointers do the job in many cases? I've been able to get 50-fold increases in speed through heavy optimizations, without switching to another language. Using C or C++ solely for a "speed boost" over C# is not only unnecessary, but it creates more problems than it solves. If you don't know how to optimize within C# (as a C# developer), how are you going to succeed in writing efficient C++ code? Once you learn the nuances and limitations of making optimizations in C#, then you should start looking into how and when other languages such as C can wisely be used. To name an example, C makes it easier to micromanage assembly instructions (can be done in C# too, but not in a very practical way, and yes I mean assembly and not IL). C also contains more syntax and features which are suitable for bitwise micromanagement, whereas with C# it can be more awkward.
- pjmlp 9y ago
  Yes they would, and the C# 7 improvements taken from Midori experience make it much better. I think in general it is a culture problem. Those of us that embraced managed languages, including for systems programming (Oberon, D, ...), know that we can be productive 99% of the time and just have to care how to do speed boost tricks on that 1% using profiler and low level language tricks. In C and C++ communities there is a sub-culture of thinking too much ahead of time how much each line of code costs, thus speeding too much time with design decisions that actually have zero value in the context of the application being delivered. The problem is not taking those decisions, rather taking them without validating if they are right with a profiler, or regard to the goals that have to be met for the application. Beyond which any low level fine tuning, while fun, is needless engineering.
  - sterlind 9y ago
    Midori was so beautiful. I think it would have succeeded as a .Net runtime replacement with picoprocesses. it frustrates me that we didn't open-source it.
    - pjmlp 9y ago
      As believer in GC enabled system programming languages, I do feel it was indeed a missed opportunity, specially to change the mind of those that think C and C++ are the only way to write OSes.
- eni 9y ago
  Can you please point to any resources that talk about heavy optimization options in c#. That 50-fold increase you talk about is very interesting. I would like to learn more.
  - pjmlp 9y ago
    Here is a list, not easy to track all of them down, but maybe as keywords to easy googling. - structs - unsafe code - stack allocation in unsafe code (think alloca()) - attribute annotations for packing and inline calls across assemblies - ref parameters - ref returns - readonly ref parameters - Span<> and Memory<> - Native memory allocation via MarshalInterop, SafeHandles - Buffer and ArraySegment - SIMD (with RyuJIT) - Profiled code cache for JIT code background generation between executions (System.Runtime.ProfileOptimization)