RE: -g and -fomit_frame_pointer

["Howell, David P" <david.p.howell@xxxxxxxxx>]

Back aways prior to my move to Intel, in the Pentium Pro days we measured this to be 4% on x86

code tests. The workload was a database engine running on a SVR4 Unix. We did the measurements

as part of our optimization plan for the engine, to make the case to the vendor to use our omit frame

pointer option. This was not gcc, may be different depending on how well gcc reuses %ebp and

optimizes mem refs.

 

This was a significant increase in our optimization plan for the database and did help performance. As

I recall the number also held up (3%-4%) on other benchmarks we ran.

 

Dave Howell 

-----Original Message-----
From: Dave Anderson [mailto:anderson@xxxxxxxxxxx]
Sent: Thursday, July 19, 2001 8:57 AM
To: lkcd@xxxxxxxxxxx
Subject: -g and -fomit_frame_pointer

No, you're not missing the point.  People just don't like to see
large kernels.  Trust me, I'd like to see -gstabs as a default
for all systems, but Linus gagged on the idea about two years
ago when I asked.  Maybe things are different now ... Heh. :)

Has Hell frozen over yet?

I've so far been working only with a live kernel and I've never
applied the lkcd kernel patch so that I did not create Kerntypes.
No wonder I could not find Kerntypes! I instead rebuilt my kernel
with -g. Yeah, the file size became over 4MB which is no good for
an embedded system, but I am still in the development stage.

Does your embedded system use the vmlinux file?
I realize some non-x86 processors boot the vmlinux
file instead of a bzImage file -- is that true
with yours?

You omit the frame pointer because it takes an extra register
on x86 systems, which can slow the machine down tremendously
(it has to do more with fewer registers)

BTW, what do you consider "tremendously"?  Has anybody
every published any hard numbers on this?  In any rough
testing we've done, the loss in performance is neglible,
i.e., in the low single-digit percentiles, if that.

Just wondering,
  Dave Anderson