[RC5] anyone had a look at the AltiVec stuff for PPC?

van der Stock, Andrew Andrew.vanderStock at nwhcn.org.au
Sun May 17 03:32:40 EDT 1998

pre-script: this is not an invitation to a my CPU is better than your CPU
flame war. It's about hopefully getting d.net to optimize for a specific
future CPU technology that some of our clients will use.

AltiVec (the PPC [vector, multi-media, DSP, SIMD, etc] extensions) can munge
in various sized words (8 bit through 128 bit), in various data types
(vector, int, fixed point, and floating point). As I currently understand
both the current RC5 algorithm and the new AltiVec stuff (and my grasp is
limited on both, I must admit), AltiVec will more than likely improve the
PPC's ability to munge the RC5 algorithm by at least four-five times at any
given clock speed. Since AltiVec CPUs will most likely come in parts at >
300 MHz, this means likely client speeds of over 4-6 million keys/s per CPU,
particularly on Rhapsody or other Unix OS's (AIX, if IBM can get past the
NIH stuff, or mkLinux if Apple still let mkLinux boot on the AltiVec Macs). 

FYI, the AltiVec execution unit's register file has 32x128 bit registers,
which are 8 way ported. So each cycle, it can move 1024 bits of data around,
or do an operation on all 32 registers simultaneously. There are 162 new

If the data size of what we're doing on RC5-64 is 64 bit, I think there will
be effectively 64 new 64 bit registers to work with that can have the same
operation done to them simultaneously. The FP and Integer units can also
process instructions at the same time, maybe getting ready to load the next
batch of registers up. 

I think it will be worth while to hand tune the PPC version of the core for
AltiVec when the CPU is released later this year. I'd love to see the
performance on that thing. 

To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list