bugGNU Octave - Bugs: bug #63184, [MXE Octave] AMD ZEN AOCL library...

 
 

bug #63184: [MXE Octave] AMD ZEN AOCL library support for blas, lapack and fftw

Submitter:  Jinchuan Tang <jinchuantang>
Submitted:  Sat 08 Oct 2022 01:13:21 PM UTC
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Mon 10 Oct 2022 10:58:38 AM UTC, comment #19: 

Test failures with blis:

***** warning <rcond = > assert (inv (Inf (2,2)), NaN (2,2))
!!!!! warning failed.
Expected warning <rcond = >, but got error <ASSERT errors for:  assert (inv (Inf (2, 2)),NaN (2, 2))

  Location  |  Observed  |  Expected  |  Reason
   (1,1)          0           NaN        'NaN' mismatch
   (2,1)          0           NaN        'NaN' mismatch>

***** test
 [xinv, rcond] = inv (Inf (2,2));
 assert (xinv, NaN (2,2));
 assert (rcond, NaN);
!!!!! test failed
ASSERT errors for:  assert (xinv,NaN (2, 2))

  Location  |  Observed  |  Expected  |  Reason
   (1,1)          0           NaN        'NaN' mismatch
   (2,1)          0           NaN        'NaN' mismatch

***** assert <*60797> (sqrtm (ones (4))^2, ones (4), 5*eps)
!!!!! regression: https://octave.org/testfailure/?60797
ASSERT errors for:  assert (sqrtm (ones (4)) ^ 2,ones (4),5 * eps)

  Location  |  Observed  |  Expected  |  Reason
   (1,1)       NaN+NaNi        1         'NaN' mismatch
   (2,1)       NaN+NaNi        1         'NaN' mismatch
   (3,1)       NaN+NaNi        1         'NaN' mismatch
   (4,1)       NaN+NaNi        1         'NaN' mismatch
   (1,2)       NaN+NaNi        1         'NaN' mismatch
   (2,2)       NaN+NaNi        1         'NaN' mismatch
   (3,2)       NaN+NaNi        1         'NaN' mismatch
   (4,2)       NaN+NaNi        1         'NaN' mismatch
   (1,3)       NaN+NaNi        1         'NaN' mismatch
   (2,3)       NaN+NaNi        1         'NaN' mismatch
   (3,3)       NaN+NaNi        1         'NaN' mismatch
   (4,3)       NaN+NaNi        1         'NaN' mismatch
   (1,4)       NaN+NaNi        1         'NaN' mismatch
   (2,4)       NaN+NaNi        1         'NaN' mismatch
   (3,4)       NaN+NaNi        1         'NaN' mismatch
   (4,4)       NaN+NaNi        1         'NaN' mismatch

***** test
 warning ("off", "Octave:nearly-singular-matrix", "local");
 x = 1000 + (-5:5);
 xn = (x - mean (x)) / std (x);
 pn = ones (1,5);
 y = polyval (pn, xn);
 n = numel (pn) - 1;
 [p, s, mu] = polyfit (x, y, n);
 [p2, s2] = polyfit (x, y, n);
 assert (p, pn, s.normr);
 assert (s.yf, y, s.normr);
 assert (mu, [mean(x), std(x)]);
 assert (s.normr/s2.normr < sqrt (eps));
!!!!! test failed
ASSERT errors for:  assert (p,pn,s.normr)

  Location  |  Observed  |  Expected  |  Reason
    (3)           1            1         Abs err 1.7764e-15 exceeds tol 1.6241e-15 by 2e-16

(that looks fairly benign)

Performance-wise it seems to outperform openblas at least
in some benchmarks. E.g.:

$ BLIS_NUM_THREADS=16 LD_PRELOAD=/opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libblis-mt.so octave -q
octave:1> a=randn(5000);
octave:2> tic; inv(a)*a; toc
Elapsed time is 1.43057 seconds.

$ OMP_NUM_THREADS=16 octave -q
octave:1> a=randn(5000);
octave:2> tic; inv(a)*a; toc
Elapsed time is 1.8783 seconds.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2022 10:17:00 AM UTC, comment #18: 

It gets better (though still slower than openblas)
if I use both libflame and libblis:

$ BLIS_NUM_THREADS=16 LD_PRELOAD=/opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libflame.so:/opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libblis-mt.so octave -q
octave:1> t_chol
octave:2> cumulate
cumulate = 1.8110
octave:3>

[dima@ryzen clang_opt]$ BLIS_NUM_THREADS=8 LD_PRELOAD=/opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libflame.so:/opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libblis-mt.so octave -q
octave:1> t_chol
octave:2> cumulate
cumulate = 2.0418

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2022 10:07:25 AM UTC, comment #17: 

Also, allegedly, libflame is very good at Cholesky decomposition.
But I do not see this (perhaps I am doing smth wrong):

Test script:

cat t_chol.m
runs = 10;
cumulate = 0;
b = zeros(5000);
for ii = 1:runs
  a = randn(5000);
  a = a'*a;
  tic;
    b = chol(a);
  timing = toc;
  cumulate = cumulate + timing;
end

$ OMP_NUM_THREADS=8 LD_PRELOAD=/opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libflame.so octave -q
octave:1> t_chol
octave:2> cumulate
cumulate = 6.1918
octave:3>

$ OMP_NUM_THREADS=8 octave -q
octave:1> t_chol
octave:2> cumulate
cumulate = 2.2371

$ OMP_NUM_THREADS=16 LD_PRELOAD=/opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libflame.so octave -q
octave:1> t_chol
octave:2> cumulate
cumulate = 6.0178
octave:3>

$ OMP_NUM_THREADS=16 octave -q
octave:1> t_chol
octave:2> cumulate
cumulate = 1.7002

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2022 09:34:26 AM UTC, comment #16: 

Thanks.
Without having looked into it in any depth: The first group of tests might be too restrictive. The result might still be correct with that symmetry.
The Inf vs. NaN mismatch might be testing undefined behavior. But it is kind of unintuitive why `inv(NaN(2,2))` would result in `Inf` values.

Markus Mützel <mmuetzel>
Project Member
Mon 10 Oct 2022 09:24:59 AM UTC, comment #15: 

Anyway here is octave test failures with libflame (8 total):

 ***** test
 [u, s, v] = svd (single ([1, 2; 2, 1]));
 x = single (1 / sqrt (2));
 assert (u, [-x, -x; -x, x], sqrt (eps ("single")));
 assert (s, single ([3, 0; 0, 1]), sqrt (eps ("single")));
 assert (v, [-x, x; -x, -x], sqrt (eps ("single")));
!!!!! test failed
ASSERT errors for:  assert (u,[-x, -x; -x, x],sqrt (eps ("single")))

  Location  |  Observed  |  Expected  |  Reason
   (1,2)       0.70711      -0.70711     Abs err 1.4142 exceeds tol 0.00034527 by 1
   (2,2)       -0.70711     0.70711      Abs err 1.4142 exceeds tol 0.00034527 by 1

***** test
 A = {
   [], [];
   zeros(1,0), [];
   zeros(4,0), [];
   zeros(0,1), 1;
   zeros(0,4), eye(4);
   0, 1;
   1, zeros(1,0);
   [1 0; 0 1], zeros(2,0);
   [1 0; 1 0], [0 1]';
 };
 for i = 1:rows (A)
   assert (null (A{i,1}), A{i,2});
   assert (null (single (A{i,1})), single (A{i,2}));
 endfor
!!!!! test failed
ASSERT errors for:  assert (null (single (A {i, 1})),single (A {i, 2}))

  Location  |  Observed  |  Expected  |  Reason
    (2)           -1           1         Abs err 2 exceeds tol 0 by 2
***** test
 A = {
   [1 1; 0 0], [-1/sqrt(2) 1/sqrt(2)]';
 };
 for i = 1:rows (A)
   assert (null (A{i,1}), A{i,2}, eps);
   assert (null (single (A{i,1})), single (A{i,2}), eps);
 endfor
!!!!! test failed
ASSERT errors for:  assert (null (single (A {i, 1})),single (A {i, 2}),eps)

  Location  |  Observed  |  Expected  |  Reason
    (1)        0.70711      -0.70711     Abs err 1.4142 exceeds tol 2.2204e-16 by 1
    (2)        -0.70711     0.70711      Abs err 1.4142 exceeds tol 2.2204e-16 by 1
***** test
 tol = 1e-4;
 A = {
   @(e) [1 0; 0 tol-e], [0 1]';
   @(e) [1 0; 0 tol+e], zeros(2,0);
 };
 for i = 1:rows (A)
   assert (null (A{i,1}(eps ("double")), tol), A{i,2});
   assert (null (single (A{i,1}(eps ("single"))), tol), single (A{i,2}));
 endfor
!!!!! test failed
ASSERT errors for:  assert (null (single (A {i, 1} (eps ("single"))), tol),single (A {i, 2}))

  Location  |  Observed  |  Expected  |  Reason
    (2)           -1           1         Abs err 2 exceeds tol 0 by 2

***** warning <rcond = > assert (inv (Inf (2,2)), NaN (2,2))
!!!!! warning failed.
Expected warning <rcond = >, but got error <ASSERT errors for:  assert (inv (Inf (2, 2)),NaN (2, 2))

  Location  |  Observed  |  Expected  |  Reason
   (1,1)         Inf          NaN        'NaN' mismatch
   (2,1)         Inf          NaN        'NaN' mismatch
   (1,2)         Inf          NaN        'NaN' mismatch
   (2,2)         Inf          NaN        'NaN' mismatch>

***** test
 [xinv, rcond] = inv (Inf (2,2));
 assert (xinv, NaN (2,2));
 assert (rcond, NaN);
!!!!! test failed
ASSERT errors for:  assert (xinv,NaN (2, 2))

  Location  |  Observed  |  Expected  |  Reason
   (1,1)         Inf          NaN        'NaN' mismatch
   (2,1)         Inf          NaN        'NaN' mismatch
   (1,2)         Inf          NaN        'NaN' mismatch
   (2,2)         Inf          NaN        'NaN' mismatch
***** warning <rcond = > assert (inv (NaN (2,2)), NaN (2,2))
!!!!! warning failed.
Expected warning <rcond = >, but got error <ASSERT errors for:  assert (inv (NaN (2, 2)),NaN (2, 2))

  Location  |  Observed  |  Expected  |  Reason
   (1,1)         Inf          NaN        'NaN' mismatch
   (2,1)         Inf          NaN        'NaN' mismatch
   (1,2)         Inf          NaN        'NaN' mismatch
   (2,2)         Inf          NaN        'NaN' mismatch>

***** test
 [xinv, rcond] = inv (NaN (2,2));
 assert (xinv, NaN (2,2));
 assert (rcond, NaN);
!!!!! test failed
ASSERT errors for:  assert (xinv,NaN (2, 2))

  Location  |  Observed  |  Expected  |  Reason
   (1,1)         Inf          NaN        'NaN' mismatch
   (2,1)         Inf          NaN        'NaN' mismatch
   (1,2)         Inf          NaN        'NaN' mismatch
   (2,2)         Inf          NaN        'NaN' mismatch

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2022 09:03:50 AM UTC, comment #14: 

nm -p /usr/lib64/liblapack.so | grep lsame
0000000000195837 t .annobin_lsame_.start
0000000000195879 t .annobin_lsame_.end
0000000000195879 t .annobin_lsamen_.start
00000000001958fe t .annobin_lsamen_.end
0000000000195840 T lsame_
0000000000195880 T lsamen_

nm -p /usr/lib64/libblas.so | grep lsame
000000000000489b t .annobin_lsame_.start
00000000000048d9 t .annobin_lsame_.end
00000000000048a0 T lsame_

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2022 08:55:41 AM UTC, comment #13: 

Sorry:

nm -p /opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libflame.so | grep lsame
0000000000896300 T lsamen_
000000000095a890 T lsamen
00000000008962c0 T lsame_
0000000000caf900 T LAPACKE_lsame
0000000000941be0 T fla_lsame

With objfump I need to provide -d option or It does not show anything.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2022 08:50:44 AM UTC, comment #12: 

@Jinchuan Tang: Thanks. It looks like `lsame` is imported from `AOCL-LibBlis-Win-MT-dll.dll`.
From the output in comment #7, we see that `lsame_` isn't exported by that libflame binary. The upstream PR (if accepted) might fix that.

@Dmitri: Afaict, `lsamen` is a LAPACK function. IIUC, this report is about the (BLAS) function `lsame` (without the `n` at the end).

Markus Mützel <mmuetzel>
Project Member
Mon 10 Oct 2022 08:43:30 AM UTC, comment #11: 

FYI
On linux:

nm -p /opt/AMD/aocl/aocl-linux-gcc-3.2.0/lib_LP64/libflame.so | grep lsamen
0000000000896300 T lsamen_
000000000095a890 T lsamen

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2022 08:24:04 AM UTC, comment #10: 

Dear Markus,
please see the attachment .
Thank you !

Best wishes,
Jinchuan

Anonymous
Mon 10 Oct 2022 08:17:21 AM UTC, comment #9: 

I opened a pull request for upstream libflame that might fix that issue:
https://github.com/flame/libflame/pull/82

Markus Mützel <mmuetzel>
Project Member
Mon 10 Oct 2022 07:41:28 AM UTC, comment #8: 

Hmm. It looks like flame doesn't export that symbol.
With the binary of the reference (netlib) LAPACK bundled with Octave for Windows:

$ objdump.exe -p /mingw64/bin/liblapack.dll | grep lsame
        [ 978] lsame_
        [ 979] lsamen_

I'm not sure if I read the lines you pasted correctly. But it looks like that library is importing that symbol from some other library.

Looking at the reference documentation, it might be that this symbol should indeed be exported by the BLAS library (not the LAPACK library):
https://netlib.org/lapack/explore-html/d0/d73/group__aux__blas_gada799b40a93f1fd2c6d1a86a95f21631.html#gada799b40a93f1fd2c6d1a86a95f21631

But it might also be that the reference implementation defines the "de facto standard".
Reading the build rules, it seems to be intentional that the reference LAPACK implementation (also) exports `lsame`:
https://github.com/Reference-LAPACK/lapack/blob/master/SRC/Makefile#L75

FWIW, the same symbol is also exported by the reference BLAS implementation bundled in Octave for Windows:

$ objdump.exe -p /mingw64/bin/librefblas.dll | grep lsame
        [  76] lsame_

This might be a bug in the flame implementation, or it might be an issue with (the build rules of) the reference implementation. Or both.

Could you please check the context of the first match of "lsame" in that objdump? Maybe with something like this:

objdump.exe -p /mingw64/bin/liblapack.dll | grep lsame -B50

From which library does it try to import that symbol? I'd guess it might be `AOCL-LibBlis-Win-dll.dll`.

Anyway, this is probably only an issue on Windows (where the linker resolves which symbols are imported from which library). Afaict, the symbol resolution is done on runtime on Linux.
Setting the Operating System tag accordingly.

Markus Mützel <mmuetzel>
Project Member
Sun 09 Oct 2022 05:06:12 PM UTC, comment #7: 

C:\Program Files\GNU Octave\Octave-7.2.0\mingw64\bin>objdump.exe -p liblapack.dll | findstr "lsame"
        e76f5e      0  lsame
        [7234] LAPACKE_lsame
        [13415] fla_lsame
        [13790] lsame_lf
        [13791] lsamen
        [13792] lsamen_

C:\Program Files\GNU Octave\Octave-7.2.0\mingw64\bin>

Jinchuan Tang <jinchuantang>
Sun 09 Oct 2022 04:10:51 PM UTC, comment #6: 

THis might also be a Fortran name mangling issue. IIRC, different Fortran compilers mangle names differently (lower vs. upper case letters, different number of underscores...).

Octave for Windows is compiled with gfortran. If those libraries have been compiled with a different compiler or a different name mangling scheme, that could cause similar issues.

It might also be that their library doesn't export that symbol at all.

Could you please open the "Bash Shell" that is installed with Octave for Windows, e.g., using the shortcut from the Start menu, and run the following command?

objdump.exe -p /mingw64/bin/liblapack.dll | grep lsame

What does it return while you have that file replaced with the libflame library?

Markus Mützel <mmuetzel>
Project Member
Sat 08 Oct 2022 08:27:35 PM UTC, comment #5: 

I also see some additional test failures (from
_run_test_suites_) with both blis (mostly NAN handling) and
flame (those seems to be more serious).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Oct 2022 07:55:28 PM UTC, comment #4: 

Nevermind -- that was an old thread. I have downloaded
aocl-linux-gcc-3.2.0-1.x86_64 and it seems to be working with
octave (using LD_PRELOAD mechanism). I do not see any improvements
over openblas though.
I do see improvements with libblis over openblas though
(this is with amd-3950x).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Oct 2022 07:35:05 PM UTC, comment #3: 

I think the issue is that AMD does not provide fortran interface
for libflame (lapack2flame ?).

See:

https://community.amd.com/t5/newcomers-start-here/fortran-compatibility-of-libflame-and-blis/td-p/249141

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Oct 2022 04:16:53 PM UTC, comment #2: 

Dear Markus,
Thank you very much for your explanations!
Currently, I am interested in the incompatibility issue with amd-libflame in Windows 11. The extra information I could provide is that I had the latest libFLAME 3.1 installed. I tried to replace the liblapack.DLL in the octave bin directory with libFLAME 3.1’s multi-thread version along with a copy of aocl-blis lib with original name. Nevertheless, I could not get into the GUI due to two errors as shown in the former attachment.

I could not tell if this is the problem on the AMD side or Octave side. It seems that AMD ‘s lapack lib is forked from the open source project libflame.

Best wishes,
Jinchuan

Jinchuan Tang <jinchuantang>
Sat 08 Oct 2022 02:34:40 PM UTC, comment #1: 

I'm not sure if I understand correctly.

Are you proposing to bundle those libraries with Octave's sources somehow? We're not doing that for other implementations of the BLAS or LAPACK libraries either.

You set the Operation System to "Any". But maybe you are referring to the installer that we provide for Windows? (That bundles binaries of a lot of different tools and libraries in conjunction with the actual Octave.)
In that case: I'm not sure how our stance is on vendor specific libraries. We aren't bundling Intel libraries either...

Users are free to use different libraries if they'd like to. (But they'd probably need to expect a bit less expertise on the side of the community if they do.)

A third option to read your report: Are you reporting an incompatibility with amd-libflame? In case you do, could you please elaborate on that a bit more?

Markus Mützel <mmuetzel>
Project Member
Sat 08 Oct 2022 01:13:21 PM UTC, original submission:  

Dear team,
Today I tried to use the AMD opensource version of blas by renaming and copying the dll AOCL-LibBlis-Win-dll.dll (C:\Program Files\AMD\AOCL-Windows\amd-blis\lib\LP64) to libblas.dll ( C:\Program Files\GNU Octave\Octave-7.2.0\mingw64\bin) .
The libs can be downloaded from https://developer.amd.com/amd-optimizing-cpu-libraries_eula/

I noticed a speedup from  1.51017 seconds (openblas) to 1.28942 seconds (AOCL) on my AMD 5950x machine for the following code:

a2 = ones(2000,'single');
tic
for i = 1:100
a2*a2;
end
toc

In the meantime, as seen in the attached fig, I have a problem with lapack while renaming and copying the dll AOCL-LibFlame-Win-MT-dll.dll (C:\Program Files\AMD\AOCL-Windows\amd-libflame\lib\LP64)to liblapack.dll ( C:\Program Files\GNU Octave\Octave-7.2.0\mingw64\bin) .

One reason I am doing this was that now matlab 2022 starts to support those libs: https://uk.mathworks.com/matlabcentral/answers/1672304-how-can-i-use-the-blas-and-lapack-implementations-included-in-amd-optimizing-cpu-libraries-aocl-wi
I guess if AOCL is open source, we can give the community more options to choose the libs and speedup their programs.

libiomp5: https://www.dll-files.com/download/3a7902626cddec83a3da541a96118b46/libiomp5md.dll.html?c=dFZMSXhUYkJWbGEyMEN3bXN0b

Best wishes,
Jinchuan Tang

Jinchuan Tang <jinchuantang>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53822:  lsame.txt added by None (12KiB - text/plain - Dear Markus, please find the cmd results as attachment. I used control +C to stop display all content. Best wishes, Jinchuan)
file #53816:  lapack.png added by jinchuantang (19KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jinchuantang (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-10 None Attached File- Added lsame.txt, #53822
    2022-10-10 mmuetzel Release7.2.0 dev
        Operating SystemAny Microsoft Windows
        SummaryAMD ZEN AOCL library support for blas, lapack and fftw [MXE Octave] AMD ZEN AOCL library support for blas, lapack and fftw
    2022-10-08 mmuetzel StatusNone Need Info
    2022-10-08 jinchuantang Attached File- Added lapack.png, #53816

    Back to the top


    Powered by Savane 3.9