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

From: Firingme (firingme_at_[hidden])
Date: 2003-08-26 20:47:21

"Hurd, Matthew" <hurdm_at_[hidden]>
??????:DDE1D547D9B5B741A47D7354A5FFF4B70E561E_at_msgbal509.ds.susq.com...
>
> > -----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.
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>

Where is uBlas-dev list ???
I can't find it