From: Charles Yeomans <[EMAIL PROTECTED]>
Date: Wed, 2 Aug 2006 23:53:26 -0400


On Aug 2, 2006, at 7:05 AM, Theodore H. Smith wrote:

From: Joe Huber <[EMAIL PROTECTED]>
Date: Tue, 1 Aug 2006 10:48:21 -0700

a little effort with a profiler almost always turns up surprises in
real applications.  This is so common, in fact, that I'm greatly
surprised on those rare occasions when the profiler has no surprises
for me!

I agree and think part of the reason is that it's not always clear
which parts of a framework or external API calls are expensive and
which are not.

The thing I don't understand that no one mentioned, not even the
article, is that fast code is usually maintainable code and code
that's quicker to write.

That's because less code = faster code. less code = quicker to
write and maintain.

Usually, anyhow.

Not really.  Loop unrolling is a standard example of a speed
optimization that increases code size and reduces maintainability and
reliability in exchange for execution speed (sometimes).  Quicksort
trades a more complex algorithm, vastly harder maintainability, and
more code for significantly improved execution.

Yeah, this is true. Which is why I said "usually". I'm sure even a quicksort can be sped up by eliminating repeated code.

As for loop unrolling, thats a perfect candidate for more code being faster. That sort of thing is why I didn't say "always".

The thing about loop unrolling, is that it is the kind of optimisation that can be applied in so many cases, only 1% of which will really benefit. It's only good for low level stuff, where the loop overhead outweighs the size of the code in the loop. In RB I doubt it'll help much. In C, I know for sure that most of my loops don't need it, only a few need it.

Unfortunately, there is no way to tell my compiler which loops to unroll.

--
http://elfdata.com/plugin/



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Reply via email to