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