--- Comment #31 from steven at gcc dot gnu dot org 2006-09-03 11:05 ---
real times for hashes100.c (x86_64-linux, Intel Xeon 3.2 GHz, 1GB RAM):
3.4.6 4.0.4 4.1.2 4.2-svn20060724
-O0 0m1.618s 0m1.762s 0m1.661s 0m1.645s
-O1 0m2.743s 0m4.646s
--- Comment #32 from steven at gcc dot gnu dot org 2006-09-03 11:37 ---
Just to be sure that between 7/24 and today we didn't speed up significantly:
real times for hashes100.c (x86_64-linux, Intel Xeon 3.2 GHz, 1GB RAM):
3.4.6 4.2-svn20060903delta
-O0 0m1.618s
--- Comment #33 from steven at gcc dot gnu dot org 2006-09-03 11:41 ---
FWIW, the oprofile for both test cases is basically flat, nothing stands out.
We just do _so_ much more work (many more passes without removing anything) and
that hurts apparently (not surprising of course).
--
--- Comment #34 from rguenth at gcc dot gnu dot org 2006-09-03 13:22
---
FYI, the profile (-O2) looks like
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
2.04 0.62
--- Comment #35 from steven at gcc dot gnu dot org 2006-09-03 17:28 ---
Even if we did not hash SCEV data a lot, it would not buy you 50%.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-07-05 09:14
---
Can you do timings on these again on the mainline since it looks like Richard
G.'s memory patches also improved compile time for C at least on the CSiBE
benchmark.
--
--- Comment #29 from mmitchel at gcc dot gnu dot org 2006-05-25 02:32
---
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from mmitchel at gcc dot gnu dot org 2006-02-24 00:25
---
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
