I can't get the CodePy Thrust example to work:
Traceback (most recent call last):
File "thrust_demo.py", line 95, in <module>
c = module.host_entry(b)
TypeError: No registered converter was able to produce a C++ rvalue of
type unsigned int from this Python object of type DeviceAllocation
I tried downgrading libboost-python from from 1.46 to 1.42 but it
didn't solve it. Any other places I might look?
On Thu, May 24, 2012 at 7:13 PM, Bryan Catanzaro <[email protected]> wrote:
> Nope, nothing has changed since then. If ctypes works for you, that's
> great. However, I don't think using codepy is that difficult - if you
> look at the example I posted, you'll see it's not that much work to
> compile things with nvcc using codepy.
> http://wiki.tiker.net/PyCuda/Examples/ThrustInterop
> Perhaps the Boost dependence scares people off - but if you're using
> PyCUDA, you are already using Boost. ;)
>
> It might be useful to include more of Thrust as a precompiled binary,
> but in general it's not possible to compile all of Thrust, since it's
> a template library. Even when you restrict yourself to a basic set of
> fundamental types, if you allow tuples, the combinatorics are
> prohibitive.
>
> - bryan
>
>
> On Thu, May 24, 2012 at 3:46 AM, Igor <[email protected]> wrote:
>> Hi Andreas, (Hi Bryan),
>>
>> Last December I was asking you about CodePy. See how far I went with
>> it with your help: http://dev.math.canterbury.ac.nz/home/pub/17/
>>
>> Note, there is no CUDA or thrust code in the CodePY example. There
>> seemed to be no easy way to do it. I'll paste some excerpts from our
>> emails from Dec 16,17,
>>
>> I: "My next question, suppose MODULE_CODE contains some thrust code and
>> would have to be compiled through nvcc (and g++). Simply using
>> nvcc_toolchain,
>>
>> nvcc_toolchain = codepy.toolchain.guess_nvcc_toolchain()
>> cmod = extension_from_string(nvcc_toolchain, "module", MODULE_CODE)
>>
>> Didn't work of course. Do you have a similar function that takes a
>> STRING, both host_toolchain, and nvcc_toolchain, and compiles it? If
>> not, what is the right way?"
>>
>> B: "NVCC can't parse Boost well, so I have to segregate the host code
>> which binds it to Python from the CUDA code compiled by NVCC.
>> The way I do this is to create a codepy.bpl.BoostPythonModule which
>> has the host entry point (and will be compiled by g++). Then I create
>> a codepy.cuda.CudaModule which references the BoostPythonModule
>> (making this link explicit lets codepy compile them together into a
>> single binary). Then I call compile on the CudaModule, which should
>> to the right thing. You can see code that does this here:
>> http://code.google.com/r/bryancatanzaro-copperhead/source/browse/copperhead/compiler/binarygenerator.py#84";
>>
>> A: "I'd just like to add that I recently split out the code generation bits
>> of codepy and called them cgen.
>>
>> http://pypi.python.org/pypi/cgen
>> https://github.com/inducer/cgen
>> https://github.com/inducer/codepy
>>
>> (but compatibility wrappers that wrap cgen into codepy will stay in
>> place for a while)"
>>
>> Has something changed since then?
>>
>> ctypes works fine and it has the advantage of not having to use boost.
>> It's just an unaltered C++/CUDA/thrust code. Invoking systems' nvcc
>> was as easy as gcc. As for the caching, I check the hash of the source
>> string: if it has changed, I build and load a new (small!) .so module
>> with the hash value attached to the name. The pointers into the old
>> .so get garbage collected and unloaded; if they are stored in a tmp
>> folder -- the .so files get deleted eventually.
>>
>> I remember you preferred Boost::Python to ctypes in general for its
>> better performance; but if we make calls to ctypes library rarely,
>> small additional overheads, if there were some, aren't important.
>>
>> A better programme would be to port all the algorithms and interfaces
>> of Thrust to PyCUDA. The only reason I need thrust for example, is
>> that it can find me the extremum element's _location_ which I still
>> don't know how to do in PyCUDA.
>>
>> Cheers,
>> Igor
>>
>> On Thu, May 24, 2012 at 11:58 AM, Andreas Kloeckner
>> <[email protected]> wrote:
>>> Hi Igor,
>>>
>>> On Thu, 24 May 2012 10:51:55 +1200, Igor <[email protected]> wrote:
>>>> Andreas, thanks, but it currently implies Linux, I'll see if I can
>>>> make it work on Windows. Or maybe I'll submit and someone will try it
>>>> on Windows. I just need to extract it from Sage into a plain Python
>>>> script. Give me a couple of days.
>>>> http://dev.math.canterbury.ac.nz/home/pub/14/
>>>> http://dev.math.canterbury.ac.nz/home/pub/19/
>>>
>>> I would actually suggest you use the codepy machinery to let nvcc do the
>>> compilation--this has the advantage that a) there is code out there that
>>> makes this work on Windows (Bryan?) and b) you get compiler caching for
>>> free.
>>>
>>> All you'd need to do is build an analog of extension_from_string, say
>>> ctypes_dll_from_string. Just imitate this code here, where
>>> compile_from_string does all the hard work:
>>>
>>> https://github.com/inducer/codepy/blob/master/codepy/jit.py#L146
>>>
>>> In any case, even if you can make something that's Linux-only, it would
>>> likely help a big bunch of people. Windows support can always be added
>>> later.
>>>
>>> Andreas
>>
>> _______________________________________________
>> PyCUDA mailing list
>> [email protected]
>> http://lists.tiker.net/listinfo/pycuda
>
> _______________________________________________
> PyCUDA mailing list
> [email protected]
> http://lists.tiker.net/listinfo/pycuda
_______________________________________________
PyCUDA mailing list
[email protected]
http://lists.tiker.net/listinfo/pycuda
