Re: [eigen] Status of non-OpenMP-based multithreading

2016-03-07 11:42 GMT-05:00 Benoit Jacob <jacob.benoit.1@xxxxxxxxxx>:

2016-03-07 11:24 GMT-05:00 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:

On Mon, Mar 7, 2016 at 4:54 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
For instance, neither iOS nor Android support OpenMP, so "mobile" is out.

I really though that the ndk v9 supported OpenMP. My android ndk contains one libgomp.a lib for each target architecture...

My goodness, you're right! Didn't realize that OpenMP support had been added.

So remove Android from the list of platforms lacking OpenMP support... but add it to the list of example of OpenMP performance issues!

Here on Nexus 5, NDK r10d, GCC 4.8 toolchain:

Single-threaded:

Multiplying 16x16 matrices at 3..58674 GFlop/s
Multiplying 32x32 matrices at 7.78734 GFlop/s
Multiplying 64x64 matrices at 10.9491 GFlop/s
Multiplying 128x128 matrices at 10..3883 GFlop/s
Multiplying 256x256 matrices at 10.436 GFlop/s
Multiplying 512x512 matrices at 11.1344 GFlop/s
Multiplying 1024x1024 matrices at 12.029 GFlop/s

OpenMP:

Multiplying 16x16 matrices at 3.45773 GFlop/s
Multiplying 32x32 matrices at 7.60419 GFlop/s
Multiplying 64x64 matrices at 17.0943 GFlop/s
Multiplying 128x128 matrices at 16.5397 GFlop/s
Multiplying 256x256 matrices at 28.2393 GFlop/s
Multiplying 512x512 matrices at 30.1025 GFlop/s
Multiplying 1024x1024 matrices at 15.8382 GFlop/s

As you can see: performance collapses at size 1024.

Actually, just increasing the duration of this benchmark 'fixes' this issue, and performance then converges to 38 GFlop/s, which is pretty good for this device.

I don't know to what extent that means that there is no issue, vs. that OpenMP's interaction with the OS's scheduler causes a longer ramp-up.

Still, very useful to know that Android now has OpenMP - thanks!

For OSX, there are better compilers than Apple's one.

There are a lot of project which, for various reasons, want to stick to the first-party toolchain on Apple platforms. So regardless of the availability of other toolchains, the first-party one needs to be treated as a "platform" as far as we're concerned - similarly to how we care about MSVC on Windows even though other compilers are available there.

It thus remains iOS.

gael