Null references redux

[Jeremie Pelletier]

Yigal Chripun wrote:
> 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:

That wasn't what I said, I don't low level hand optimize everything, I 
do profiling first, only a few parts *known* to me to require 
optimizations (ie matrix multiplication) are written in sse from the 
beginning with a high level fallback, there just happen to be a lot of 
them :)

What I argued about was your view on today's software being too big and 
complex to bother optimize it.

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