MTL and C++ compilers - some thoughts
Christoph Monzel <[email protected]>
| Newsgroups | gmane.comp.lib.mtl.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi everbody, First of all i want to thank the authors of the MTL (and ITL) for making it available to the public. Current situation regarding compilers It is well known that the MTL/ITL needs a good optimizing compiler to archive high speed at execution time. KAI's KCC was the best (and only ?) choice for that. Unfortunately KAI was bought by Intel and so KCC is longer sold. Intel C++ compiler is not really an alternative, since it only supports IA32 and IA64 architectures and currently, in my opinion, is just some kind of beta software. Gcc 3.1 is unable to perform the "Lightweight Objects" optimization and therefore produces code which is more than two times slower then KCC code. I could not see that gcc will provide that kind of optimization some day (correct me if i am wrong). Possible solution Because of its multiple architecture support and free availability of gcc seems to be the most interesting compiler. So it is worth considering to "help" gcc a little bit with minor modifications of the MTL. In our FEM solver project iMOOSE ( http://sourceforge.net/projects/imoose/ ) we apply the MTL compressed2D sparse matrices types to solve the linear sparse equation system resulting from the FEM discretization. Some examinations with profiling, debugger and assembler listing have shown that gcc does not cope well with iterator classes and the resulting temporaries (eg. begin()/end()). It will getting even worser if you use the reverse_iterator, which introduces a temporary iterator object for the dereference operator*() (take a look at /usr/include/c++/3.1/bits/stl_iterator.h). For the same reason reverse_iterator<>::operator++(int) is "evil". So you use better T_i++ than ++T_i (if T_i is a STL reverse_iterator). Best solution seems to be to rewrite the code avoiding reverse_iterators completely [1]. This gave us a performances boost about 50% in 'tri_solve__(const TriMatrix& T, VecX& x, row_tag)' (mtl.h) if T is an "upper" matrix. Together with an specialized version (after reading [2]) of 'mult_symm__(const Matrix& A, const VecX& x, VecZ& z, row_tag)' the speed up was by a factor of 1.7. So we need "only" 30% more speed to match with KCC (time for solving the equation system: KCC 55s <-> gcc-3.1: 77s [3]). Well, in my opinion writing specialized version of the critical functions is not a nice solution. So i suggest to think about re-design of the iterator classes for sparse matrices (in compressed2d.h compressed_iter.h). What do the list members thing ?! Best regards -- Christoph Monzel [1] if interested i can post a patch. [2] http://www.osl.iu.edu/MailArchives/mtl-devel/msg00383.php [3] funny thing: for the whole test problem (reading FE meshes, building the system and jacobi matrix and so on, gcc-3.1 outperforms KCC: gcc-3.1: 925s KCC: 1205s ! ------------------------------------------------- Institut fuer Elektrische Maschinen, RWTH-Aachen Tel : +49-241-8093962 Fax: +49-241-8092270 Schinkelstr. 4, D-52062 Aachen mailto: monzel@_NOSPAM_iem.rwth-aachen.de -------------------------------------------------- Accelerate Windows: 9.81 m/sec^2 would be adequate _______________________________________________ This list is archived at http://www.osl.iu.edu/MailArchives/mtl-devel/