On Wed, 20 Mar 2002, Allan Whiteford wrote:
> Is their not a difference between optimising a piece of code (in a
> textbook computer science type way) and choosing the correct algorithm
> (by actually engaging your brain)?
(IMHO) sort of ...
> I'd say they were different things but I wouldn't like to have to draw a
> line anywhere between them.
Yes, I agree. In practise there is a difference, but conceptually there
isn't.
The way I think of this is if you're looking at the overall picture, then
you are choosing which algorithm is best for a particular "job". There
might be many ways of "doing" the job you need to do. If it numerical
optimisation (more my experience) then you might use Simulated Annealing,
Hunter-Seeker, Secant method, Pavel's method, Genetic Algorithms, ... each
has advantages and disadvantages, depending on what you're after. There's
no way a compiler can rewrite a GA as a Pavel's algorithm for you, you'd
have to know to do it yourself.
At the opposite scale, you might write
ptr = &something;
There might be a couple of ways of doing that in assembler, but you trust
the compiler to choose the best one (that supports all the expected C
functionality)
If you're in the intermediate scale, this is where the -O2 stuff comes in.
You might write:
ptr = &something;
(*ptr)++;
and then never use "ptr" again. If the compiler has no optimisation, then
it will faithfully reproduce this functionality, even though its stupid. If
you turn on optimisation, it will notice these things and alter the
assembler accordingly.
Obviously this is a silly example, but in practise -O2 optimisation arises
from 1. writing code in a easy to understand way (using small functions,
tight loops). 2. the compiler knowing more (than you ever want to know)
about the target platform (see Intel's "free" Linux compiler that uses
3DNow! to speed up arbitrary floating-point operations).
> I also think that, for the former, gcc -O2 will do a far better job than
> most people[1].
Yep, the right tool for the right job. As long as you sort out the higher
level stuff (which algorithm to use), let the compiler sort of some of the
nitty gritty detail.
> [1] Most people does not include the guy who wrote quake.
Most people aren't that desperate to squeeze as much performance out of a
machine :^)
[oops, that turned into a bit of a rant, sorry;^]
Paul.
> Paul Millar wrote:
> >
> > On Wed, 20 Mar 2002, Graeme Mathieson wrote:
> > > On Wed, Mar 20, 2002 at 01:19:37PM +0000, Paul Millar wrote:
> > > > (e.g. use your brain to optimise code, not
> > > > the -O2 switch in gcc).
> > >
> > > Bah. The -O2 switch in GCC will do a lot better than most people trying
> > > to hand optimise code. The important thing to do is write the code in
> > > the first place. Once that's done, you can use a profiler to determine
> > > which areas it's actually worth spending time on optimising.
> >
> > Kind of. Say your algo has some tight loop called a few hundred times.
> > You profile to discover this tight loop (if you didn't notice it before)
> > and rewrite the thing in assembler: tight as possible. You get maybe 10x
> > speed improvement if you're lucky.
> >
> > But, there might be some completely different algo. for getting the same
> > result. It doesn't have any tight-loops, it just explicitly calculates the
> > right answer (if this was a numerical-code example). By using this algo,
> > you get maybe 100x speed improvement, probably much more. All without
> > writing any assembler.
> >
> > Profiling will produce the optimal implementation of an algo. Choosing the
> > correct algo. (should) happens at a higher level / earlier on. Get this
> > wrong and it bites.
> >
> > > I worked with somebody who preferred to 'optimise' his own code. He
> > > produced unreadable piles of crap and spent ages 'optimising' code that
> > > was never in the critical path. I seriously doubt what he was producing
> > > was any faster than a decent compiler would anyway...
> >
> > That just sounds like crap programming to me ;^)
> >
> > Cheers,
> >
> > Paul.
> >
> > ------------------------------------------------------------------------------
> > Paul Millar yo-yo, n. :
> > Particle Physics Theory Group Something that is occasionally
> > Department of Physics and Astronomy up but normally down.
> > University of Glasgow, (see also Computer)
> > Glasgow G12 8QQ, [EMAIL PROTECTED]
> > Scotland +44 (0)141 330 4717
> > ------------------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > http://www.lug.org.uk http://www.linuxportal.co.uk
> > http://www.linuxjob.co.uk http://www.linuxshop.co.uk
> > --------------------------------------------------------------------
>
> --
> This sentence have three erors.
> --------------------------------------------------------------------
> http://www.lug.org.uk http://www.linuxportal.co.uk
> http://www.linuxjob.co.uk http://www.linuxshop.co.uk
> --------------------------------------------------------------------
>
------------------------------------------------------------------------------
Paul Millar yo-yo, n. :
Particle Physics Theory Group Something that is occasionally
Department of Physics and Astronomy up but normally down.
University of Glasgow, (see also Computer)
Glasgow G12 8QQ, [EMAIL PROTECTED]
Scotland +44 (0)141 330 4717
------------------------------------------------------------------------------
--------------------------------------------------------------------
http://www.lug.org.uk http://www.linuxportal.co.uk
http://www.linuxjob.co.uk http://www.linuxshop.co.uk
--------------------------------------------------------------------
