Re: Wasted CPU Cycles
On 2011-03-03 16:17, Joe Hesse wrote:
> I occasionally find myself writing C/C++ functions where something is
> only done once but the test occurs multiple times. Below are two
> examples. Does anyone have suggestions to make the code better?
What you shouldn't worry about are wasted CPU cycles. That kind of
branch is predictable and correctly predicted branches are free (take 0
time) or close to free on most current CPUs.
Modern CPUs generally have pretty sophisticated branch prediction, so if
you had a low iteration count in your second case, the branch prediction
will likely predict all branches correctly when your function is called
after the first time.
A workaround that results in larger code is likely going to be a larger
waste of CPU cycles (larger code = more cache misses which are expensive).
Re: Wasted CPU Cycles
On Mar 3, 11:35*am, tni <t...@example.invalid> wrote:
> On 2011-03-03 16:17, Joe Hesse wrote:
> > I occasionally find myself writing C/C++ functions where something is
> > only done once but the test occurs multiple times. *Below are two
> > examples. *Does anyone have suggestions to make the code better?
> What you shouldn't worry about are wasted CPU cycles. That kind of
> branch is predictable and correctly predicted branches are free (take 0
> time) or close to free on most current CPUs.
Or rather, if you must worry about it, you should
be doing it with accurate information. For example,
get the original code and a stop watch. Then get
some candidate alternatives. Run each possible
version and measure how long it takes. Make sure
you use sensible candiate data as inputs, not just
the shortest possible run.
Better yet, get some good profiling tools and see
how long it really spends doing each version.
If different versions take the same time, don't
worry about it. Do what makes the code more
clear, easier to document, easier to understand,
easier to test, and such like "motherhood" things.
Then back up a step or two and see if you have a
specification on how fast it must run. If there
is no spec on execution time, or if there is and
you are easily meeting it, then don't sweat a few
extra cycles here and there even if they are being
wasted. Get the code right first. Keep all those
motherhood things in mind while doing it. And
only after all of that think about optimizing.
If you optimize first you will often get bad code.
Clear, easy to understand, easy to test, easy to
document code is a value. It's also easier to try
out optimizing alternatives on such code.
Similar comments apply to things like trying to
make the code smaller, use less memory, less lines
of code, etc. If *every* other measure of code
quality were identical then a smaller code is
likely better. But shorter isn't the only concern.
And in many cases it isn't the first concern. Or
even in the top few.
|All times are GMT. The time now is 09:56 PM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.