The change triggers a different implementation of the weave code. I measured a 1% improvement on Solaris amd64 (64-bit) in rsaperf 1024-bit private keys ops by making this change.
Created attachment 236345 [details] [diff] [review] simple Makefile change. Use a different word-at-a-time implementation of the weave code
Comment on attachment 236345 [details] [diff] [review] simple Makefile change. Use a different word-at-a-time implementation of the weave code You can use this on Solaris x86, too.
Comment on attachment 236345 [details] [diff] [review] simple Makefile change. Use a different word-at-a-time implementation of the weave code r=nelson for trunk
Wan-Teh, I tried it on Solaris x86 and I saw a decrease in performance of 9.3%.
Checked in on the trunk : Checking in Makefile; /cvsroot/mozilla/security/nss/lib/freebl/Makefile,v <-- Makefile new revision: 1.87; previous revision: 1.86 done
Julien, thanks for the Solaris x86 info. I wonder if we should turn it off for Linux x86, too.
I would expect the results to be similar between Solaris and Linux, given that it's the same code. Note that I benchmarked on a dual Opteron machine with rsaperf -d . -n none -p 30 -t 2 On the Opteron machine, I got the 1% increase in 64-bit mode, and a 9.3% decrease in 32-bit mode, when adding the defines added by attachment 236345 [details] [diff] [review] in the Solaris x86 block . I think it is a property of AMD CPUs that 8-bit accesses are slow in the 64-bit instruction set, but not in the 32-bit instruction set. The same may not be necessarily be true on Intel chips. You would have to experiment. I don't have access to any 64-bit Intel CPUs to do this comparison. I tested the 32-bit code on a 32-bit dual Xeon CPU with hyperthreading. I tested with 4 threads in rsaperf. On that chip, there was a 1% increase by using MP_CHAR_STORE_SLOW - with the same bits that gave a 9.3% decrease on the AMD. That just goes to show that the chips are really very different. You have to balance which chip you want to optimize for. If you want to optimize for both, you should create multiple freebl libraries. But at that point, you would probably want to look into using SSE2 for that additional freebl lib, which will perform even better on the Intel - and not as much of an improvement on the AMD, though still better than the standard multiply instruction.