# [rc5] Why are Alpha's so much slower then wintel boxe

Eric Gindrup gindrup at okway.okstate.edu
Fri Oct 31 18:25:51 EST 1997

```     Oops.  Drop the last term from that long sum and add that the most
significant byte is now useless.

Also, I got a bit fuzzy about x.  It would have been better to say:
"Let abcdefgh be some 8-bit... and let x = [abcdefgh, 8-3-1]"  I was
thinking I had said this in the rest of the message.  (*sigh*)
-- Eric Gindrup ! gindrup at Okway.okstate.edu

Subject: Re[2]: [rc5] Why are Alpha's so much slower then wintel boxe
Author:  <rc5 at llamas.net > at SMTP
Date:    1997/10/31 17:59

This is not entirely correct.  As I alluded in a recent post, the
following can be done at the FPU:
Let x=abcdefgh be some 8-bit value you want rotated by 3 bits.  Assume
80-bit (IEEE double) floating point.
Multiply x by [(2^3 + 2^(8+3)),0] (the [mantissa, un-biased exponent]
pair)
Then the next-to-last byte of the mantissa is defghabc = x<<3.

If one multiplies by [2^3 + 2^11 + 2^19 + 2^27 + ... + 2^75, 0] then
all 9 bytes that are not the least significant contain x<<3

No imprecision is introduced because you aren't "challenging the
precision".  You are multiplying two entirely representable values
with exact representations and performing an operation that does not
have any chance of underflow or overflow.  It would be an exceptional
processor in my experience that didn't reliably give at least ONE
correct value in some byte for any amount of rotation of any x.

Multi-issue processors could probably check keys in the FPU as well as
in the normal pipelines.  Hand-tuning would probably be required to
prevent waiting pipes.
-- Eric Gindrup ! gindrup at Okway.okstate.edu

Subject: Re: [rc5] Why are Alpha's so much slower then wintel boxes?
Author:  <rc5 at llamas.net > at SMTP
Date:    1997/10/31 13:36

At 03:13 PM 10/31/1997 -0600, Brian Greul (Exch) wrote:
>Does anyone have any ideas on why Alphas might be so much slower than
>wintel boxes at crunching this code?
>I would expect them to perform on par.

That, alas, turns out not to be the case. The Alpha processor doesn't have
a rotate instruction, so it's gotta be faked by the code. This, needless to
say, slows things down, so you end up with less than stellar numbers.

>Is there a way to utilize the FPU to crunch numbers?
>after all, an integer is just an even floating point number....

Um, no, they aren't. And even if they were, no FPU that I know of will
rotate the bits in a floating point number. There's no purpose in it.

>It would seem that it might be worthwhile to convert the integers to
>floating point numbers, or to just read them in on the alpha client....
>Any thoughts on this issue?
>Reasons why it won't work?

Several. The biggest is that floating point operations are, by their very
nature, imprecise. That's the last thing you want when dealing with
cryptography.

Dan

----------------------------------------"it's like this"-------------------
Dan Sugalski                            even samurai
sugalskd at osshe.edu                      have teddy bears
and even the teddy bears
get drunk
----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the
body.

----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the
body.

----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

```