RE: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas?

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2003-08-26 20:24:37

> -----Original Message-----
> From: Firingme [mailto:firingme_at_[hidden]] 
> Subject: [boost] Re: [uBlas] Any Performance Resulst Data with uBlas?
> 
> 
> Then Matthew, refer to your graph result data, the champion  
> and the runner-up all are C libs but not C++ 
> .................. Does it means if I want to get high 
> performance with Matrix operation, I "must" use C but not C++????

I don't know, I just did a graph.  I'm have no expertise here.

I have some personal thoughts about uBLAS and C++ numerics, but take it with
a grain of salt.

uBLAS performance
-----------------

It is pretty good.  Blocking was taken out the out of cache dead horse
problem.  But it is still significantly slower than vendor BLAS and ATLAS.
Tv-met and the like are faster for small matrices, like the 4x4 transform
you might use in CGI.  

Joerg has shown me some uBLAS results a while ago that were preliminary,
unconfirmed and very fast for the Intel platform.  Faster than ATLAS.  So
watch that space.

You need a smart compiler with the appropriate settings to get good
performance.  Vectorising with SSE2 makes an enormous difference, for
example, with Linux or Win32 on a P4.  There is an issue with making the
best performance available to everyone without the you-beaut compiler.
Building and releasing libs/dlls for platforms would be required, which is
not normal Boost practice.

uBLAS as an interface
---------------------

Works well.  Nice interface.  Can use ATLAS, vendor BLAS and other libs from
this base.
Would be good if there was an ATLAS-like automagically tuned interface for
uBLAS to choose at compile and/or run time the appropriate underlying
implementation for "prod" etal.  That way uBLAS would transparently be using
the best implementation, perhaps its own, at various points.

This would mean that you could use uBLAS without any uncertainty that your
performance will be superseded, encouraging numeric development beyond plain
BLAS.

The uBLAS guys have a LAPACK binding in progress as well.  LAPACK, as you
probably know, needs  BLAS.  Other bindings would be good to encourage uBLAS
as the lingua franca of numeric C++.

On the flip side, a lot of uBLAS work will be ignored unless it can be
incorporated into other works, like LAPACK.  I think this means that uBLAS
should provide a BLAS interface so that people are encourage to work within
the framework of uBLAS knowing that this is a widely useful thing.  Again
this could grow to include other interfaces, e.g. uLAPACK, to encourage and
draw resources.

Developing right now
--------------------

What would I do right now?  I would use uBLAS and delegate to ATLAS or a
vendor BLAS where that really mattered.  That's what I do.

I'd suggest you to talk to the ublas-dev list and get information from
horses' mouths.  They have been nice guys to chat to.

Regards,

HTH.