303338 - New assembler multiply code needed for Sparc v8 ISA

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

Back in 2001, when I was working on NSS 3.1 performance, I found a 
c language code construct that the then-current compiler would turn into 
optimal multiplication code on Sparc v8 (32-bit only) CPUs.  So, I didn't 
use assembly code for the inner multiplication loops because it was 
unnecessary.   Some more recent compilers generate less efficient results 
from that same source code, so it is now necessary to use assembler code 
to achieve that same level of optimization.  I took the old NSS 3.2 v8
multiply code and disassembled it, creating a new .s file.  The results 
perform as well as the old NSS 3.2 did on v8 CPUs.  

Patch forthcoming.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The diffs may be seen here:  

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=NSS&branch=NSS_PERFORMANCE_HACKS_BRANCH&branchtype=match&dir=mozilla%2Fsecurity%2Fnss%2Flib%2Ffreebl&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-14+01%3A01&maxdate=2005-06-16+01%3A01&cvsroot=%2Fcvsroot

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Attachment: code from perf hacks branch

Here are the diffs as a patch. 
Note, changes two 2 files, one new file.

Comment 3

[Wan-Teh Chang]

Comment on attachment 191566 [details] [diff] [review]
code from perf hacks branch

r=wtc.	Your changes to mpi/mpv_sparcv8.s are license
header change and whitespace changes.  Perhaps you can
just make the license header change to reduce the diffs.

Commentary: In 2005+, does the performance of NSS 3.11+
on SPARC v8 matter?  I don't think it's worthwhile to
do all this work for old CPUs.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

This is not actually an enhancement.  It is a fix for a regression.

We still support v8 CPUs on S8 and S9, and must continue to do so for a few
years.  We don't want/need to enhance performance on those older CPUs, but
neither do we want to allow regressions.  We are trying to get users to come 
forward from older 3.3.x to newer 3.9.x or 3.10.x releases.  Unfortunately,
NSS has experienced a significant performance regression between 3.3.x
and 3.9.x (and later) on v8, due to switching to a newer compiler.  

This assembly file recovers that lost performance, by restoring the optimal 
code built by the previous compiler.  It's a substantial difference in 
performance for v8 users.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Checked in on trunk in lib/freebl:

Checking in Makefile;           new revision: 1.61; previous revision: 1.60
Checking in mpi/mpv_sparcv8.s;  new revision: 1.4; previous revision: 1.3
Checking in mpi/mpv_sparcv8x.s; new revision: 1.2; previous revision: 1.1

I think this bug is done.  But I'll leave it open for a bit.

Comment 6

[Julien Pierre]

This bug is done. Marking fixed.