[Cython] nonecheck directive

[Stefan Behnel]

Robert Bradshaw, 20.05.2011 17:33:
> On Fri, May 20, 2011 at 8:13 AM, Stefan Behnel wrote:
>> why is the "nonecheck" directive set to False by default? Shouldn't it
>> rather be a "I know what I'm doing" option that allows advanced users to
>> trade speed for safety?

Erm, trade safety for speed, obviously ...


>> The reason I'm asking is that I just enabled its evaluation in NoneCheckNode
>> and immediately got crashes in the test suite. So its currently only
>> half-heartedly safe because it's not being evaluated in a lot of places.
>> That's a rather fragile situation, not only for refactorings.
>
> The reasoning was that we didn't want to have a major performance
> regression on existing code has already been written knowing these
> semantics, and also that we eventually plan to solve this more
> gracefully using control flow.

I can see that there could have been a slight, potential performance 
regression due to additional None checks, even considering that the C 
compiler can often drop many of them due to its own control flow analysis, 
and even though the CPU's branch prediction can be expected to handle this 
quite well even in loops.

However, for users, it's hard to predict where Cython can avoid None checks 
and where it cannot, so having to explicitly tell it to do None checks in a 
specific code section means that users encounter and analyse a crash first, 
potentially when switching to a newer Cython version. The opt-out way would 
have allowed them to disable it only for code sections where it is really 
getting in the way, and would have made it clear in their own code that 
something potentially unsafe is happening where they are on their own.

I think that even in the face of future control flow analysis in Cython, it 
would still have been better to make it an opt-out rather than opt-in 
option, but I would expect that we can still switch the default setting 
when a suitable CFA step becomes available.

In the future, I think we should be more careful with potentially harmful 
options, and always prefer safety over speed - *especially* when we know 
that the safe way will improve at some point.

Stefan