Boost logo

Boost :

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-06-27 19:36:35

On Thursday 27 June 2002 11:47, Martin Weiser wrote:
> Dear all,
> without giving a full review report (I haven't yet used uBLAS sufficiently
> to post a meaningful statement), I'd like to draw the attention to two
> points I haven't read so far in the discussion.
> [ If you're familiar with cache blocking techniques for linear algebra,
> you may wish to skip right to the end of the posting. ]
> Although the abstraction penalty is mostly insignificant compared to
> equivalent handwritten code, there remains a huge performance gap to
> optimized numerical kernels. I've done a preliminary comparison of dgemm
> performance with different matrix sizes N (see
>, measuring the flops/s
> multiplying two square matrices of size N (N=1,...,1000). The competitors
> are a vendor optimized BLAS implementation (Sun Performance Library) and
> a straightforward naive "C" implementation. The environtment is GCC 3.1
> (options -O3 -funroll-loops) on UltraSparc 10/300.

This type of graphs would be useful as uBLAS doc !

I also noticed this performance drop and it was to be expected unless uBLAS
would contain blocking strategies. To obtain maximal performance, about 8
months ago, also involving andrew lumsdaine, 2 different approaches have been
discussed which that can serve to obtain this performance :

1) Bindings to BLAS
Most high-performance computer vendors put a lot of effort into optimising
BLAS on their machines, writing the kernels directly in assembler. I don't
think any compiler is ever able to match this performance (first of all, a
compiler does not know about the different cache sizes that can be exploited).
This is at least a short-time solution.
I've also discussed this with Joerg and, as you suggest if I understand you
correctly, it is very hard to detect in an expression the sub-expression for
which a blas call can be maid. So the user should state explicitly if he
wants a blas-gemm or a ublas-prod.
I've started providing such bindings yesterday and in attachment you can find
my preliminary bindings.

2) optimising the uBLAS implementation
The review is mostly about the interface. Optimising the C++ implementation
for the different compilers should be looked at in a following stage IMHO.
This is very tricky and very subtle (just look at Jeremy's thesis, stating
the differences using a '==' or '<' condition in for loops) and needs to be
updated every time a new compiler is released.
This is a long-term solution.
I do think it can really coexist with the blas-calls because for small
matrices it's easier and, if the ublas implementation is heavily optimised,
long expressions could be quicker (due to the loop-fusion) than several calls
to blas (and creating temporaries). For instance, when multiplying 3
matrices, you need 2 gemm-cals and a temporary to store the result of the
first gemm. Here an optimised ublas should be able to outpace blas (correct
me if I'm wrong please).


Boost list run by bdawes at, gregod at, cpdaniel at, john at