Re: Perfromance problem running multiple copies of Octave on a multicore processor

[Ian McCallion]

Hi Olaf,

Thanks for helping me on this. Yes I agree serialisation is highly
improbable, especially because (as I realised after posting) the CPU
cores are all at 100% during the computation. For avoidance of doubt
the laptop has plenty of memory (although memory usage is a bit
highter with Octave 4.0.0) and disk is not touched during processing.

So far I have (I believe) eliminated openblas as a cause by retrying
my first experiments, trying both versions of Octave with both
versions of OpenBLAS. The bad performance definitely follows Octave
4.0.0.

I have also trimmed down my code greatly, checking at each stage that
the performance problem is still present. I am planning to instrument
the code to find where the excess time is being consumed before
trimming it further.

I'm not sure what your role is so this may be a silly question, but if
this turns out to be a real issue would it be helpful for you to have
the code at some point?

Cheers... Ian

On 1 December 2015 at 08:09, Olaf Till <address@hidden> wrote:
> On Mon, Nov 30, 2015 at 11:39:02PM +0000, Ian McCallion wrote:
>> ...
>> As far as I can see this proves that there is some serialisation going
>> on in Octave 4.0.0 that was not going on in Octave 3.8.2. It sounds
>> like a bug (system wide serialisation protecting a local resource?).
>
> Sounds improbable.
>
>> Has anyone got any suggestions for a workaround, alternative
>> explanations for the cause of the problem
>
> An explanation could be using up the common L2 cache of the processor
> cores, so that they must share the main memory bus. Maybe some
> calculation in the newer Octave is spread over a larger memory area.
>
>> or other tests I can run to
>> elucidate the problem.
>
> It could be useful to find the smallest possible unit (e.g a native
> Octave function, or a builtin function called by it) which shows your
> problem.
>
> Your idea with different BLAS libraries seemed good to me, make sure
> you tested this influence correctly.
>
> Olaf
>
> --
> public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net