Investigate Array, TypedArray performance issues in noVNC tests

NEW
Unassigned

Status

()

defect
8 years ago
5 years ago

People

(Reporter: humph, Unassigned)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
Here's an interesting post, with tests, showing performance of using Arrays and TypedArrays in the noVNC project:

http://blog.n01se.net/?p=248

In it, the author finds that Firefox suffers from speed issues with random reads, perhaps a regression in the 4 time frame.

The tests are at https://github.com/kanaka/noVNC/blob/master/tests/arrays.html
So the test loop is this:
for (cnt = 0; cnt < conf.read_cnt; cnt++) {
    i = (arr[i] + cnt) % arraySize;
}
If i change the mod to and and the time drops from 828 (5000000 reads / 1000000 array size) to 247.
*an and (&)
This is a tracer issue; if I disable the tracer then the problem more or less goes away.
And so far I have not managed to reproduce this in the shell....
Attachment #527201 - Attachment mime type: application/x-javascript → text/plain
For what it's worth, I can't reproduce the "normal" array thing in browser either.

But for typed arrays I see us spending a ton of time under js::GetPropertyByName and js_NumberToStringWithBase.

Obvious guess is that we somehow end up with 'i' being a double; the question is _why_.  And why it only happens in browser....
I might have been using just -j for the other shell testcase...

This testcase shows the problem when run with -m -j (as well as -m -j -p -a), but NOT with just -j or just -m.  Furthermore, it stops showing the problem if the typed array sequential read test is removed.  It stops showing the problem if the "normal" array random read test is removed or moved to after the typed array random read test. 

I hope someone who understands things like the oracle better than I can make sense of this...
Attachment #527206 - Attachment mime type: application/x-javascript → text/plain
Interestingly, the type inference branch doesn't seem to have this problem, even if I just run |-m -j -p -a| or |-m -j| (i.e. without -n).  If I toss in -n, the behavior is identical to just -m except a bit faster (not nearly as fast as -j on either branch, though).

Brian, any idea what changes on the TI branch might be affects -m -j without -n?
JM typed array IC's are disabled on the TI branch (also without -n), see bug 643842.
Aha!  Let me go look at those; I bet they produce doubles for integer typed arrays or something.
Hmm.  Except LoadFromTypedArray seems to tell masm that these are integers...  And disabling typed array ICs locally in my TM tree does not make the problem go away.

Comment 14

7 years ago
There is a note at the end of the blog saying that when the generic function is replaced with one for each array type the performance improved significantly.

Thus, firefox is not instantiating a specialization of each function call. What should happen ideally is that if the type inference oracle (JM and/or Ion version) knows all the types of a function, it should create a specialization for that function using that information (remembering which specializations it has).
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.