Re: -O3 vs. -Os
Re: -O3 vs. -Os
- Subject: Re: -O3 vs. -Os
- From: Eric Albert <email@hidden>
- Date: Tue, 17 Jan 2006 01:29:28 -0800
On Jan 17, 2006, at 1:06 AM, Steve Checkoway wrote:
On Jan 16, 2006, at 11:50 PM, Rustam Muginov wrote:
Regular applications do not have heavy computation mathematics and do
not have clearly visible "hot-spots", i.e. small parts of code where
application spend something like 50% or more total time.
I would recommend you to use Shark (part of the CHUD tools) to
investigate application run-time behaviour
How about a game? Still, I would say that this uses fairly
computationally intensive mathematics. Matrix multiplications left and
right for graphics work, resampling sounds for audio output, etc. I
have used Shark and there is no single hot spot clearly visible in the
game.
Still, I wonder on what you were basing your assertion that only
"manually-tuned high-performance libraries" benefit from -O3. I
wouldn't claim that this game is manually tuned at all. Plus, I would
think that such code would benefit the least from optimization if it
is carefully done by hand to begin with.
I think in this case it is pretty clear that more highly optimized
code that is actually smaller than the less optimized code is likely
to run faster. Based on framerates (turning vsync off, of course),
that is the case.
I'm curious if this is normal.
This is not normal, but it isn't inconceivable. Optimization is a very
tricky thing, and it can behave differently based on all kinds of
things. In the end, while we have recommendations (and we've done a
lot of testing to come up with -Os as the recommended default), if
performance is critical for you you're really better off doing your own
measurements. And if those measurements show that you can get faster
and smaller code with different compiler flags, well, go for it!
In general, though, most people will benefit a lot more from spending
some time with Shark than from changing compiler flags. Compiler flags
are useful if you need to eke another 2% out of something, but if you
have something "slow" that needs to be "fast", you're far more likely
to accomplish that via algorithmic changes than via the compiler.
-Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden