[Cython] nonecheck directive

[Robert Bradshaw]

On Fri, May 20, 2011 at 10:57 PM, Stefan Behnel <stefan_ml at behnel.de> 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.

It would be great if someone did some extensive benchmarking--maybe
the overhead is negligible right now.

> 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.

It's not as if we introduced a new feature, and then chose the unsafe
version rather than the safe one. In this case (e.g. buffer indexing)
we always default to the safe option. Rather, this is how the language
has always been, and we introduced an option with overhead to make
things safer but remaining 100% backwards compatible (in terms of
performance and behavior) with existing code.

- Robert