Re: [PyOpenCL] copy_if_sparse()?
by Andreas Kloeckner
Alexandre Linhares <linhares(a)clubofrome.org.br> writes:
> Suppose the results from copy_if() are few, in relation to the buffer.
> Wouldn't it be advantageous (performance-wise) to create a results-sized
> buffer, copy the results there, and minimize buffer transfer?
>
> In other words, am I introducing any bugs?
>
> Source code here:
> https://stackoverflow.com/questions/28249558/pyopencl-copy-if-is-it-possi...
>
> Thank you for your work. It is wonderful!
http://documen.tician.de/pyopencl/algorithm.html#pyopencl.algorithm.copy_if
The interface to copy_if is as it is on purpose. As we start the scan to
do the main operation, we don't yet know how large the result will be,
so we have to allocate the full length.
From here, there are two possible ways forward, but which you choose is
a tradeoff.
- You can allocate a 'right-sized' output array and copy your result to
it. This is what you're suggesting, if I understand you right. The
advantage is that you don't waste memory for entries that are unused.
The downside is that the copy takes time. This is usually what you'd
do if the result is intended to be long-lived.
Btw, you can achieve this just via out[:count].copy().
- You can also just grab a smaller view of the results array by
out[:count], knowing that there's a larger array behind that being
kept alive 'behind' it. This is a good solution if the result is
short-lived.
If you're mainly concerned about copy costs, out[:count].get() should
be yet faster than your solution, because you don't incur the cost of
allocating the temporary and copying into it.
Since copy_if cannot make that trade-off for you (for example, it can't
know how long-lived the result is intended to be), the interface is the
way it is, allowing you to achieve a cost-optimal solution for your
situation with just a tiny bit of extra work. I'd love to take a patch
to the documentation that explains this, if you have time.
Hope that helps,
Andreas
4 years, 7 months
copy_if_sparse()?
by Alexandre Linhares
Dear Andreas et al.,
Suppose the results from copy_if() are few, in relation to the buffer.
Wouldn't it be advantageous (performance-wise) to create a results-sized
buffer, copy the results there, and minimize buffer transfer?
In other words, am I introducing any bugs?
Source code here:
https://stackoverflow.com/questions/28249558/pyopencl-copy-if-is-it-possi...
Thank you for your work. It is wonderful!
please... Help! :)
--Alex
4 years, 7 months
Re: [PyOpenCL] undefined symbol (nvidia-304xx)
by Andreas Kloeckner
Neal Becker <ndbecker2(a)gmail.com> writes:
> I'm assuming if I use nvidia driver I have to use their libOpenCL?
No, you're free to use whichever one you please. libOpenCL only
dispatches between different drivers ("ICDs"). See here for more:
http://wiki.tiker.net/OpenCLHowTo
Nvidia's is perhaps the worst choice, although it is viable as long as
you either install matching headers or configure PyOpenCL with
CL_PRETEND_VERSION = "1.1"
in siteconf.py.
Better choices include AMD's libOpenCL or this open-source one:
https://forge.imag.fr/projects/ocl-icd/
Hope that helps,
Andreas
4 years, 8 months
undefined symbol (nvidia-304xx)
by Neal Becker
Perhaps my nvidia opencl is missing something?
Just trying out pyopencl.
This is fedora 21 linux with
rpm -qa *nvidia*
kmod-nvidia-304xx-3.17.7-300.fc21.x86_64-304.125-1.fc21.1.x86_64
akmod-nvidia-304xx-304.125-1.fc21.1.x86_64
xorg-x11-drv-nvidia-304xx-304.125-1.fc21.x86_64
xorg-x11-drv-nvidia-304xx-libs-304.125-1.fc21.x86_64
xorg-x11-drv-nvidia-304xx-devel-304.125-1.fc21.x86_64
configured as:
./configure.py --help --cl-lib-dir=/usr/lib64/nvidia-304xx --boost-compiler=g++
--boost-python-libname=boost_python
/home/nbecker/.local/lib/python2.7/site-packages/pyopencl-2014.1-py2.7-linux-
x86_64.egg/pyopencl/__init__.py in <module>()
28
29 try:
---> 30 import pyopencl._cl as _cl
31 except ImportError:
32 import os
ImportError: /home/nbecker/.local/lib/python2.7/site-packages/pyopencl-2014.1-
py2.7-linux-x86_64.egg/pyopencl/_cl.so: undefined symbol: clCreateSubDevices
ldd /home/nbecker/.local/lib/python2.7/site-packages/pyopencl-2014.1-py2.7-
linux-x86_64.egg/pyopencl/_cl.so
linux-vdso.so.1 => (0x00007fff129fe000)
libboost_python.so.1.55.0 => /lib64/libboost_python.so.1.55.0
(0x00007f796caa0000)
libOpenCL.so.1 => /usr/lib64/nvidia-304xx/libOpenCL.so.1
(0x00007f796c89a000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f796c4cc000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f796c1bd000)
libm.so.6 => /lib64/libm.so.6 (0x00007f796beb4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f796bc9d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f796ba81000)
libc.so.6 => /lib64/libc.so.6 (0x00007f796b6c3000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f796b4c0000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f796b2bc000)
librt.so.1 => /lib64/librt.so.1 (0x00007f796b0b3000)
/lib64/ld-linux-x86-64.so.2 (0x0000003897600000)
--
-- Those who don't understand recursion are doomed to repeat it
4 years, 8 months
