Re: OCL package 1.0.0 released

[Matthias W. Klein]

On 20.08.2019 23:57, Philip Nienhuis wrote:
> Matthias W. Klein wrote:
> > On 20.08.2019 00:08, PhilipNienhuis wrote:
> > > 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.

Dear Philip and octave maintainers!

Your package testing with dev octave is highly valued, in past and
future, Philip!

My questions about the package compatibility with dev octave was aimed
at all maintainers - also giving you the opportunity to start the
discussion with your assessment (thank you for picking up the ball,
Philip). Your point towards convenience convinces me and fits to my
(previously vague) understanding. Agreed, compatibility is worthwhile
and attractive for the near future.

@Maintainers:
a) So is it that each package release should be tested against a recent
dev octave before release?
b) How is the other way usually handled, with all existing OF packages?
Is it each package maintainer's responsibility to re-achieve package
compatibility after octave release, or is some other way of
collaboration common?
I consider myself a newbie in these respects, thanks for letting me know.

>
> 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.

Ocl as "just a framework": If you like to strongly simplify it, yes. As
is all of octave in the first place: The user has to put in code to get
meaningful results which are of value to him/her.

In analogy, at least to a certain extent, this is the purpose of the ocl
package: Give the user the ability to (hopefully) accelerate his/her
code using present hardware. Another analogy is Mathworks' 'gpuArray'
functionality [1], which, as far as documented, must have concerned
somewhat consequently rewriting "all" their core math functions to also
work with this GPU data type (in my interpretation from their doc; I
never had access to Mathworks' parallel computing package for testing).
Well, not fully: They say math functions which shall output complex
numbers must be fed with complex number data as input.

The ocl package implements many math functions and operators for
oclArray data (but surely not as much as the Mathworks package today).
Much octave code can simply be reused with ocl. But I have not tested
what octave functions beyond those in ocl_test.m actually run already today.

What I have done with ocl, for instance, is write a complete Monte Carlo
simulation (with 1e5 to 1e8 particles) in three different ways:
1) pure octave code of ~1000 summed lines,
2) the very same code with ~10 lines added at the beginning/end, to
completely work with ocl math functions and operators, and
3) translating the code to OpenCL C and using 'ocl_program'.
My results were:
a) The OpenCL C code ran almost a factor of 1000 faster than pure octave
code, using a good but old GPU.
b) The code using ocl math functions and operators was slower than
octave, even for large datasets, due to overhead.

This having said, I think the ocl package is very good at the following:

* Provide a detailed infrastructure between octave, the (correctly
installed) OpenCL software and the (chosen) OpenCL hardware.

* Provide best acceleration with user-written OpenCL C code, which is
handled by ocl interactively.

* Provide handy means (functions, operators, indexing) for inspection of
intermediate and end result data.

The package is currently not so efficient or good at:

* Provide efficient acceleration with standard functions and operators.

* Work with complex numbers.

I have had an active look into complex numbers as a future major
extension to ocl.

As to efficient standard functions and operators for re-using octave
code: I have had a few thoughts about more efficient workload
distribution models in ocl_array(_prog).cc, this might be a lightweight
improvement. The alternative would be to fall back onto an established
OpenCL-related math library, like clBLAS(T) [2,3] or MAGMA [4], but,
given the ocl structure, this would raise technical (library calls,
dependencies) and/or licensing questions.

In general, I think the ocl package will never cover all possible
standard functions and operators efficiently, the effort is simply too much.

But I do see, as you do, Philip, that the package can be of great use
for a broad audience of octave users, and have designed the package
correspondingly. I can well imagine ocl to become an OF package, but I
do not know what you maintainers or OF admins require in practice for
this step? (Yes, I have read [5], conform to most of it, and am willing
to discuss the rest. With whom?) Also, the decision community vs.
external package seems crucial. The package itself contains about 10000
lines of C++ code and a few points will have to be adapted slightly in a
concerted action as the octave interface for oct-files evolves. What
procedure is expected or common?

@Maintainers: Who can kindly assist me with the latter questions?

Thanks,
Matt

[1] https://www.mathworks.com/help/parallel-computing/gpuarray.html
[2] https://github.com/clMathLibraries/clBLAS
[3] https://github.com/CNugteren/CLBlast
[4] https://icl.cs.utk.edu/magma/
[5] https://octave.sourceforge.io/developers.php