Tester for openblas needed

Tester for openblas needed

[Marco Atzeri]

Hi,
before making an official cygwin package for OpenBlas (fast Blas)
http://www.openblas.net/

I would like some test from potential users.
The dynamic library is multicore, so it should work on "all" processors,
but unfortunately I can only test on my dual Core i5-3320M.

On this system the speedup of basic BLAS operation is notable.

1000x1000x1000 DGEMM tests give

for x86_64 architecture
  0.818047 s      2444.847301 MFLOPS      x86_64  netlib reference
  0.055000 s      36363.636364 MFLOPS     x86_64  openblas 2.12

for i686 architecture
  0.825001 s      2424.239486 MFLOPS      i686    netlib reference
  0.095001 s      21052.409975 MFLOPS     i686    openblas 2.12

Libraries are available on:
http://matzeri.altervista.org/x86/openblas/libopenblas_dynamic/
http://matzeri.altervista.org/x86_64/openblas/libopenblas_dynamic/

To use them is enough to copy the cygblas-0.dll in any path
directory before "/usr/lib/lapack" where the lapack one is located.

On http://matzeri.altervista.org/works/openblas/
there is also a DGEMM test routine, if you have no other benchmark.

Thanks in advance
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Tony Kelman]

> before making an official cygwin package for OpenBlas (fast Blas)
> http://www.openblas.net/
> 
> I would like some test from potential users.
> The dynamic library is multicore, so it should work on "all" processors,
> but unfortunately I can only test on my dual Core i5-3320M.

Neat, I'll give it a try. Do you have a cygport file you're working on
that I could look at? I build OpenBLAS quite regularly, though almost
always as a MinGW cross-compile, for use with Julia (www.julialang.org
if you're not familiar).

-Tony


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/20/2014 4:00 PM, Tony Kelman wrote:
>> before making an official cygwin package for OpenBlas (fast Blas)
>> http://www.openblas.net/
>>
>> I would like some test from potential users.
>> The dynamic library is multicore, so it should work on "all" processors,
>> but unfortunately I can only test on my dual Core i5-3320M.
>
> Neat, I'll give it a try. Do you have a cygport file you're working on
> that I could look at? I build OpenBLAS quite regularly, though almost
> always as a MinGW cross-compile, for use with Julia (www.julialang.org
> if you're not familiar).

look in the source package
http://matzeri.altervista.org/x86_64/openblas/

>
> -Tony

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Tony Kelman]

> look in the source package
> http://matzeri.altervista.org/x86_64/openblas/

Thanks. I'm a little surprised the cygblas-0.dll (x86_64, 0.2.12-1) does
not appear to be linked to libgfortran. Were you seeing your test
executables using multiple cores? I think you may have to build with
USE_THREAD=1 to enable threading (or USE_OPENMP=1 for openmp)?

I may be doing this wrong, but I'm getting errors from your openblas
build, but not the reference blas package, when I run the following:

$ curl -O 
https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.f
$ gfortran -o sblat2 sblat2.f -lblas
$ rm -f SBLAT2.SUMM
$ curl 
https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.dat | 
./sblat2

This outputs messages like:
** On entry to SGEMV  parameter number  1 had an illegal value
and so on for the other single-precision level 2 functions in that test.

This does seem to work okay on Linux or an existing i686-w64-mingw32 build.

-Tony


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/20/2014 6:16 PM, Tony Kelman wrote:
>> look in the source package
>> http://matzeri.altervista.org/x86_64/openblas/
>
> Thanks. I'm a little surprised the cygblas-0.dll (x86_64, 0.2.12-1) does
> not appear to be linked to libgfortran. Were you seeing your test
> executables using multiple cores? I think you may have to build with
> USE_THREAD=1 to enable threading (or USE_OPENMP=1 for openmp)?

openblas is written in C

USE_THREAD=1 and  USE_OPENMP=1, can be used dynamically ;
if I am not wrong.

> I may be doing this wrong, but I'm getting errors from your openblas
> build, but not the reference blas package, when I run the following:
>
> $ curl -O
> https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.f
> $ gfortran -o sblat2 sblat2.f -lblas
> $ rm -f SBLAT2.SUMM
> $ curl
> https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.dat |
> ./sblat2
>
> This outputs messages like:
> ** On entry to SGEMV  parameter number  1 had an illegal value
> and so on for the other single-precision level 2 functions in that test.
>
> This does seem to work okay on Linux or an existing i686-w64-mingw32 build.

It fails also on the netlib blas reference so it is not a specific 
openblas issue.
It must be something more general like
http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01441.html

During the OpenBlas build the test is passed

$ cat SBLAT2.SUMM
------------------------------------------
  TESTS OF THE REAL             LEVEL 2 BLAS

  THE FOLLOWING PARAMETER VALUES WILL BE USED:
    FOR N                   0     1     2     3     7    31    63
    FOR K                   0     1     2     4
    FOR INCX AND INCY       1     2    -1    -2
    FOR ALPHA             0.0   1.0   0.7
    FOR BETA              0.0   1.0   0.9

  ROUTINES PASS COMPUTATIONAL TESTS IF TEST RATIO IS LESS THAN   16.00

  RELATIVE MACHINE PRECISION IS TAKEN TO BE  1.2E-07

  SGEMV  PASSED THE TESTS OF ERROR-EXITS

  SGEMV  PASSED THE COMPUTATIONAL TESTS (  4324 CALLS)
[cut]
  SSYR2  PASSED THE TESTS OF ERROR-EXITS

  SSYR2  PASSED THE COMPUTATIONAL TESTS (   577 CALLS)

  SSPR2  PASSED THE TESTS OF ERROR-EXITS

  SSPR2  PASSED THE COMPUTATIONAL TESTS (   577 CALLS)

  END OF TESTS
-----------------------------------------------------

but the test program is built static, not linked to the dll.


> -Tony

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Tony Kelman]

> openblas is written in C

More assembly than C according to github's count. I'm used to building
the full version of openblas including their optimized implementations
of lapack routines, which bring in libgfortran. So nevermind.

> USE_THREAD=1 and  USE_OPENMP=1, can be used dynamically ;
> if I am not wrong.

What does your Makefile.conf say for NUM_CORES? I can't seem to get a
test program with your build to use more than 2 cores (I have 4 + HT)
by setting the OPENBLAS_NUM_THREADS environment variable.

-Tony


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/21/2014 1:33 AM, Tony Kelman wrote:
>> openblas is written in C
>
> More assembly than C according to github's count. I'm used to building
> the full version of openblas including their optimized implementations
> of lapack routines, which bring in libgfortran. So nevermind.

I avoided to include lapack as for compatibility
I will need to split exactly as netlib in

cygblas-0.dll
cyglapack-0.dll

something for the future.

>> USE_THREAD=1 and  USE_OPENMP=1, can be used dynamically ;
>> if I am not wrong.
>
> What does your Makefile.conf say for NUM_CORES? I can't seem to get a
> test program with your build to use more than 2 cores (I have 4 + HT)
> by setting the OPENBLAS_NUM_THREADS environment variable.

NUM_CORES=2
I will ask on the OpenBlas mailing list

> -Tony

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/21/2014 7:47 AM, Marco Atzeri wrote:
> On 10/21/2014 1:33 AM, Tony Kelman wrote:
>> What does your Makefile.conf say for NUM_CORES? I can't seem to get a
>> test program with your build to use more than 2 cores (I have 4 + HT)
>> by setting the OPENBLAS_NUM_THREADS environment variable.
>
> NUM_CORES=2
> I will ask on the OpenBlas mailing list

https://groups.google.com/forum/#!topic/openblas-users/2cxnw0tvd9A

"one of the testers noted that his quad core is unable to use more than
two cores; as the build machine is a two cores, is that causing the 
limitation ?

Yes.

There is a mode to override it ?

Use "make NUM_THREADS=n " to support n threads. "

So how many THREADS would you like to see ?

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Tony Kelman]

> I avoided to include lapack as for compatibility
> I will need to split exactly as netlib in
>
> cygblas-0.dll
> cyglapack-0.dll
>
> something for the future.

That makes sense, it gets packaged that way in debian and fedora too.
I think there's an open issue on openblas' tracker to add a build option
to split up the shared library that way, make packagers' lives easier.

Even netlib lapack will run faster with a better blas plugged in, so the
way you're doing it now with just the blas parts makes sense to start with.

> So how many THREADS would you like to see ?

I think 8 would cover the majority of users, 16 at the most. I've seen
cases where openblas can try to use threads on small problems where it
shouldn't need to, so it would be good to check whether it's smart about
avoiding oversubscription if you run it without setting 
OPENBLAS_NUM_THREADS.
Of course users who really want more threads can compile it themselves,
but it'll be convenient to have a fast blas easily hooked into Cygwin's
packages for numpy, R, octave, etc.

-Tony


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/21/2014 2:39 PM, Tony Kelman wrote:

>> So how many THREADS would you like to see ?
>
> I think 8 would cover the majority of users, 16 at the most. I've seen
> cases where openblas can try to use threads on small problems where it
> shouldn't need to, so it would be good to check whether it's smart about
> avoiding oversubscription if you run it without setting
> OPENBLAS_NUM_THREADS.

I will prepare another package

> Of course users who really want more threads can compile it themselves,
> but it'll be convenient to have a fast blas easily hooked into Cygwin's
> packages for numpy, R, octave, etc.

R uses it own blas+lapack so no improvement on that side.

> -Tony

Regards
Marco



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Achim Gratz]

Marco Atzeri writes:
> Use "make NUM_THREADS=n " to support n threads. "

Wait, what?

> So how many THREADS would you like to see ?

It should determine the number of cores at runtime as well as the level
of SSE/AVX support: i686 starts with the PentiumPro, which didn't have
SSE.  Fixing this at compile time is nice for local builds, but no good
for packages.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Tony Kelman]

> It should determine the number of cores at runtime as well as the level
> of SSE/AVX support: i686 starts with the PentiumPro, which didn't have
> SSE.  Fixing this at compile time is nice for local builds, but no good
> for packages.

As long as you set DYNAMIC_ARCH=1 (which Marco did), openblas does
exactly this when it comes to SIMD instruction sets (and more details
like tuning for different cache sizes, etc). They have optimized routines
for this list of processor families:
https://github.com/xianyi/OpenBLAS/blob/ac5a7e1c1bb75d1accfb83c394e1535b5ff170d2/driver/others/dynamic.c#L296-L318
the right implementation gets used based on runtime detection, which is
why the compiled dll is much larger than reference netlib blas.

Hopefully the number of threads you set at build time is just a maximum.
The library is explicitly designed so you can control the number of
threads used at runtime. What we're not sure about is what happens in
the default case when you don't manually set the number of threads.

-Tony


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/21/2014 7:49 PM, Tony Kelman wrote:

> Hopefully the number of threads you set at build time is just a maximum.
> The library is explicitly designed so you can control the number of
> threads used at runtime. What we're not sure about is what happens in
> the default case when you don't manually set the number of threads.
>
> -Tony
>


try openblas-0.2.12-2.x86_64

I think OPENBLAS_NUM_THREADS setting is not needed.

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/21/2014 6:59 PM, Achim Gratz wrote:
> Marco Atzeri writes:
>> Use "make NUM_THREADS=n " to support n threads. "
>
> Wait, what?
>
>> So how many THREADS would you like to see ?
>
> It should determine the number of cores at runtime as well as the level
> of SSE/AVX support: i686 starts with the PentiumPro, which didn't have
> SSE.  Fixing this at compile time is nice for local builds, but no good
> for packages.

Hi Achim,
feel free to require the feature upstream.
https://github.com/xianyi/OpenBLAS/issues

Building with NUM_THREADS=n should provide in the mean time
the maximum available.

The variable OPENBLAS_NUM_THREADS=m should allow to less than the 
maximum.

> Regards,
> Achim.

building rev -2 with  NUM_THREADS=16

Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Tester for openblas needed

[Marco Atzeri]

On 10/20/2014 11:56 PM, Marco Atzeri wrote:
> On 10/20/2014 6:16 PM, Tony Kelman wrote:
>
>> I may be doing this wrong, but I'm getting errors from your openblas
>> build, but not the reference blas package, when I run the following:
>>
>> $ curl -O
>> https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.f
>> $ gfortran -o sblat2 sblat2.f -lblas
>> $ rm -f SBLAT2.SUMM
>> $ curl
>> https://raw.githubusercontent.com/xianyi/OpenBLAS/develop/test/sblat2.dat
>> |
>> ./sblat2
>>
>> This outputs messages like:
>> ** On entry to SGEMV  parameter number  1 had an illegal value
>> and so on for the other single-precision level 2 functions in that test.
>>
>> This does seem to work okay on Linux or an existing i686-w64-mingw32
>> build.
>
> It fails also on the netlib blas reference so it is not a specific
> openblas issue.
> It must be something more general like
> http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg01441.html
>

I think the problem is in the test, changing one flag

--- sblat2.in~  2014-10-21 14:38:37.665617000 +0200
+++ sblat2.in   2014-10-21 14:47:33.515675400 +0200
@@ -4,7 +4,7 @@
  -1                UNIT NUMBER OF SNAPSHOT FILE (NOT USED IF .LT. 0)
  F        LOGICAL FLAG, T TO REWIND SNAPSHOT FILE AFTER EACH RECORD.
  F        LOGICAL FLAG, T TO STOP ON FAILURES.
-T        LOGICAL FLAG, T TO TEST ERROR EXITS.
+F        LOGICAL FLAG, T TO TEST ERROR EXITS.
  16.0     THRESHOLD VALUE OF TEST RATIO
  6                 NUMBER OF VALUES OF N
  0 1 2 3 5 9       VALUES OF N


both netlib and openblas pass the computational tests.

Regards
Marco




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple