Make benchmarks out of our opensource SHA256 implementation

RESOLVED FIXED in Q4 11 - Anza

Status

Tamarin
Virtual Machine
P3
normal
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Lars T Hansen, Assigned: Lars T Hansen)

Tracking

unspecified
Q4 11 - Anza
Bug Flags:
flashplayer-injection -
flashplayer-qrb +
flashplayer-bug -

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

7 years ago
We're hosting a SHA256 program on opensource.adobe.com.  This program is a strongly-typed component that uses Array and probably an example of trying-to-be-fast AS3 not written by us; it's also a kernel that is easily run as a benchmark.  It's easy to transform the Array version into one that uses Vector.  Both versions should be added to test/performance in some suitable directory.
(Assignee)

Comment 1

7 years ago
Created attachment 556560 [details]
WIP: Array version
(Assignee)

Comment 2

7 years ago
Created attachment 556561 [details]
WIP: Vector version
(Assignee)

Comment 3

7 years ago
The spectrum of running times is potentially interesting here.  On 32-bit using Array it's quite slow, presumably because of all the boxing as values go into Arrays - the Vector case is much faster.  But why is the 64-bit Vector case so much faster than the 32-bit Vector case?  On other benchmarks, 64-bit yields no particular advantages.

Iterations/sec (roughly):

            Array    Vector

32-bit        608      1345
64-bit       1260      1642

Comment 4

7 years ago
Is there any issue with the fact that the Vectors are typed as uint but it appears that most of the time the value is pulled out and cast to int()?
(Assignee)

Comment 5

7 years ago
(In reply to Brent Baker from comment #4)
> Is there any issue with the fact that the Vectors are typed as uint but it
> appears that most of the time the value is pulled out and cast to int()?

IMO there shouldn't be (the int/uint distinction is about the interpretation of the bit pattern but the bit pattern should be the same), but part of the job of turning these into good benchmarks is measuring that by adding safeguards on expected results and also seeing whether Vector.<int> would be more appropriate.
(Assignee)

Comment 6

7 years ago
Created attachment 556821 [details] [diff] [review]
Benchmarks + driver

This upgrades the Vector benchmark to use Vector.<int>, which seemed to improve the performance a tiny bit.  I've copied the driver from the asmicro/ tests so the metric is iterations/second.

After some hesitation I am proposing that we place the benchmarks in canaries/; I would have chosen misc/ but that appears to be a dumping ground for manually-run benchmarks.  It's too big to be a microbenchmark (asmicro/).  It does not fit in jsbench/ or scimark/ or v8/ or sunspider/ since those are externally created.  We could create a new category if necessary.
Attachment #556560 - Attachment is obsolete: true
Attachment #556561 - Attachment is obsolete: true
Attachment #556821 - Flags: review?(brbaker)
(Assignee)

Updated

7 years ago
Target Milestone: --- → Q4 11 - Anza

Updated

7 years ago
Flags: flashplayer-qrb+
Flags: flashplayer-injection-
Flags: flashplayer-bug-

Updated

7 years ago
Priority: -- → P3

Comment 7

7 years ago
Comment on attachment 556821 [details] [diff] [review]
Benchmarks + driver

Review of attachment 556821 [details] [diff] [review]:
-----------------------------------------------------------------

- move the tests into test/performance/misc based on our conversation
- add the following to test/performance/testconfig.txt
   misc/driver, .* ,, skip, included by test files

NIT: remove tabs from files
Attachment #556821 - Flags: review?(brbaker) → review+
(Assignee)

Updated

7 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Comment 8

7 years ago
changeset: 6581:b02571ac42d8
user:      Lars T Hansen <lhansen@adobe.com>
summary:   Fix 682848 - Make benchmarks out of our opensource SHA256 implementation (r=brbaker)

http://hg.mozilla.org/tamarin-redux/rev/b02571ac42d8
You need to log in before you can comment on or make changes to this bug.