Hi Thorsten, Ideally, we would like to have - the most efficient algorithm in compiled code - the possibility to have a CINT interface - the possibility to do I/O I frankly do not see any reason why C++ should be slower than Fortran for matrix operations. It should even be the contrary ! I know that thousands of man years have been spent in optimizing matrix libraries in Fortran. I refuse to believe your factor 10. You are may be confusing the effect of inline code (that you may get with cleverly designed classes) and the effect of virtual functions. Inline code was not possible with Fortran. C++ could help here. I am not preaching in favour of matrix classes (a la CLHEP). I again repeat that it would be in the general interest if people motivated by the mathematical classes could contribute to some selection of already existing code. I do not think that we should reinvent the wheel. The added value in the context of Root will come from an interactive interface as explained by Jacek and from the I/O interface. >From the many comments I have received, the last point about I/O is crucial. Without I/O, users may have to revert to less efficient implementations. It would be nice if some benchmark indications could be posted comparing different systems and their behaviour in Fortran and C++. This probably exists in the litterature. If there is a consensus, we can provide help for the CINT interface and the I/O interfaces. Rene Brun On Sat, 19 May 2001, Thorsten Glebe wrote: > Hi, > > "Jacek M. Holeczek" wrote: > > > 2. > - BUT, I see many people requesting: > > > -- interactive access via CINT (debugging purpose mainly). (Rene ?) > > ... we can't seem, however, to agree on the need of INTERACTIVE access > > to matrices, vectors, ..., from CINT. I fully support Rene's point, and > > more. I DO WANT interactive access to these data. > > My idea is the following - the time consuming algorithms are compiled, > > linked to the ROOT dynamically via a shared library. The organization > > of what happens (and when) is done by an INTERPRETED script (I mean, > > from the command line, for example). That is, for example, I create the > > matrix from the root prompt, then I call a compiled function to fill > > it, ..., and finally I look at results. Then I INTERACTIVELY multiply > > the matrix by some kind of a vector, or a number, and repeat the > > process. Maybe I decide to make the matrix diagonal, ... ? > > Maybe I create two matrices and decide to add them ? > > All these actions MUST be available from the interpreter. > > > > I hope it is clear to you what this means: for active libraries like Blitz++ > you have to precompile > operations like > > A + B > A + B + C > A + B + C + D > A * B > A * B + C > ... (and so on, of course for each dimension used individually!) > > The reason is that the expressions itself are templates. > > The consequence is that one can hardly provide a library which satisfies the > needs of the majority of the users. The user has to > make such a library by his own, precompiling the operations he wants to use > in CINT. > But this is not convenient any more as precompiling expression templates for > CINT is really ugly. This is something > the average user will for sure not do. Also alternative possiblities (like > wrapper functions) are not feasible if you think > about it for a minute. > > All these problems do not exist of course with trivial Vector/Matrix > implementations like those of the CLHEP library. Those > you can easily incorporate in CINT, but as I mentioned, the performance is > (even in compiled code) low. > > So the problem to me is the following: A ROOT user will certainly prefer > those Vector/Matrix classes which are supported by > ROOT. If you provide Vector/Matrix classes which can easily incorporated into > CINT, you leave the user with low performant > numerical code even if he fully compiles it!!! > If you want to provide a Vector/Matrix library which has an attractive > performance compared to hand written FORTRAN/C > routines you will have certainly big problems to make a reasonable > integration into CINT. > > I am pretty sure that a ROOT user wants both: CINT integration plus high > performance. Therefore the only solution might be to support both: a high > performance Vector/Matrix class with I/O capabilities but with very limited > access in CINT and > a slow but fully CINT functional Vector/Matrix class for convenient > programming. > > > 5. > ... the HERA-B experiment which uses a high performance C++ > > > Vector/Matrix algebra library ... (Thorsten) > > Can you predict whether your library can be made "visible" in CINT ? > > Yes, I can predict: No! > > Goodbye, > Thorsten >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:46 MET