Null references redux

Yigal Chripun yigal100 at gmail.com
Mon Sep 28 21:54:45 PDT 2009


On 29/09/2009 00:31, Nick Sabalausky wrote:
> "Yigal Chripun"<yigal100 at gmail.com>  wrote in message
> news:h9r37i$tgl$1 at 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.
>
>

I think you took my post to an extreme, I actually do agree with the 
above description.

what you just said was basically:
1. write portable/safe version
2. profile to find bottlenecks that the tools can't optimize and 
optimize those only while still keeping the portable version.

My objection was to what i feel was Jeremie's description of writing 
code from the get go in low level hand optimized way instead of what you 
described in your own words:

> And unless you didn't know
> what you were doing, that inner optimization will still be small and highly
> isolated.



More information about the Digitalmars-d mailing list