Dear Rene, > I certainly agree with your point about performance and I have absoluty > no doubts about the fact that Blitz++ is a very efficient library. > I have never proposed to introduce wrappers. In my mail, I said; > - that there should be no obstacles in using the native C++ classes > from compiled code. I never disagreed with you on this point. You are perfectly right. > - BUT, I see many people requesting: > -- interactive access via CINT (debugging purpose mainly). With a library like Blitz++ I do not see a possibility to fully integrate it into CINT. Then CINT must be able to handle expression templates (which makes only sense if CINT deals with templates and not with template instantiations) and recursive templates. > I have seen so many nice libraries designed essentially at the time of > the vector computers, very well optimized for pure CPU type applications. > However, most of the time, these libraries have proven to be unpractical > in reality because the classes cannot be made persistent. > For me, the I/O is a cricial point (CINT being a different priority). I do not see why I/O should be a critical point. It is rather easy to write I/O routines for Vector or Matrix objects. It is far more difficult to write *fast* Matrix algebra classes! It is also possible to run rootcint to generate streamers. But one has to protect most of the code in the header file from being seen by rootcint. From my experience I can say (I am writing a ROOT based data analysis framework for the HERA-B experiment which uses a high performance C++ Vector/Matrix algebra library) that nobody is interested in C++ code which can easily be outperformed by hand-optimized FORTRAN or C code. And (sorry to say this) it is fact that numerical code based on classic C++ Vector/Matrix classes (like those in CLHEPLIB) are a factor 5-20 slower than equivalent numerical code written in FORTRAN/C. The reason for this is also known since a long time: its the C++ abstraction penalty. Although CINT is a nice product, I think is is a big mistake to consider only those numerical libraries which can be fully used in CINT. This will force people to use classes with low numerical performance and you will have a hard time to explain why people should change from fast FORTRAN code to slow C++ code supported by ROOT... > We are under very strong pressure to propose something for the mathematical > libraries. We left this question pending, hoping that other groups will > take care of this problem. Unfortunately not much is happening. In fact I am not sure whether blitz++ is a good choice, as it is not made for high energy physics purposes. Also well known libraries like LAPACK (or LAPACK based libraries) are not necessarily a good choice, as they reach their peak performance at Vector/Matrix dimensions of 40-100, but for small dimensions they are very inefficient. An important application for a Vector/Matrix package in HEP is the implementation of Kalman filter based Track and Vertex fits. The matrix dimensions here are typically of the order 3 - 5 (in the worst case 3N+3, N being the number of tracks in a vertex). > It would be nice if people with experience in the field, but also understanding > the I/O problem could cooperate to at least start a discussion. Hope my comments help as a starting point... Goodbye, Thorsten > > > > Dear Rene, > > > > > - It would be nice to have a CINT interface. > > > - Most important, an I/O interface. There is no point in having a matrix > > > class if you cannot do I/O. These mathematical objects can be embedded > > > inside other objects that have to be persistent. It implies that one must > > > be able to run rootcint on the header files. > > > > as you might know, Blitz++ is an active library which uses template > > metaprogramming to generate high performance code at compile time. In > > other > > words, the code gerated by this library depends on the expressions you > > write. > > In case you wrap Blitz++ classes in ROOT I/O capable classes, you invent > > again > > the C++ abstraction penalty which has been ovecome so successfully by > > Blitz++ and other packages. The result is a large performance > > degradation (factor 5-20, depending on Matrix dimensions and expression > > complexity). > > > > Therefore I cannot recommend to introduce ROOT wrappers for high > > performance libraries. One should use them in compiled code as they are > > and not in CINT. --------------------------------------------------------- Dr. Thorsten Glebe <T.Glebe@mpi-hd.mpg.de> Max-Planck-Institut für Kernphysik Saupfercheckweg 1 Tel: +49/(0)6221/516-631 D-69117 Heidelberg Fax: +49/(0)6221/516-603 ---------------------------------------------------------
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:45 MET