HS>CB>1) although on your computer and compiler, pointers are faster than
HS>CB>direct indexing, they may not be on other peoples computers and
HS>CB>compilers.  This will depend on compiler optimizations available, the
HS>CB>register assigning the compiler makes, and the individual CPU itself.
HS>So you are happy to let an optimizer do all the 'hard-stuff' for you? I 
r
No.  But I know where to spend my time.  On things that give a heck of a
lot better improvement than low level optimizations would, and things
that are far more portable and consistent.  This is especially true
considering how very very different the multiple sources would have to
be for them to 'optimal' for the wide variety of processors.
HS>one, am not, and compile my programs for specific machines. 
ulti-processor
HS>programs should be compiled specifically for the machine intended, to gain 
t
Multi-processor programs generally _have_ to be, because the
multi-processing varies so much from one system to another.
HS>doesn't work, get a better machine' attitude I keep seeing all over
HS>the place when it's quite obvious that performance performed by games
HS>such as quake could be atleast 20% faster on a 486 using the
HS>appropriate An optimization
Well... That's a rather curious 'observation'.  The people who write
those games are generally professionals who do that for a living and
have done it for 10 or more years.  They feed their families by the
quality of code they write.  They are intimately familiar with the
processors, compilers, and hundreds of different algorithms. If those
methods you liked really _were_ so good, and so portable, and so
effective across such a wide range of systems, etc., then don't you
think they'd do them?  Odds are, there were very good reasons for what
they did.
They don't supply 3 or 4 different versions tweaked for various systems
(such as 386, old 486, new 486, 586+) because they don't want to
recompile it with a better optimizing compiler, but because 1) there is
more work in maintaining different versions than there is writing the
program, 2) the optimizations and low level tweaking would be so time
consuming it would double the time it took to write it, 3) there is
still no guarantee that their carefully tuned 586 code would be better
on a Pentium, an AMD '586', a Cyrix 586, etc.
And finally, many of those types of games have been tuned to a
particular type of system... Namely one with a fast video card.  In most
cases, most peoples computers will outrun their video cards ability.
(ie: a 386 outruns ISA, 486/66 outrus most VLB, 486/100 outruns VLB,
pentium 150 outruns PCI, etc.)  The video cards just can't keep up the
CPU trying to put the data on the screen.  More expensive computers
generally have faster video cards, and thus are capable of displaying
the fancier, faster graphics that the processor can deliver. In other
words, they've done the types of optimizations you've been promoting, at
the expense of everybody else who doesn't have the fastest processor and
video card.  They've tuned the games to the higher performance video
card, and the types of processors that usually go along with it.  It's
like one of the 'rules of optimizations' I gave you before, you can tune
it for a particular type of system and require everybody else to have
the same.
HS>absolute fastest performance. I wouldn't mind 20 or so different versions 
of
HS>the executable on a compact disc taking into consideration that the 
programm
I wouldn't mind being on the _receiving_ end, but considering the type
of low level optimizations you are talking about, that would end up
being at _least_ a half dozen or so significantly different programs to
maintain. Maintaining multiple sources, and keeping them synchronized,
is not easy.  You end up spending more time keeping them 'together' than
you do improving them.
--- QScan/PCB v1.19b / 01-0162
---------------