Optimization idea: put (y&1) in [] instead of if()

about:
> #ifdef FASTWAY
> p[0] = (p[397] ^ y >> 1) ^ xorer[y & 1];
> #else
> p[0] = y & 1
> ? (p[397] ^ y >> 1) ^ 0x9908b0df
> : (p[397] ^ y >> 1);
> #endif

In article <5180a9bc-db20-4efe-bbf2-> James Dow Allen <> writes:
....
> Thank you. Still, it seemed remarkable that *more than half* the
> time spent by the entire twister (much longer piece of code than
> the posted fragment) was wasted by this "unhoistable" branch,
> especially since the FASTWAY would have been slower, I think,
> on many Jurassic-era processors.

I do not think so. On many early CDC's the first version would be
faster, even if you compiled the code fragment naively to machine
code. The forward branches would kill performance (they would void
the instruction stack leaving a delay comparable to the time for
about 50 instructions, while a load was about 12 instructions worth).

Or do you not think a mainframe from the early 60's is Jurassic-era?

Naive thinking can lead to bad programming and also extrapolating from
past experience to new machines can lead to slow programs. Consider
the relative cost of floating-point multiplication vs floating-point
addition and subtraction. I have seen routines where algorithms using
many multiplications where converted to algorithms using far fewer
multiplications and many more additions, for a total increase in the
number of operations. While this was faster on the first CDC I did
use (addition was 3 cycles, multiplication 57), it failed on later
generations (addition still 3 cycles but multiplication now 4 cycles).
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

Dik T. Winter

On Nov 6, 10:31*pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
> about:
>
> > #ifdef * *FASTWAY
> > * * * * p[0] = (p[397] ^ y >> 1) ^ xorer[y & 1];
> > #else
> > * * * * p[0] = y & 1
> > * * * * * * * * ? (p[397] ^ y >> 1) ^ 0x9908b0df
> > * * * * * * * * : (p[397] ^ y >> 1);
> > #endif
>
> In article <5180a9bc-db20-4efe-bbf2-4b44afe6a...@a37g2000prf.googlegroups..com> James Dow Allen <jdallen2...@yahoo.com> writes:
> ...
> *> Thank you. *Still, it seemed remarkable that *more than half* the
> *> time spent by the entire twister (much longer piece of code than
> *> the posted fragment) was wasted by this "unhoistable" branch,
> *> especially since the FASTWAY would have been slower, I think,
> *> on many Jurassic-era processors.

I did write *many* Jurassic-era processors; I did not write *all*
Jurassic-era processors.

> I do not think so. *On many early CDC's the first version would be
> faster,..

By "many" I think you mean the 6600. They kept that in the Rad Lab
in my day, and we undergrads had to use the 6400 which had no
pipeline. Among IBM mainframes in the mid-1970's, only the
million-dollar-plus models had any real pipeline.

> Or do you not think a mainframe from the early 60's is Jurassic-era?

What I think is that I wrote *many* and you
misinterpreted that to mean *all*.

> Naive thinking can lead to bad programming and also extrapolating from
> past experience to new machines can lead to slow programs.

Everyone seems eager to impugn my optimization talents! For the
first class using the afore-mentioned CDC6400, the Professor gave me
an A+ as my programs outperformed his for speed. I *did* write
the World's Fastest JPEG Compressor. Etc.

I once sat at a desk next to a circuit designer who was, supposedly,
one of only two people in the world to be able to debug the 6600
register-reservation scoreboard (the other was Seymour Cray!)
I did *not* post my message because I wanted someone to explain
pipelining to me! I *did* post, altruistically, because I
thought that the huge performance advantage shown in the fragment
might be of interest to others who seek speed. Perhaps the
post should have been addressed only to "naive thinkers."

James Dow Allen

James Dow Allen