This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 3.1 is still very slow, compared to 2.95.3


On Sun, May 19, 2002 at 06:11:35AM +0100, Julian Seward wrote:

>      Writes   D1-w miss  L2-w miss
>  79,686,641  11,105,948  181,718  ../sysdeps/i386/memset.c:memset
>   2,230,720     279,758  140,231  genrtl.c:gen_rtx_fmt_i0
>     430,998     121,051        0  gcc/recog.c:preprocess_constraints
>     388,072     101,271   20,187  gcc/sbitmap.c:sbitmap_vector_alloc
> 
> which doesn't really lead anywhere.  Either it's untrue, or someone is
> calling memset like crazy where they weren't in 2.95.3.

So it seems, the libc profile for gcc 3.1 counting memory references
looks like this :

0007455c 2626     3.44294     fputs_unlocked
0007f180 2870     3.76285     strlen
00080c64 4231     5.54725     memcpy
0007e1f8 7663     10.0469     strcmp
00079868 9222     12.0909     chunk_free
00078e60 11224    14.7158     chunk_alloc
00080858 33939    44.4973     memset

I haven't yet tried more detailed profiling with the cache counter types, 
but it's indicative that valgrind's simulation isn't totally off the
wall

This was on a Celeron Coppermine 800MHz with cache size      : 128 KB

regards
john

-- 
"It is very difficult to prophesy, especially when it pertains to the
 future."
 	- Patrick Kurzawe


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]