Coffeehouse Post

Single Post Permalink

View Thread: is managed code faster than native?
  • User profile image

    , BitFlipper wrote

    Wow that is quite a generalization for someone that has no clue what my code looks like. I'm talking about tight loops that does DSP processing (realtime FFT, filtering, FFT analysis, etc) as well as code that does asynchronous multithreaded low-level IO. In such cases the overhead of using enumerators can easily add a 30% performance drop in such tight loops. I've done the benchmarks and that is what they show. What does your benchmarks show for such cases?

    I think you might get a bigger performance gain by taking a step back and asking if using other types of data structures and coding styles might give you better performance.

    For example, a flat array will give you faster data accesses than an SDL list, even when using integer indexors.

    And if you're really spending all of your time in a hot loop doing memory/CPU operations like FFTs, try writing them as a GPU shader in HLSL; you'll get orders of magnitude speed up by doing so. That's what I do for password-cracking for example. I certainly don't use the SDL at all for the hot loops of mine that actually make the room so hot you need four water cooling pumps and a heat-sink the size of a table to keep the processors from melting (but as you say, I only write code where performance doesn't matter, right Smiley)

    Focusing on minor things like iterators versus integer indexers tends to hide the wood for the trees - as you said before you spend a lot of time doing low-level asynchronous IO - the syscall to kick that off will take tens of thousands of times longer to complete than the difference between an index in SDL verus the overloaded array indexer.

    And since the SDL interator is not contractually bound to be slower - it might actually be faster on some machines or in future versions of the CRT. For example, integer array accesses need to be bounds checked for safety, whereas iterators do not.

    Morale of the story is that writing, easy-to-read, obviously-correct and good-practices code for the most part, and only ever optimising (and liberally commenting and benchmarking) genuine hotloops tends to lead to better, more reliable and more long-lived code.