22 Jun
2004
22 Jun
'04
9:31 a.m.
(1) Reliability is always more important. But
memory/CPU cycles
cannot be ignored when your customers are running benchmarks, and when
you're trying to beat the competition using less expensive hardware
than they are.
That's what the company I work for need to do if we
expect to stay in business.
(2) Yes indeed -- but being skilled at
assembly
language programming imposes a useful discipline that carries over
into other languages.
In our case it is more like being skilled in understanding exactly
how the whole system hangs together. Most of the code (99.99%) needs
to be correct rather than fast (noone cares too much how fast
the web GUI is). The remaining (pretty small) percentage
gets pored over by multiple people, looking for a hint of a
performance gain.
Even that code is almost all in a HLL. In our case that may be
because the trick is to do as little as possible in s/w and
get the vlsi to do it instead.
(3) Not true. A compiler will
beat a poor
assembly programmer all the time, and an average one much of the
time.
I'm not sure that's true. A poor assembly programmer can probably
pick a lousy algorithm in an HLL too :-) If they are restricted
to implementing a specific algorithm, then I agree, these days
a compiler for a modern RISC processor should be able to whip
the pants off a poor or even average programmer all the time, and
even a good programmer much of the time.
But a programmer can know more about the problem
than the
compiler can ever know (because the higher level language can't
express everything there is to say about the problem) so an excellent
programmer can always tie the compiler, and in selected spots can beat
the compiler by a very large margin. It's important to know when to
spend the effort, and that is also part of what marks an excellent
programmer.
The trouble is that all programmers (good AND bad) think they
can predict where it is worth directing their effort. For real
world programs, all the evidence I've seen suggests that they
are both about equal in their predictive abilities: i.e. almost
always wrong!
True, but about a year ago I spent a week or so on a
routine that
takes about 30% of the CPU, and (with the help of a CPU expert) made
it 50% faster. It started out faster already than what the compiler
could do; the end result is way beyond any compiler designer's fondest
imagination.
The presence of numbers suggests you cheated by doing the unthinkable
and actually measuring the performance both before fiddling (to see
where you should play) and afterwards (to see what you'd done). Do
you realise how much trouble you could get into with such an
unconventional approach :-)
Antonio
--
---------------
Antonio Carlini arcarlini(a)iee.org