Skip to content

Commit 11ce79a

Browse files
authored
Merge pull request #5329 from foxtran/fix/docs
Update FAQ
2 parents d24195e + 46b0dfe commit 11ce79a

File tree

2 files changed

+4
-4
lines changed

2 files changed

+4
-4
lines changed

docs/dgemm_snb_1thread.png

156 KB
Loading

docs/faq.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -91,7 +91,7 @@ like Intel Haswell. There once was an effort to build an OpenCL implementation t
9191

9292
We obtained a performance comparable with Intel MKL that actually outperformed Intel MKL in some cases.
9393
Here is the result of the DGEMM subroutine's performance on Intel Core i5-2500K Windows 7 SP1 64-bit:
94-
![Single Thread DGEMM Performance on Intel Desktop Sandy Bridge](http://xianyi.github.com/OpenBLAS/dgemm_snb_1thread.png)
94+
![Single Thread DGEMM Performance on Intel Desktop Sandy Bridge](dgemm_snb_1thread.png)
9595

9696
<hr noshade="noshade">
9797

@@ -220,8 +220,8 @@ lead to compiler error messages about an "ABI change" when compiling AVX512 code
220220
### <a name="ppcxl"></a>Building OpenBLAS on POWER fails with IBM XL
221221

222222
Trying to compile OpenBLAS with IBM XL ends with error messages about unknown register names
223-
like "vs32". Working around these by using known alternate names for the vector registers only leads to another assembler error about unsupported constraints. This is a known deficiency in the IBM compiler at least up to and including 16.1.0 (and in the POWER version of clang, from which it is derived) - use gcc instead. (See issues #1078
224-
and #1699 for related discussions)
223+
like "vs32". Working around these by using known alternate names for the vector registers only leads to another assembler error about unsupported constraints. This is a known deficiency in the IBM compiler at least up to and including 16.1.0 (and in the POWER version of clang, from which it is derived) - use gcc instead. (See issues [#1078](https://github.com/OpenMathLib/OpenBLAS/issues/1078)
224+
and [#1699](https://github.com/OpenMathLib/OpenBLAS/issues/1699) for related discussions)
225225

226226
### <a name="debianlts"></a>Replacing system BLAS/updating APT OpenBLAS in Mint/Ubuntu/Debian
227227

@@ -268,7 +268,7 @@ path (usually either /usr/local/include, /opt/OpenBLAS/include or whatever you s
268268

269269
This is due to different interpretations of the (informal) standard for passing characters as arguments between C and FORTRAN functions. As the method for storing text differs in the two languages, when C calls Fortran the text length is passed as an "invisible" additional parameter.
270270
Historically, this has not been required when the text is just a single character, so older code like the Reference-LAPACK bundled with OpenBLAS
271-
does not do it. Recently gcc's checking has changed to require it, but there is no consensus yet if and how the existing LAPACK (and many other codebases) should adapt. (And for actual compilation, gcc has mostly backtracked and provided compatibility options - hence the default build settings in the OpenBLAS Makefiles add -fno-optimize-sibling-calls to the gfortran options to prevent miscompilation with "affected" versions. See ticket 2154 in the issue tracker for more details and links)
271+
does not do it. Recently gcc's checking has changed to require it, but there is no consensus yet if and how the existing LAPACK (and many other codebases) should adapt. (And for actual compilation, gcc has mostly backtracked and provided compatibility options - hence the default build settings in the OpenBLAS Makefiles add -fno-optimize-sibling-calls to the gfortran options to prevent miscompilation with "affected" versions. See ticket [#2154](https://github.com/OpenMathLib/OpenBLAS/issues/2154) in the issue tracker for more details and links)
272272
<hr noshade="noshade">
273273

274274
### <a name="newcpu"></a>Build fails with lots of errors about undefined ?GEMM_UNROLL_M

0 commit comments

Comments
 (0)