On (11 May 97) Herman Schonfeld wrote to Jerry Coffin...
 HS> Jerry, I'm afraid that your missing the point here.
At least you wish I was.  In fact, you're the one missing the point.
 HS> What I previously claimed was that 'Optimizers don't always produce
 HS> the fastest code'. I hardly see where a[b] or *(a+b) have anything to
 HS> do with hand-optmizations.
One of your hand "optimizations" (which produced worse code) was based
on the idea that a compiler would be written ignoring that fundamental
fact.
 HS> test machine = 486 dx2 66, tseng 4000
 HS> version             Blits per Second
 HS> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 HS> floating point         31
 HS> fixed point            369.5  (nb, optimizers do not implement fixed
 HS> point)
 HS> fixed point + asm      348.9  (watcom writes better asm than me)
 HS> fixed point + cp asm   612.3  (using code patching)
 HS> Now, if I were to write the code normally without many optimizations I
 HS> would get a rather slow 31 fps. If I used fixed point math (please
 HS> name a compiler which does this for you, I'd really be interested in
 HS> it) I would get a whoppingly fast 370 fps. You might consider this
 HS> fast enough and just leave it and do something else, right? Well, by
 HS> spending a few minutes by adding code patching you could double the
 HS> fps. Now, that's 20 times faster than the original version. I don't
 HS> think it hurts to hand-optmize code, do you?
Okay, you asked about fixed point math.  All PL/I compilers support
fixed point math, because fixed point is a part of PL/I.  In case you're
intersted, IBM has a rather nice PL/I compiler for OS/2 and another for
Win32.
However, while you've stated that _your_ original code as slow, and
shown things _you_ did to speed it up, you've yet to show that those
were the only or the best ways to speed it up.  You're taking for
granted that somebody else couldn't have come up with other ways of
optimizing the code that would improve the speed sufficiently without
making it less readable.
Your statements ignore reality: you talk about 31 Frames per second as
slow, and 300+ frames per second as being more desirable.  In reality,
you can get completely smooth animation at around 30 frames per second.
For instance, the next time you go to a movie theater, consider that
it's using exactly 32 frames per second. The next time you turn on your
TV, consider that it's about the same.  (Offhand, I don't recall whether
Australia uses PAL or SECAM television, so I can't give an exact number,
but it's _well_ under 100 frames per second at any rate.
Even if we ignore the limitations of human vision, being able to produce
600 frames per second instead of 300 is _still_ useless and stupid.  The
fastest monitors around can't display anywhere close to that many frames
per second.  The fastest possible useful speed is the scan rate of the
monitor, which is typically around 70 frames per second.  If you attempt
to display more than that, you'll simply cause extra image shear, which
is NOT a good thing at all.
Finally, I have to admit that I find your results highly questionable at
best in any case.  If you want to back them up, post some code.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------