Re: are static operations optimized?
Re: are static operations optimized?
- Subject: Re: are static operations optimized?
- From: Chris Williams <email@hidden>
- Date: Tue, 27 Jan 2009 09:22:46 -0800
- Thread-topic: are static operations optimized?
Title: Re: are static operations optimized?
Virtually all applications I’ve seen that are “slow” are slow not because of CPU time, but because of other operations (such as disk and network accesses) that are orders of magnitude more expensive. Or because they needlessly do operations many times where once would do.
Certainly you know more about the specifics of your application and its larger objectives than a compiler can know. And therefore you CAN write code that is faster in the individual case than a compiler. That is quite true.
But I have said this before, in 25+ years in the software business I’ve seen precisely one case where someone made huge performance gains in an application by hand-coding or tricking the compiler, and that was almost 20 years ago when the person wrote code that just fit in the 80286 pre-fetch cache.
In every other case, the return on time investment for this kind of stuff is tiny (or negative) and serves merely to amuse the inner-geek in the coder and not the larger case of making the application faster.
</soapbox> :)
From: Stephen Northcott <email@hidden>
Date: Wed, 28 Jan 2009 00:12:25 +0700
To: Chris Williams <email@hidden>
Cc: <email@hidden>
Subject: Re: are static operations optimized?
Hi Chris,
On the broader front, many of the discussions I see on this list (and the Cocoa list) about various coding tricks to achieve performance are simply wasted effort. Virtually all good compilers perform optimizations far beyond your imagination, and many of these “tricks” are already handled or even worse they so badly confuse the optimizer as to make performance decline.
Interesting, but how do you ratify that with dedicated hand coded SSE functions?
I now write three versions of each maths routine I code.
1. asm.
2. C++
3. Intrinsics.
Although I am still finding my way around intrinsics there are definitely times when they simply do not cover some of the short cuts you can find by hand coding for specific cases in SSE. I am specifically referring to ways of using and re-using register contents from various positions across a 128bit register, and spotting patterns in complex equations where non-intuitive instruction / data ordering cut real corners in the logic.
Admittedly some of these 'tricks' are melon twisters.
However, generally when I benchmark the three it's speed is in the order asm, then intrinsics/C, then C.
Often the asm is an order of magnitude faster when tested inline.
Yes, there are pitfalls, and you have to manage where your data is yourself, rather than letting the compiler do it.
But if I cannot get the same speed letting the compiler worry about it why would I opt for that?
I totally agree that good code architecture is key, but isolated, special purpose in-lined functions are simply faster when coded in asm.
With the caveat that you must know what you are doing... But dismissing it out of hand and discouraging people from that pursuit is counter productive I think. Compilers are wonderful wonderful things, and thanks for your efforts on them for sure. But they are not the holy grail. Sorry.
Kind regards,
Stephen.
_______________________________________________
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