Date: Mon, 05 Aug 2002 22:03:47 -0700 From: Darren Pilgrim <dmp@pantherdragon.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Jason Andresen <jandrese@mitre.org>, Dmitry Morozovsky <marck@rinet.ru>, hackers@freebsd.org Subject: Re: -fomit-frame-pointer for the world build Message-ID: <3D4F58B2.E58C2865@pantherdragon.org> References: <20020802212841.R58905-100000@woozle.rinet.ru> <3D4AC526.4CD399B3@mindspring.com> <3D4C8464.A2F4775A@pantherdragon.org> <3D4CC81F.94526C8A@mindspring.com> <3D4EA466.C1289F0F@mitre.org> <3D4EF091.EA1C91D3@pantherdragon.org> <3D4F0A5F.9B76573F@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > Darren Pilgrim wrote: > > > > The claimed savings are fictions. They are function call > > > > overhead savings assuming an average number of arguments and > > > > related pushed values, and they apply only to the call process > > > > itself. Most time in programs is spent in running, not calling > > > > functions, so if you expect an elimination of "18% overhead" > > > > to make you programs that much faster, you are dreaming. > > > > > > On the other hand, -fomit-frame-pointer is the only optimization > > > beyond -O in gcc that actually seems to offer any sort of speedup > > > for me. I've seen 10 to 20% reduction in runtime on some programs > > > with -fomit-frame-pointer. It's the only specific optimization I > > > bother with anymore. > > > > What, if anything, have you come across that won't compile/run properly > > when you use -fomit-frame-pointer? > > Not that this question has anything to do with the stuff you > are quoting before asking it... I had read what you said, but that's like saying, "If you drive way too fast for the road conditions, you'll wreck your car." That's fine and true, and I won't argue with it. However, it doesn't tell you how fast is "way too fast" coming westbound down I-84 around the bend at the viewpoint just outside of Corbett, OR, for example. I was hoping for more specific information. > If you attamept to mix code that does callee pop or tail call > optimization (e.g. in a library) with code that omits the > frame pointer, or vice versa, then either the caller is going > to push something that is never popped, or the callee is going > to pop something that is never pushed. For hand coded assembly > functions, it's not possible to make it obey the options which > control this (e.g when it is not the caller which does both > the pushing and popping of arguments). Are there any such known instances in the FreeBSD base code or any of the (more popular) ports? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D4F58B2.E58C2865>