Re: [Libmesh-devel] AW: Re: good news: 1e6 :-)

[Benjamin S. K. <be...@cf...>]

We have access to a part-time gcc developer here.  I asked him about  
this, and you will be happy (or unhappy...) to know this is a common 
"problem."

The basic issue is that gcc-2.9x is not standards compliant in 
string/stream handling.  gcc-3.x has fixed this, and currently the 
"fixed" version is a _lot_ slower.

The basic issue is internationalization.  The ASCII character set is 
efficient but limited:  only 256 symbols.  To support more "exotic" 
languages you need to use wide-characters and other complications. 
Fortunately, all these complications are hidden
behind the "locale" interface.  Unfortunately, the interface iis slow.  
So, g++ under the 3.x series is forced to use less efficient streams 
since they must interface with the user's locale.

Currently, there isn't anything we can do about this.  You can always 
have a copy of meshtool built with gcc-2.9x, and just use it to convert 
ASCII files to XDR.  Then read them with the fast XDR methods.  ;-)

Sorry.  I'll let you know if I find a work-around.

-Ben


Daniel Dreyer wrote:

>FYI:
>
>Perflog timings for reading UNV files from local harddrive,
>sizes of 31 and 83 MB, with different compilers (all opt mode,
>reading performed with meshtool, almost identical hardware):
>
>                   Mesh::read() [s], compiled using:
>file size [MB]        gcc 3.2.3      gcc 2.95.3
>  31                     20.            5.7
>  83                     56.           16.
>
>
>Quite interesting...
>
>  Daniel
>
>
>|
>| Daniel Dreyer, SM (MIT)
>| Mechanics and Ocean Engineering
>| TUHH, Germany
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Libmesh-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>  
>