<story><title>BLIS: A BLAS-like framework for basic linear algebra routines</title><url>https://github.com/flame/blis</url></story><parent_chain><item><author>quanto</author><text>The real money shot is here:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;flame&amp;#x2F;blis&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;docs&amp;#x2F;Performance.md&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;flame&amp;#x2F;blis&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;docs&amp;#x2F;Performance.m...&lt;/a&gt;&lt;p&gt;It seems that the selling point is that BLIS does multi-core quite well.  I am especially impressed that it does as well as the highly optimized Intel MKL on Intel CPUs.&lt;p&gt;I do not see the selling point of BLIS-specific APIs, though.  The whole point of having an open BLAS API standard is that numerical libraries should be drop-in replaceable, so when a new library (such as BLIS here) comes along, one could just re-link the library and reap the performance gain immediately.&lt;p&gt;What is interesting is that numerical algebra work, by nature, is mostly embarrassingly parallel, so it should not be too difficult to write multi-core implementations.  And yet, BLIS here performs so much better than some other industry-leading implementations on multi-core configurations.  So the question is not why BLIS does so well; the question is why some other implementations do so poorly.</text></item></parent_chain><comment><author>vatican_banker</author><text>&amp;gt; numerical algebra work [...] is mostly embarrassingly parallel&lt;p&gt;It&amp;#x27;s the exact opposite, most numerical linear algebra is _not_ embarrassingly parallel and requires quite an effort to code properly.&lt;p&gt;That is why BLAS&amp;#x2F;LAPACK is popular and there are few competing implementations.</text></comment>
<story><title>BLIS: A BLAS-like framework for basic linear algebra routines</title><url>https://github.com/flame/blis</url></story><parent_chain><item><author>quanto</author><text>The real money shot is here:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;flame&amp;#x2F;blis&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;docs&amp;#x2F;Performance.md&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;flame&amp;#x2F;blis&amp;#x2F;blob&amp;#x2F;master&amp;#x2F;docs&amp;#x2F;Performance.m...&lt;/a&gt;&lt;p&gt;It seems that the selling point is that BLIS does multi-core quite well.  I am especially impressed that it does as well as the highly optimized Intel MKL on Intel CPUs.&lt;p&gt;I do not see the selling point of BLIS-specific APIs, though.  The whole point of having an open BLAS API standard is that numerical libraries should be drop-in replaceable, so when a new library (such as BLIS here) comes along, one could just re-link the library and reap the performance gain immediately.&lt;p&gt;What is interesting is that numerical algebra work, by nature, is mostly embarrassingly parallel, so it should not be too difficult to write multi-core implementations.  And yet, BLIS here performs so much better than some other industry-leading implementations on multi-core configurations.  So the question is not why BLIS does so well; the question is why some other implementations do so poorly.</text></item></parent_chain><comment><author>bee_rider</author><text>BLIS mixed precision interfaces seem quite interesting and might be a good reason to expand on the BLAS api.&lt;p&gt;If I recall correctly, MKL also has interfaces that allow different array orders (row order or column order).</text></comment>