Re: multidimensional arrays
Re: multidimensional arrays
- Subject: Re: multidimensional arrays
- From: Pandaa <email@hidden>
- Date: Tue, 15 Mar 2005 23:09:32 +0100
2005-03-15 kl. 20.03 skrev Thomas Davie:
- you probably gain 0.001 seconds on one chip and loose the same on
a different chip...
So stop trying to find that one clock cycle difference it makes and
start trying to (a) write code that looks nice, and (b) write fast
algorithms.
I trust everyone to have a sound judgment on when and what to
optimize and when and what not to optimize. Bringing up the
"premature optimization" point everytime someone talks about
efficient coding is redundant at best. Everyone knows their own
situation and application best, so trying to lecture them on what is
appropriate for their situation is simply rude. People are
intelligent enough to understand if a comment were relevant for them
or not, don't treat them like they're not.
Also, if it is never considered OK to discuss what is efficient and
what is inefficient programing - how are we to develop the skills we
need when it *is* important to optimize?
I never said that it wasn't important to optimize or that it wasn't OK
to discuss optimizations.
Sorry, you didn't. It's just the general attitude at some lists and
forums that hit me.
But what you demonstrated is something that I would barely count as
being in the category of optimizations. Optimizations are things that
bring the complexity of your program down, not things that gain you a
clock cycle here and a clock cycle there.
After you've done everything you can to reduce your program complexity,
these kinds of optimization are what's left that you can do and may
give significant gains. It's not one thing or the other, one can do
both. Most of the time, there are better things to do but sometimes
it's worth the effort.
In the end, it's all about that clock cycle here and there. They add up.
But if you really wanted to bring this up, writing code that looks
nice has very little do to with wether you're writing efficient code
or not. The fastest known algorithm has probably already been
selected, or its design requires deep specialist knowledge of topics
very different from computer programming. Cache-tuning and other
optimizations can usually improve your speed by a rather large
integer factor - such as going from 20 seconds to less than one
second to process a large data set.
Absolutely, but eliminating one multiply to go from
array[x][y];
to
*(array + x * kYSize + y)
Make that array[x*ysize+y] , where ysize was a variable.
is a particularly ugly hack and it is debatable whether it even gains
you anything.
It's not debatable, it's a question for profiling. It's always been a
locally significant gain in my cases. The denser syntax will only be
worth the gain in tight loop nests that are frequently run.
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. email@hidden . . www.synapticpulse.net .
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden