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] | |
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] |