RE: MTL and C++ compilers - some thoughts

Hi,

Many thanks for posting your know-how about KCC vs GCC...

Within the development of our own FEM software FELyX (http://felyx.sourceforge.net) we are fighting pretty much the same problems you do. I can describe what's our best try at the moment:

*** Compiler
Since we do not have KCC and we do want to offer a software that runs on several platforms we use GCC 2.95.3  or GCC 3.2. Up to now, gcc 2.95.3 seems to be some 30-40% faster for our code than gcc 3.2.  Why?

*** Matrix Multiplications:
We are using the template specializations that were posted from Gunter  Winkler on this list ( http://www.osl.iu.edu/MailArchives/mtl-devel/msg00402.php ) for matrix multiplications in our element stiffness formulation and assembly processes. He modified the specializations from Trevor Blackwell to use ATLAS/BLAIS routines. This boosts matrix multiplications quite a bit.

**** Solution of the linear equation system:
After some bugfixes in MTL, we could use the envelope storage format to handle the sparse global stiffness matrices. Then, we reimplemented a direct Skyline solver from the OFELI package in MTL. This worked quite o.k., but not really fast...
To make the solver faster, we are now using a dot-product routine from ATLAS/BLAIS in the most inner loop of the solver. This speeded up the solution process by another 30%... This actual code seems to be competitive to the direct solvers implemented in the commercial program ANSYS as long as the problems are relatively small (< 40000 DOF's). 


--> So finally one can say, that we circumnavigated the MTL-GCC weaknesses at critical points by using ATLAS/BLAIS routines.... Makes the code faster but not easier to handle....

It would be interesting to know what the actual state of MTL 3 is, and how all the compiler problems are considered there ?

Greetings
ok


----------------------------------------------------
Oliver Koenig
Center of Structure Technologies
Institute of Mechanical Systems
LEO C12
ETH Zurich
CH-8092 Zurich
Phone : +41 1 632 23 28
Fax :   +41 1 632 17 02
Mail :  [email protected]
WWW :  http://www.imes.ethz.ch/st/
----------------------------------------------------


-----Original Message-----
From: Christoph Monzel [mailto:[email protected]] 
Sent: Montag, 2. September 2002 14:28
To: [email protected]
Subject: MTL: MTL and C++ compilers - some thoughts

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/
_______________________________________________
This list is archived at http://www.osl.iu.edu/MailArchives/mtl-devel/