Null references redux

[Don]

Jeremie Pelletier wrote:
> Don wrote:
>> Jeremie Pelletier wrote:
>>> Yigal Chripun wrote:
>>>> On 29/09/2009 16:41, Jeremie Pelletier wrote:
>>>>
>>>>> What I argued about was your view on today's software being too big 
>>>>> and
>>>>> complex to bother optimize it.
>>>>>
>>>>
>>>> that is not what I said.
>>>> I was saying that hand optimized code needs to be kept at minimum 
>>>> and only for visible bottlenecks, because the risk of introducing 
>>>> low-level unsafe code is bigger in more complex and bigger software.
>>>
>>> What's wrong with taking a risk? If you know what you're doing where 
>>> is the risk, and if now how will you learn? If you write your 
>>> software correctly, you could add countless assembly optimizations 
>>> and never compromise the security of the entire thing, because these 
>>> optimizations are isolated, so if it crashes there you have only a 
>>> narrow area to debug within.
>>>
>>> There are some parts where hand optimizing is almost useless, like 
>>> network I/O since latency is already so high having a faster code 
>>> won't make a difference.
>>>
>>> And sometimes the optimization doesn't even need assembly, it just 
>>> requires using a different high level construct or a different 
>>> algorithm. The first optimization is to get the most efficient data 
>>> structures with the most efficient algorithms for a given task, and 
>>> THEN if you can't optimize it more you dig into assembly.
>>>
>>> People seem to think assembly is something magical and incredibly 
>>> hard, it's not.
>>>
>>> Jeremie
>>
>> Also, if you're using asm on something other than a small, simple 
>> loop, you're probably doing something badly wrong. Therefore, it 
>> should always be localised, and easy to test thoroughly. I don't think 
>> local extreme optimisation is a big risk.
> 
> That's also how I do it once I find the ideal algorithm, I've never had 
> any problems or seen any risk with this technique, I did see some good 
> performance gains however.
> 
>> Greater risks come from using more complicated algorithms. Brute-force 
>> algorithms are always the easiest ones to get right <g>.
> 
> I'm not sure I agree with that. Those algorithms are pretty isolated and 
> really easy to write unittests for so I don't see where the risk is when 
> writing more complex algorithms, it's obviously harder, but not riskier.

By "riskier" I mean "more chance of containing an error".

I'm partly basing this on my recent experience with writing BigInt. The 
low-level asm routines are easy to get right, and it's easy to tell when 
you've go them wrong. They do brute-force stuff, like schoolbook O(n^2) 
multiplication, and importantly, _there are no special cases_ because it 
needs to be fast.
But the higher-level O(n^1.3) multiplication algorithms are full of 
special cases, and that's where the bugs are.