MNT: Mark all nogil functions as noexcept

[matusvalo]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

This PR marks all nogil functions as noexcept because:

1. Currently, they are not propagating exception with Cython 0.29.X
2. I found out that several of functions are still checking exception after every call - e.g.

   pandas/pandas/_libs/tslibs/ccalendar.pyx

   Line 158 in 75daea4

   cpdef iso_calendar_t get_iso_calendar(int year, int month, int day) nogil:

3. Several functions returning void were missed in MNT: Explicitly set cdef functions as noexcept #53144

Note: nogil function calls checking the exception after every function call is introducing non-negligible performance degradation - see https://cython.readthedocs.io/en/latest/src/userguide/language_basics.html#error-return-values

[matusvalo]

@h-vetinari could you run tests over this PR using Cython3.0 b3? Unittests are failing on my computer but I am not 100% convinced that it is caused by changes in this PR.

[h-vetinari]

@h-vetinari could you run tests over this PR using Cython3.0 b3?

Running in conda-forge/pandas-feedstock#162

[h-vetinari]

Ah, I should have said: I'm running the changes of this PR on top of 2.0.1. If we need everything that's in main as well, then I'll have to do it differently...

[h-vetinari]

So, on top of 2.0.1, the only failure on unix is test_add_out_of_pydatetime_range, but that was pre-existing. Windows has three other failures, but those also were pre-existing.

[WillAyd]

What does something being nogil have to do with its error handling? I think this is OK but not sure I follow the reasoning in the OP; want to make sure we don't lose exception handling we actually want

[h-vetinari]

What does something being nogil have to do with its error handling?

It has nothing to do with nogil, but with Cython 3 now propagating exceptions by default, and it being beneficial to mark those functions that will not raise as noexcept for performance reasons.

[WillAyd]

Cool makes sense and thanks for the info. This lgtm - assuming we can look at non-nogil functions in a follow up?

[matusvalo]

What does something being nogil have to do with its error handling?

Let me explain it using following function from PR:

pandas/pandas/_libs/window/aggregations.pyx

Lines 115 to 116 in 8cf4ab4

	cdef void remove_sum(float64_t val, int64_t *nobs, float64_t *sum_x,
	float64_t *compensation) nogil:

1. The function has void return type which in Cython3 means that by default after every call the exception is checked. This single point is introducing a small (maybe negligible) performance hit. In Cython 0.29.X you did not care since the default behaviour is to not propagate exception information.
2. But the gil keyword is making it worse when function is called within with nogil block - e.g. here:
   

   pandas/pandas/_libs/window/aggregations.pyx

   Line 167 in 8cf4ab4

   remove_sum(values[j], &nobs, &sum_x, &compensation_remove)

   
   In this case cython3 generates following code:

    __pyx_f_6pandas_5_libs_6window_12aggregations_remove_sum(/*function args*/); if (unlikely(__Pyx_ErrOccurredWithGIL())) __PYX_ERR(0, 167, __pyx_L4_error)

   The problem is caused by __Pyx_ErrOccurredWithGIL() which acquires GIL lock. This can hit performance seriously. See [BUG] Performance degredation due to __Pyx_ErrOccurredWithGIL in memoryview code cython/cython#5324 for details.

[mroeschke]

Thanks @matusvalo