# ATLAS 3.5.7 SYRK Timings

So, we've known for a while now that ATLAS's SYRK/HERK perform sub-optimally.
It should run roughly at GEMM speed, but it has been instead one of our
slowest BLAS. This is bad news, because SYRK is the asymptotic limit to
Cholesky performance, just as GEMM is for LU. So, even though Cholesky
should run **at least** as fast as LU, ATLAS's Cholesky has always
significantly underperformed.
The solution is to write SYRK in terms of the GEMM kernel, rather than
the full GEMM. This has been done for real precision only in 3.5.7,
and here are the results.

The first graph compares all DSYRK versions vs DGEMM on a 600Mhz Athlon
classic.

## DGEMM & DSYRK: ATLAS 3.5.7 vs. 3.5.6 on a 600 Mhz Athlon

The good news is that SYRK and GEMM speed are now essentially the same, and
we see that 3.5.7's SYRK is clearly superior to 3.5.6's. However, the best
performing case is 'Upper','NoTrans', which is not used by Cholesky. Since
all the cases are relatively close, this is not that big a deal.

Now that our Cholesky performance kernel, DSYRK, is rolling along, what
about Cholesky itself:
## Factorization results: ATLAS 3.5.7 vs. 3.5.6 on a 600 Mhz Athlon

Again, things are more like what we hoped. Cholesky is still slightly slower
than LU for small problems (I believe our LU low-order terms have been better
optimized), but catches up around `N=600`. After this size, Cholesky
runs around the same speed as LU, and possibly a little faster.
I include SYRK 'Upper' 'Trans' on this chart, because this is essentially the
upper limit on Cholesky performance. Just as with LU, we see that the low-order
terms are keeping us from reaching our Cholesky peak.

OK, our final graph is a little busy, but it compares ATLAS 3.5.7 and 3.5.6's
differing SYRK, and resulting Cholesky performance on a 1.6 Ghz Opteron.
## ATLAS 3.5.7 vs. 3.5.6 on 1 Processor of 1.6Ghz Opteron

There are several interesting things about this chart. We see that
for the small to medium-sized problems, 3.5.7's gemm-kernel-based SYRK
kicks butt, but that the recursive gemm-based SYRK used in 3.5.6
catches up asymptotically. 3.5.7's SYRK does not run as fast as GEMM,
though actually some cases are closer than this. The case I timed was
the one used in Lower Cholesky. If you take the 'Lower' 'Transpose'
setting instead, performance will roughly halve the difference between SYRK
and GEMM.

3.5.6's Cholesky factorizations never catch up with 3.5.7's, however.
It is almost impossible to see on this busy chart, but 3.5.7's Cholesky
roughly catches up with LU around N=1000, and they then stay within
clock resolution of each other.

Back to ATLAS timing page