fynv / ThrustRTC

CUDA tool set for non-C++ languages that provides similar functionality like Thrust, with NVRTC at its core.
Other
59 stars 6 forks source link

ThrustRTC on Colab #6

Closed piotrbartman closed 4 years ago

piotrbartman commented 4 years ago

image Do you have any idea how to fixed this error (I want to test ThrustRTC on Google Colab)

fynv commented 4 years ago

I had a lot of trouble trying to find a proper place to put libPyThrustRTC.so (and the succeeding libPyCURandRTC.so). The last few uploads are all about that.

  1. Make sure you have the latest verstion (0.3.3) pip install ThrustRTC == 0.3.3

  2. If you still have the error, try locating libPyThrustRTC.so manually (a "Fei" folder should have been created somewhere), then you can fix the path in Native.py yourself. In that case, I hope you can tell me where libPyThrustRTC.so is in your case and what sys.prefix and site.USER_BASE returns.

Thanks.

piotrbartman commented 4 years ago

https://colab.research.google.com/drive/1IvE1J02ATWZsFNYim0q2G6aSrdEa8-bu?usp=sharing

Everything is available on this colab notebook. Of course editing Native.py works.

fynv commented 4 years ago

According to all threads I read, "package_data" is preferable to "data_files". However, in this case, considering libPyCURandRTC.so and libPyRTRTC.so has binary linkage to libPyThrustRTC.so, I want them to be deployed in the same directory rather than in separate module folders, so I used "data_files". But there seems to be no reliable way to locate the .so files at run-time. In this case, neither sys.prefix nor site.USER_BASE points to /usr/local.. Haven't come to a perpect solution yet.

fynv commented 4 years ago

"package_data" appears to be the better approach after all.. I've just updated ThrustRTC/CURandRTC/RTRTC to 3.4/1.4/1.4 on PyPi, now using "package_data" instead of "data_files" and everything works for me.

Solving binary linkage turns out to be easier than I thought. The trick is that, because each dll only needs to be loaded once for each process, I just need to make sure the python->dll loading happens before the dll->dll loading.

piotrbartman commented 4 years ago

It works for me too. Thank you very much!