[Cython] nonecheck directive

[Dag Sverre Seljebotn]

On 05/21/2011 07:57 AM, Stefan Behnel wrote:
> 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.

There wasn't a point where anybody wasn't careful about this; it is 
simply something that was inherited from Pyrex. The nonecheck directive 
came much later.

Dag Sverre