octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OCL package 1.0.0 released


From: Philip Nienhuis
Subject: Re: OCL package 1.0.0 released
Date: Tue, 20 Aug 2019 23:57:08 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48

Matthias W. Klein wrote:
On 20.08.2019 00:08, PhilipNienhuis wrote:
Matthias W. Klein wrote
Hi Octave folks,

a new release of the OCL package providing OpenCL support for
parallelized calculations (including GPGPU) is available [1], version
1.0.0 .

It is the first package release which is fully compatible with all
recently released octave versions.  (Thanks to the "communications"
package, I learned a crucial octave programming technique.)  A summary
of all important user-visible changes is available online [2].

Users and developers can choose to either download and install the
package tarball [3], or clone the repo [4] and use 'make dist' and other
Makefile targets for local testing.

Feedback is welcome, by e-mail or project ticket.

I just tested ocl-1.0 on a cross-built dev Octave 6.0.0 on my Windows
7 box
with 2 graphics HW, i.e., built-in Intel plus an NVidia graphics card.
Results: ocl_tests works fine & gives no errors and the example in the
doc/README works fine compared to mimicking the commands in Octave.

While installing/building the package I got a LOT of errors along the
lines
of:

:
C:/Programs/Octave/OCTAVE~1.0_2/mingw64/bin/mkoctfile-6.0.0.exe
--verbose -c
ocl_ov_matrix.cc
g++ -c
-I/home/philip/devel/octdev/mxe/mxe_64b_20190808/usr/x86_64-w64-mingw32/include

-IC:\Progr
ams\Octave\OCTAVE~1.0_2\mingw64\include\octave-6.0.0\octave\..
-IC:\Programs\Octave\OCTAVE~1.0_2\m
ingw64\include\octave-6.0.0\octave
-IC:\Programs\Octave\OCTAVE~1.0_2\mingw64\include   -fopenmp -g
 -O2    ocl_ov_matrix.cc -o ocl_ov_matrix.o
ocl_ov_matrix.cc: In member function 'octave_base_ocl_matrix<AT>*
octave_base_ocl_matrix<AT>::ocl_
index_op(const octave_value_list&, bool)':
ocl_ov_matrix.cc:181:13: warning: 'error_state' is deprecated: [6]: this
variable is obsolete and
always has the value 0 [-Wdeprecated-declarations]
         if (error_state) break;
             ^~~~~~~~~~~
In file included from
c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\oct.h:33

:0,
                 from ocl_octave_versions.h:4,
                 from ocl_ov_matrix.h:37,
                 from ocl_ov_matrix.cc:32:
c:\programs\octave\octave~1.0_2\mingw64\include\octave-6.0.0\octave\error.h:551:26:

note: declared
 here
 extern OCTINTERP_API int error_state;
                          ^~~~~~~~~~~
ocl_ov_matrix.cc:190:11: warning: 'error_state' is deprecated: [6]: this
variable is obsolete and
always has the value 0 [-Wdeprecated-declarations]
:

so I'd suggest to update these statements so that ocl-1.0 isn't
outdated the
moment that Octave-6.1.0 is released. Perhaps some configure option
stuff is
needed for that.

Next try: on the virtualized HW of the VDI clients at work. Maybe
maybe it
works.

Nice work, Matthias!

Philip
Philip,

thanks for your dedicated evaluation and motivating comment.

The last months, I worked on making the OCL project compatible with
released versions of octave as prio #1. Doing the same with the octave
dev has been on my mind - as one of several ideas in which direction OCL
should grow in the future, maybe as the most important of these. (I
will, however, need to setup a new dedicated environment for that, in
short, so don't expect it tomorrow.)

Your tests clearly show very promising results with the octave dev, very
appreciated. And also show only little work left, probably only a few
encapsulations with preprocessor directives using an extended
ocl_octave_versions.h

In order to clarify for me: What difference will it make to have a
dev-compatible ocl package, what aspects are relevant to you octave
maintainers in practice for the package? Where do you see it in relation
to the octave (forge) project?

Please do keep me posted on you further tests as announced.

A lot of questions, Matthias. I think of myself not so much as a core dev but rather a contributor and OF package maintainer (io and mapping).

I merely wanted to test the package for you in its current state as you asked on the ML. Well, it was fun in the limited time I had available.

To be compatible with dev Octave now is primarily a convenience. It will make sure that you do not have to worry later if 5.2.0 is skipped and 6.1.0 is released instead. As for myself, I always use bleeding edge Octave, usually not "older" than one or two weeks. IMO it is always a good thing to try to be compatible with dev Octave, because when a new Octave is released it usually takes a few months to get OF packages updated. For end users that is not very motivating. But admittedly dev Octave can be a moving target.

While testing I got the impression that ocl by itself just provides a framework to build upon. To do useful things with it user code has to incorporate its functions, possibly with try/catch around it to follow another code path in case ocl isn't supported on the local HW. It's not as if ocl is a mere drop-in replacement for user code, it requires a little more.
Or did I get that wrong? I only briefly tested a few things.

Anyway, in my opinion ocl is a very useful and promising package. I'd like to try really big matrices to test if ocl really makes a difference but that'll have to wait a bit I'm afraid.

Philip









reply via email to

[Prev in Thread] Current Thread [Next in Thread]