[Cython] Cython 0.17 beta 3 released - release candidate

Christoph Gohlke cgohlke at uci.edu
Sun Aug 26 23:09:37 CEST 2012 

On 8/26/2012 4:08 AM, mark florisson wrote:
> On 25 August 2012 03:07, Christoph Gohlke <cgohlke at uci.edu> wrote:
>> Hi,
>>
>>
>> On 8/24/2012 12:43 PM, Stefan Behnel wrote:
>>>
>>> Hi,
>>>
>>> thanks for testing!
>>>
>>> Christoph Gohlke, 24.08.2012 07:20:
>>>>
>>>> I tested Cython-0.17b3 on Windows 7 with Visual Studio compilers.
>>>>
>>>> 32 bit Python 2.7 works well, only 4 test failures.
>>>
>>>
>>> Three of those errors are in OpenMP tests - is OpenMP supported in your
>>> build environment?
>>
>>
>> OpenMP is available on my system, and parallel.pyd is linked to the openmp
>> library. The prange tests fail only sometimes. On my system, the prange
>> index is sometimes left at the start (zero) of the range, while the tests
>> expect the index to be left at the stop of the range. According to the
>> Cython prange enhancements webpage "the iterations of the loop body can be
>> executed in any order" <http://wiki.cython.org/enhancements/prange>. Where
>> does that leave the loop index?
>>
>
> I should be the value from the last iteration, but in my experience
> many compilers have buggy OpenMP implementations. I think your
> compiler doesn't correctly support the lastprivate clause in all
> situations. For instance, test_prange fails (which doesn't have any
> break/return/exceptions), which simply has a lastprivate clause and a
> schedule clause set to 'dynamic'. The test without the schedule clause
> works fine (or maybe it's just luck). Or maybe it doesn't support
> multiple lastprivate() clauses? I'm not entirely sure... It also seems
> the thread limit on your system is 1.
>
> In any case, the generated code for these tests looks correct to me,
> but we've had similar problems before with different compilers...

A minimal example that fails for me is:

def test_parallel():
     cdef int i = 0, s = 0
     with nogil, cython.parallel.parallel():
         for i in prange(10):
             s += i
     return i

The returned value is often 0, otherwise 9 as expected.

In the generated C code I see

     #pragma omp for firstprivate(__pyx_v_i) lastprivate(__pyx_v_i)

If I change this to

     #pragma omp parallel for firstprivate(__pyx_v_i) lastprivate(__pyx_v_i)

the function always returns the expected value. Does that make sense?

Thanks for your help and patience.

Christoph


>
>>
>>>
>>> The other one is the new "initial_file_path" test that fails with this
>>> linker error:
>>>
>>> """
>>> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL
>>> /nologo /INCREMENTAL:NO /INCREMENTAL:YES        /DEBUG
>>> /LIBPATH:X:\Python27\libs
>>> /LIBPATH:X:\Python27\PCbuild /EXPORT:init__init__
>>> build\temp.win32-2.7\Release\my_test_package\__init__.obj
>>>
>>> /OUT:\Cython-0.17b3\BUILD\run\initial_file_path\my_test_package\__init__.pyd
>>> /IMPLIB:build\temp.win32-2.7\Release\my_test_package\__init__.lib
>>>
>>> /MANIFESTFILE:build\temp.win32-2.7\Release\my_test_package\__init__.pyd.manifest
>>>
>>> LINK : error LNK2001: unresolved external symbol init__init__
>>> """
>>>
>>> Maybe the Windows build of distutils is broken here - it seems to assume
>>> the wrong module name for the package module.
>>
>>
>> I think this is an issue with the test. The extension does compile and link
>> outside of the tests.
>>
>>
>>
>>>
>>> I guess compiling package modules is just an overall badly supported
>>> feature in CPython...
>>>
>>>
>>>> On 64 bit Python 2.7 and 3.2 with msvc9 compiler, python.exe crashes
>>>> during
>>>> `test_slice_assignment (memslice.__test__)`. I tested two computers. The
>>>> Windows executive can not identify in which specific module it crashes,
>>>> and
>>>> neither enabling faulthandler nor building with debug symbols gives any
>>>> useful information. Can anyone reproduce this? It seems compiler specific
>>>> since Python 3.3, which is using msvc10, does not crash.
>>>
>>>
>>> Hmm, yes, sounds like a problem with the compiler. Would be good to get
>>> this sorted out, but it's almost impossible to debug something like this
>>> from a distance.
>>
>>
>>
>> Maybe the following simple example is related. It fails (not crash) when
>> compiled with 64 bit msvc9, but does work with 32 bit msvc9 and msvc10 (32
>> and 64 bit):
>>
>> ```
>> from cython.view cimport array as cvarray
>> import numpy as np
>>
>> narr = np.arange(8 * 14 * 11).reshape((8, 14, 11))
>>
>> cdef int[:, :, ::1] a = narr
>> cdef int[:, :, :] b = a[2:8:2, -4:1:-1, 1:3]
>>
>> print narr[2:8:2, -4:1:-1, 1:3].shape
>> print b.shape[0], b.shape[1], b.shape[2]
>> ```
>>
>> On win-amd64-py2.x the shape of b is (3, 9, 3) but it should be (3, 9, 2)
>>
>>
>>
>>>
>>>
>>>> When disabling
>>>> test_slice_assignment, runtests.py completes with many failures.
>>>>
>>>> The results of `runtests.py -v -v` are at
>>>> <http://www.lfd.uci.edu/~gohlke/pythonlibs/tests/cython/>.
>>>
>>>
>>> The 64bit output looks so broken that I wonder what went wrong here. I
>>> mean, most of the problems look like this:
>>>
>>> """
>>> Expected:
>>>       Traceback (most recent call last):
>>>       TypeError: m() takes at most 2 positional arguments (3 given)
>>> Got:
>>>       Traceback (most recent call last):
>>>       TypeError: m() takes at most %Id positional argument%s (%Id given)
>>> """
>>>
>>> I have no idea how that can happen.
>>>
>>> I can see two other problems, one is the linker warning about the module
>>> init function in Py3:
>>>
>>> """
>>> bufaccess.obj : warning LNK4197: export 'PyInit_bufaccess' specified
>>> multiple times; using first specification
>>> """
>>
>>
>> This is "normal".
>>
>>
>>
>>>
>>> The other one is about mixing Py_ssize_t and int (and some other) types
>>> all
>>> over the place:
>>>
>>> """
>>> bufaccess.c(3033) : warning C4244: '=' : conversion from 'Py_ssize_t' to
>>> 'int', possible loss of data
>>> """
>>>
>>> Some of them look like we'd need an explicit cast in the C code somewhere,
>>> others might hint at lax type usage in tests.
>>>
>>> There's also this:
>>>
>>> """
>>> C:\Program Files (x86)\Microsoft Visual Studio
>>> 10.0\VC\INCLUDE\xlocale(323)
>>> : warning C4530: C++ exception handler used, but unwind semantics are not
>>> enabled. Specify /EHsc
>>> """
>>>
>>> Stefan
>>>
>>
>>
>> Thanks,
>>
>> Christoph
>>
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
>
>

More information about the cython-devel mailing list