"Hurd, Matthew" <[EMAIL PROTECTED]> ??????:[EMAIL PROTECTED] > > > -----Original Message----- > > From: Firingme [mailto:[EMAIL PROTECTED] > > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost