Re: Possible (summer of code) projects for Octave

[Jaroslav Hajek]

On Tue, Jan 4, 2011 at 4:52 PM, David Bateman <address@hidden> wrote:
>
>
> Jaroslav Hajek-2 wrote:
>>
>> On Mon, Jan 3, 2011 at 8:10 PM, Daniel Kraft <address@hidden> wrote:
>>> Still,
>>> maybe there are currently some ideas or motivation to try something into
>>> that direction?  Otherwise, I also read something about attempts to make
>>> use
>>> of multiple cores -- this sounds interesting, too, are the ongoing
>>> projects
>>> towards (or interest in) that?  Some other things that would be useful
>>> for
>>> Octave and the user community?
>>>
>>
>> I think what Octave needs to be considered seriously in the future is
>> better support for high-level parallelism. Low-level cheap stuff like
>> parallelizing sum() is laughable, IMHO - might be good for MW to boost
>> their PR image, but in real life that will win you almost nothing. I
>> and D. Bateman actually experimented with code to parallelize some
>> element-wise matrix operations, and the results were, IMHO, poor.
>>
>
> Parallelizing the element-wise matrix operators gave poor performance, but
> parallelizing the mapper functions gave speed-ups that scaled well with the
> number of cores. In the thread
>
> http://octave.1599824.n4.nabble.com/Using-OpenMP-in-Octave-td1694553.html
>
> You tested with 2 threads and Kai Habel with 4 and you both showed nearly
> linear speed-up with the mapper functions. Kai on his AMD even showed slight
> improvements for the element-wise operators. I'd say its worth trying to
> improve the speed of the mappers.
>

Yes, I never objected to that, it's just harder than it seems because
of the exceptions issues.
It is possible to either
1. make the parallelizing code exception-safe
2. parallelize only mappers that don't throw exceptions (possibly
conditionally on configuration)

first I wanted to do 1., but eventually I realized that 2. would not
be that bad and probably simpler.
Regarding the multithreaded element-wise ops, we basically have a
patch. I would just object to putting it into 3.4. on the basis that
it is the most useless part of low-level multithreading. Octave don't
need to kid its users that it can do mt when it actually can't mt
anything useful.