C compile time
Steven Bosscher
s.bosscher@student.tudelft.nl
Wed Jun 18 09:15:00 GMT 2003
Jan Hubicka wrote:
>>Dara Hazeghi wrote:
>>
>>
>>
>>>Okay, here's the updated table. Checking is disabled
>>>on all compilers.
>>>
>>>gcc version -O0 -O1 -O2 -O3
>>>2.7.2.3 128.04 131.02 163.51 176.01
>>>2.8.1 128.86 140.79 182.35 194.63
>>>2.90.29 130.60 140.57 186.29 199.32
>>>2.91.66 132.44 148.48 203.71 219.21
>>>2.95.3 143.38 180.97 250.94 276.85
>>>3.0.4 169.79 210.73 320.24 365.15
>>>3.2.3 193.48 269.43 424.74 519.85
>>>3.3 184.15 282.57 442.64 529.93
>>>3.3-branch 184.15 283.89 443.66 535.10
>>>3.4-mainline 195.34 302.02 483.84 704.59
>>>3.4-mainline* 175.84 269.78 426.77 627.13
>>>3.5-tree-ssa 223.33 327.91 503.58 702.11
>>>
>>>
>>>
>>So with Andrew P's patch, mainline C is faster than 3.3, hurray!
>>
>>The slowdown at -O3 is of course due to unit-at-a-time, which can be a
>>big memory sucker if there are lots of opportunities to inline static
>>
>>
>
>I was doing some estimates there, and for compiling SPEC sources the
>slowdown is proportinal to the code size growth caused by
>unit-at-a-time. So the problem does not seem to be increased memory
>overhead, just the fact that we find more inlining opurtunities and
>inline more. GCC is probably good testcase for this as many parts are
>ordered top-down instead of bottom-up or old inliner likes.
>
You can also use the test case for PR 10155 to see the RAM abuse (and PR
11121 while you're at it :-)
Gr.
Steven
More information about the Gcc
mailing list