CB>You can tune a program nice and tight for your particular system, but
CB>then when it's run on a different system, discover that the performance
CB>sucks big time.  That you are only getting, maybe half or less, of the
CB>performance you could have otherwise gotten by not making processor
CB>specific optimizations and then running the program on a different
CB>processor.
Do you think that an executable would be compiled once and once only to be 
suited for all machines? If i were to make a game of such, i would include 
many executables, each compiled for different machines.
CB>Because whether something like that is optimal depends HEAVILY on the
CB>particular platform you are running on.  On one platform, doing *256 may
CB>be faster but on another, doing <<8 may be faster.  A multiply by 256
CB>may take 2-3 cycles, but a shift by 8 might take 8 or more (1 cycle for
CB>each shift.)  It depends on the particular processor.
CB>Things like that are very very platform dependant.
How absurd!
I don't think anyone would release a product to be multi-platformed with only 
one executable to suit all.
CB>And many compilers _do_ make that optimization.  WHEN and ONLY when it
CB>is appropriate for the CPU they are compiling for.  You obviously don't
CB>have much experience with optimizors, or you wouldn't have used that as
CB>an example.  Things like that are called Strength Reduction and have
CB>been around since the early days of compilers and optimizations.
CB>Throughout C's life, certainly.  It's very rare for even a 15 year old
CB>compiler for any language to not do simple optimizatons like that.
I realise most compilers make that optimization, (i based that example on a 
tc compiler), but OBVIOUSLY i'd try to get the maximum performance out of a 
program. Like i said before, as soon as i license my rather large game that i 
have been writing for the last 2 years an executable suitable for the machine 
would be installed. It's absurd to think that one shouldn't increase 
performance by 70% on a 386 because it would run 5% slower (based in ration) 
on a 686 machine.
CB>But only to an extent.  What you don't seem to realize that is that a
CB>program that is 'optimal' on a 386 class computer could be running at
CB>only 1/4th speed it might otherwise run on a cached 386, or 486 or
CB>Pentium, etc.  Now, true that will benefit those people running a 386,
CB>but there aren't many of them left.  It's usually better to just aim
CB>towards the middle, which these days is a 486.  (Also, since most 486
CB>are higher peformance 486s, Pentium type optimizations can usually
CB>help.)
See prev. message.
... Error 941 -  CPU not found...
--- Ezycom V1.48g0 01fd016b
---------------