I'm currently thinking of adopting the Python-opencl package on the Arch
Linux community repositories. I noticed that there are no tarball
signatures or signed tags for the sources.
Is this intentional? I'd be more than convenient security-wise to have a
(or a set) key that I could trust when building the package :)
I am writing to solicit some feedback on what seems likely to become the
'next generation' of PyOpenCL:
This branch switches to pybind11 for its C wrapping needs, and, in many
ways, is a revival of the old Boost.Python code base, though without any
of the Boost requirements. All that's needed is a reasonably recent C++
Why do this, you ask? Smaller code base (by about 1500 lines), faster
(by around 2x, especially in tight kernel-calling loops!), more reliable
(especially in handling errors and Ctrl+C, cf ), simpler and more fun
to hack (subjective, admittedly). I do envision continuing to support
Pypy, although building on Pypy is currently broken because of a few
direct uses of the numpy interface from C. I think this should be
fixable without too much fuss.
There are no changes to the external interface--the tests from 2018.1
pass unmodified. All of my own workloads run without modification. Some
changes *have* been made to continue the process of adapting to OpenCL 2.
You may install directly using:
pip install git+https://github.com/inducer/pyopencl@pybind11
You may need to
pip install pybind11
in order for that to succeed.
Some notes and CI results are here:
If all goes as planned, this branch will at some point turn into version
2018.2 of PyOpenCL.
Please test this against your workloads and report any issues. Also, if
you have any feedback, please do speak up.
Gregor Thalhammer <gregor.thalhammer(a)gmail.com> writes:
>> Am 14.08.2018 um 19:02 schrieb Andreas Kloeckner <lists(a)informa.tiker.net>:
>> Gregor, Vincent,
>> Gregor Thalhammer <gregor.thalhammer(a)gmail.com <mailto:email@example.com>> writes:
>>>> Am 14.08.2018 um 14:03 schrieb Vincent Favre-Nicolin <favre(a)esrf.fr>:
>>>> Hi Andreas,
>>>> I tested this against my code and found only one issue when using gpyfft, as the ‘retain’ keyword argument seems to be absent in the new Event.from_int_ptr() function.
>>>> If I remove the ‘retain=False’ argument near the end of gpyfftlib.pyx everything works as before. Not sure how necessary the retain argument is (Gregor ?).
>>> it seems it is a regression that in the latest pyopencl version the
>>> retain argument to Event.from_int_ptr() is missing. It has been added
>>> to avoid a memory leak, see
>> Thanks for taking a look, and for catching this regression. I've added
>> the retain flag in 88eecd2.
> Thanks for fixing this. Did you push it to the github repo? Can’t see it.
I can see them on the pybind11 branch: