grunwald@uiucdcsm.cs.uiuc.edu (03/09/88)
re: address hashing to randomize bank conflicts. I would think that this would be too slow in software. However, if I recall correctly, randomized hashing was done in hardware on the RP-3 (it had some sort of variable hashing so you could fiddle with the parameters).
brooks@lll-crg.llnl.gov (Eugene D. Brooks III) (03/10/88)
In article <3300021@uiucdcsm> grunwald@uiucdcsm.cs.uiuc.edu writes: > >re: address hashing to randomize bank conflicts. > >I would think that this would be too slow in software. However, if I recall >correctly, randomized hashing was done in hardware on the RP-3 (it had some >sort of variable hashing so you could fiddle with the parameters). Those who have been using supercomputers for the past decade have dealt with this sort of problem by carefully avoiding the undesired addressing modes. Hashing takes care of the few pathological cases by slowing down the majority of cases which would normally stream at one word per clock. To slow down the machine to "random gather" speed for all of the normally high performance situtations is not desired. This applies to shared memory multiprocessors as well as it does to single cpu supercomputers.
lawrie@uicsrd.csrd.uiuc.edu (03/10/88)
I think I recall early versions of CHOPPS randomized addresses, and Klapholtz wrote >=one paper about this. Was also proposed for Cedar at Illinois but was not implemented at least in the first versions for reasons of economy.