Re: [ViennaCL-devel] PyViennaCL: Call for testing / advice (2)
Hi Toby, > So I've uploaded PyViennaCL packages which don't have the shared_ptr > troubles that my previous ones did (in the end, I split what used to be > a single Python extension into many smaller extensions under one package > namespace). These packages seem mostly to work, and (for instance), pass > my blas3_prod and blas3_solve tests. Try them out, if you can! Hmm, it's not very satisfactory if we don't yet know what the issue was... > > There still seems to be something weird going on, though: > >$ python3 tests/pyviennacl/vector_operations.py >-- >-- >## Test :: vector operations >-- >-- >*** Using float numeric type *** ># Testing setup: > eps: 0.001 >Now using A=vector, B=vector, C=vector >Test: initialisation of vector with CPU scalar passed >Test: initialisation of vector with ndarray passed >Test: initialisation of vector with Vector passed >Test: negation passed >Test: in-place scale (multiplication) passed >Test: in-place add passed >ERROR 2013-12-21 22:55:43,949 pyviennacl.pycore 2759 execute > EXCEPTION EXECUTING: InplaceAdd(Vector, Mul(Vector, > Scalar)=>Vector)=>Vector >Traceback (most recent call last): > File "tests/pyviennacl/vector_operations.py", line 458, in >sys.exit(test()) > File "tests/pyviennacl/vector_operations.py", line 444, in test >test_vector_slice(run_test, epsilon, p.float32, 11) > File > "/home/toby/src/viennacl/pyviennacl-dev/tests/pyviennacl/test_common.py", > line 124, in test_vector_slice >dtype = dtype) > File "tests/pyviennacl/vector_operations.py", line 109, in run_test >vcl_A += alpha * vcl_B > File "/usr/lib/python3/dist-packages/pyviennacl/pycore.py", line 530, in > __iadd__ >op.execute() > File "/usr/lib/python3/dist-packages/pyviennacl/pycore.py", line 2101, > in execute >self._result = s.execute() > File "/usr/lib/python3/dist-packages/pyviennacl/pycore.py", line 2757, > in execute >self.vcl_statement.execute() >RuntimeError: ViennaCL: Internal memory error: unknown memory handle > (memory_read)! > > > This seems to be reproducible where something like this happens: > >$ python3 >Python 3.3.3 (default, Dec 8 2013, 15:11:36) >[GCC 4.8.2] on linux >Type "help", "copyright", "credits" or "license" for more information. >>>> import pyviennacl as p >>>> x = p.Vector(5, 2.0, dtype=p.float32) >>>> y = p.Vector(5, 0.3, dtype=p.float32) >>>> a = p.Scalar(p.float32(2.0)) >>>> b = p.HostScalar(p.float32(5.0)) >>>> x *= a >ERROR 2013-12-21 23:13:14,927 pyviennacl.pycore 2759 execute > EXCEPTION EXECUTING: Assign(Vector, Mul(Vector, > Scalar)=>Vector)=>NoResult >Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/pyviennacl/pycore.py", line 571, in > __imul__ >return op.result > File "/usr/lib/python3/dist-packages/pyviennacl/pycore.py", line 2090, > in result >self.execute() > File "/usr/lib/python3/dist-packages/pyviennacl/pycore.py", line 2101, > in execute >self._result = s.execute() > File "/usr/lib/python3/dist-packages/pyviennacl/pycore.py", line 2757, > in execute >self.vcl_statement.execute() >RuntimeError: ViennaCL: Internal memory error: unknown memory handle > (memory_read)! >>>> x.value >array([ 2., 2., 2., 2., 2.], dtype=float32) >>>> y *= b >>>> y.value >array([ 1.5, 1.5, 1.5, 1.5, 1.5], dtype=float32) > > > I haven't yet written up a pure C++ test case, but it seems to be the > case that performing arithmetic operations via the scheduler using > device scalars on (device) vectors and matrices results in memory > errors; if this isn't because of my code reorganisation, then it's a > regression. Unless someone beats me to it, I'll check the C++ case > sometime tomorrow or the day after. > > Operations like this via the scheduler work fine right now: >>>> x += y >>>> x.value >array([ 3.5, 3.5, 3.5, 3.5, 3.5], dtype=float32) Hmm, I created a C++ test case for x *= a, but everything worked out. I also checked the corresponding scheduler code, there's also nothing suspicious. The internal memory error looks as if 'x' or 'a' is not created properly. Do other operations with Scalars work? Best regards, Karli -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://
Re: [ViennaCL-devel] PyViennaCL: Call for testing / advice (2)
Hi Karl, Karl Rupp writes: > > So I've uploaded PyViennaCL packages which don't have the shared_ptr >> troubles that my previous ones did (in the end, I split what used to be >> a single Python extension into many smaller extensions under one package >> namespace). These packages seem mostly to work, and (for instance), pass >> my blas3_prod and blas3_solve tests. Try them out, if you can! > > Hmm, it's not very satisfactory if we don't yet know what the issue was... Well, I'm pretty sure that the issue originated somewhere in the pointer handling in boost::python or the Python garbage collector, since I didn't do any deletion or freeing myself (as the lifetime of any objects created by pyviennacl is tied to objects created in Python, and so that has to be handled by Python). It just seemed to me that writing return value policies for boost::python in a blind attempt to keep objects around -- or trying to debug the garbage collector -- was too much of a distraction, especially given that I had this alternative available.. > Hmm, I created a C++ test case for x *= a, but everything worked out. I > also checked the corresponding scheduler code, there's also nothing > suspicious. The internal memory error looks as if 'x' or 'a' is not > created properly. Do other operations with Scalars work? Hmm. Any operation involving a (GPU) Scalar and some higher-dimensional object (matrix or vector) fails. However, scalar arithmetic (eg, a += b for scalar a and b) succeeds in PyViennaCL, but this doesn't go via ViennaCL; it seemed overkill for something that CPUs are pretty good at, and is well-supported in Python anyway. But both vector and scalar seem to be constructed correctly -- I can get access to the underlying ViennaCL objects using the `vcl_leaf' attribute. For example (GPU scalar b, vector x): >>> b.vcl_leaf.to_host() 0.04001 >>> x.vcl_leaf.as_ndarray() array([ 5., 5., 5., 5., 5.]) I'll dig around some more... Cheers, Toby -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
Re: [ViennaCL-devel] PyViennaCL: Call for testing / advice (2)
Toby St Clere Smithe writes: > I'll dig around some more... So it turned out that it wasn't anything to do with my previous error, just that having split up the files, I had not put the OpenCL #define in all the right places. In fact, come to think of it, that may be the cause of the shared_ptr troubles. Agh!! Cheers, Toby -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
Re: [ViennaCL-devel] PyViennaCL: Call for testing / advice (2)
Hey, > So it turned out that it wasn't anything to do with my previous error, > just that having split up the files, I had not put the OpenCL #define in > all the right places. > > In fact, come to think of it, that may be the cause of the shared_ptr > troubles. Agh!! Ah, I see. What about setting the defines globally through the CMake build system? That should be far less error-prone and easier to configure... Best regards, Karli -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
Re: [ViennaCL-devel] PyViennaCL: Call for testing / advice (2)
Karl Rupp writes: > Ah, I see. What about setting the defines globally through the CMake > build system? That should be far less error-prone and easier to configure... Quite...! :) -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
[ViennaCL-devel] ViennaCL 1.5.0 released!
Dear ViennaCL users, ViennaCL 1.5.0 is finally out and available for download at http://viennacl.sourceforge.net/ It introduces a couple of new convenience routines, performance improvements, and higher code quality. Most important changes from the changelogs: - Vectors and matrices can be instantiated with integer template types (long, int, short, char). - Added support for element_prod() and element_div() for dense matrices. - Added element_pow() for vectors and matrices. - Added norm_frobenius() for computing the Frobenius norm of dense matrices. - Added unary element-wise operations for vectors and dense matrices: element_sin(), element_sqrt(), etc. - Multiple OpenCL contexts can now be used in a multi-threaded setting (one thread per context). - Multiple inner products with a common vector can now be computed efficiently via e.g.~inner_prod(x, tie(y, z)); - Added support for prod(A, B), where A is a sparse matrix type and B is a dense matrix (thanks to Albert Zaharovits for providing parts of the implementation). - Added diag() function for extracting the diagonal of a vector to a matrix, or for generating a square matrix from a vector with the vector elements on a diagonal (similar to MATLAB). - Added row() and column() functions for extracting a certain row or column of a matrix to a vector. - Certain BLAS functionality in ViennaCL is now also available through a shared library (libviennacl). - API-change: User-provided OpenCL kernels extract their kernels automatically. A call to add_kernel() is now obsolete, hence the function was removed. - API-change: Device class has been extend and supports all informations defined in the OpenCL 1.1 standard through member functions. Duplicate compute_units() and max_work_group_size() have been removed (thanks for Shantanu Agarwal for the input). - API-change: viennacl::copy() from a ViennaCL object to an object of non-ViennaCL type no longer tries to resize the object accordingly. An assertion is thrown if the sizes are incorrect in order to provide a consistent behavior across many different types. - Datastructure change: Vectors and matrices are now padded with zeros by default, resulting in higher performance particularly for matrix operations. This padding needs to be taken into account when using fast_copy(), particularly for matrices. The full change logs can be found at http://viennacl.sourceforge.net/changelog.txt Thanks to all contributors :-) Best regards and best wishes for 2014, Karl Rupp -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
Re: [ViennaCL-devel] PyViennaCL: Call for testing / advice (2)
Hey, >> Ah, I see. What about setting the defines globally through the CMake >> build system? That should be far less error-prone and easier to configure... > > Quite...! :) :-) Okay, 1.5.0 is out, I'll fall asleep now and start testing pyViennaCL asap. Best regards, Karli -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
Re: [ViennaCL-devel] ViennaCL 1.5.0 released!
Hey Karl! Congratulations! ViennaCL 1.5.0 is a pretty cool release :) In fact, there are still some features that I don't have in PyViennaCL: Karl Rupp writes: > - Added norm_frobenius() for computing the Frobenius norm of dense > matrices. > - Multiple OpenCL contexts can now be used in a multi-threaded setting > (one thread per context). > - Multiple inner products with a common vector can now be computed > efficiently via e.g.~inner_prod(x, tie(y, z)); > - Added support for prod(A, B), where A is a sparse matrix type and B > is a dense matrix (thanks to Albert Zaharovits for providing parts of > the implementation). > - Added diag() function for extracting the diagonal of a vector to a > matrix, or for generating a square matrix from a vector with the vector > elements on a diagonal (similar to MATLAB). > - Added row() and column() functions for extracting a certain row or > column of a matrix to a vector. I think I will add these to my to-do list; luckily, things like diag(), row() and column() are pretty easy to do using NumPy, but the other bits would be particularly desirable. I'll probably aim to get a 1.0.0 release out, first, though -- these bits can wait for 1.1.0 early in the New Year, and I'll probably leave multi-threading out for now... Hm, I should probably create a public roadmap page of my own.. Best wishes, Toby -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
Re: [ViennaCL-devel] PyViennaCL: Call for testing / advice (2)
Hi again, Karl Rupp writes: > Okay, 1.5.0 is out, I'll fall asleep now and start testing pyViennaCL asap. Yes -- get some rest, and by the morning, some fixed pyviennacl packages will be available ready for testing in the Ubuntu PPA :) Cheers, Toby -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
Re: [ViennaCL-devel] ViennaCL 1.5.0 released!
Hey Karl, Awesome ! Philippe 2013/12/23 Karl Rupp > Dear ViennaCL users, > > ViennaCL 1.5.0 is finally out and available for download at > http://viennacl.sourceforge.net/ > It introduces a couple of new convenience routines, performance > improvements, and higher code quality. Most important changes from the > changelogs: > > - Vectors and matrices can be instantiated with integer template types > (long, int, short, char). > > - Added support for element_prod() and element_div() for dense matrices. > > - Added element_pow() for vectors and matrices. > > - Added norm_frobenius() for computing the Frobenius norm of dense > matrices. > > - Added unary element-wise operations for vectors and dense matrices: > element_sin(), element_sqrt(), etc. > > - Multiple OpenCL contexts can now be used in a multi-threaded setting > (one thread per context). > > - Multiple inner products with a common vector can now be computed > efficiently via e.g.~inner_prod(x, tie(y, z)); > > - Added support for prod(A, B), where A is a sparse matrix type and B > is a dense matrix (thanks to Albert Zaharovits for providing parts of > the implementation). > > - Added diag() function for extracting the diagonal of a vector to a > matrix, or for generating a square matrix from a vector with the vector > elements on a diagonal (similar to MATLAB). > > - Added row() and column() functions for extracting a certain row or > column of a matrix to a vector. > > - Certain BLAS functionality in ViennaCL is now also available through > a shared library (libviennacl). > > - API-change: User-provided OpenCL kernels extract their kernels > automatically. A call to add_kernel() is now obsolete, hence the > function was removed. > > - API-change: Device class has been extend and supports all > informations defined in the OpenCL 1.1 standard through member > functions. Duplicate compute_units() and max_work_group_size() have been > removed (thanks for Shantanu Agarwal for the input). > > - API-change: viennacl::copy() from a ViennaCL object to an object of > non-ViennaCL type no longer tries to resize the object accordingly. An > assertion is thrown if the sizes are incorrect in order to provide a > consistent behavior across many different types. > > - Datastructure change: Vectors and matrices are now padded with zeros > by default, resulting in higher performance particularly for matrix > operations. This padding needs to be taken into account when using > fast_copy(), particularly for matrices. > > The full change logs can be found at > http://viennacl.sourceforge.net/changelog.txt > > Thanks to all contributors :-) > > Best regards and best wishes for 2014, > Karl Rupp > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > ViennaCL-devel mailing list > ViennaCL-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/viennacl-devel > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
