"Yigal Chripun" <yigal...@gmail.com> wrote in message news:h9r37i$tg...@digitalmars.com... > >> >> These aren't just marginal performance gains, they can easily be up to >> 15-30% improvements, sometimes 50% and more. If this is too complex or >> the risk is too high for you then don't use a systems language :) > > your approach makes sense if your are implementing say a calculator. > It doesn't scale to larger projects. Even C++ has overhead compared to > assembly yet you are writing performance critical code in c++, right? >
It's *most* important on larger projects, because it's only on big systems where small inefficiencies actually add up to a large performance drain. Try writing a competitive real-time graphics renderer or physics simulator (especially for a game console where you're severely limited in your choice of compiler - if you even have a choice), or something like Pixar's renderer without *ever* diving into asm, or at least low-level "unsafe" code. And when it inevitably hits some missing optimization in the compiler and runs like shit, try explaining to the dev lead why it's better to beg the compiler vender to add the optimization you want and wait around hoping they finally do so, instead of just throwing in that inner optimization in the meantime. You can still leave the safe/portable version in there for platforms for which you haven't provided a hand-optimization. And unless you didn't know what you were doing, that inner optimization will still be small and highly isolated. And since it's so small and isolated, not only can you still throw in tests for it, but it's not as much harder as you would think to veryify correctness. And if/when your compiler finally does get the optimization you want, you can just rip out the hand-optimization and revert back to that "safe/portable" version that you had still left in anyway as a fallback.