Closed
Bug 549509
Opened 14 years ago
Closed 14 years ago
JM: jsval representation profiling
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
People
(Reporter: dmandelin, Assigned: dmandelin)
References
Details
(Whiteboard: fixed-in-tracemonkey)
Attachments
(5 files)
Motivation: Consider JSOP_MUL. We know we should have some fast paths, but which inputs do we need to cover? int*int? double*double? Others? We need to know the frequency with which each tuple of input jsval tags occurs. Here's what we need: For each opcode, record the tuple of input tags that occur at runtime [ i_1, i_2, ..., i_n] for an opcode that uses n inputs. Print the results as a histogram of the input tag tuple for each opcode. This feature should be in the tree so that we can rerun it at any time. I'm calling this "representation profiling" rather than "type profiling" because this is about the representations used by the interpreter, not semantic type properties of the values. It's a subtle distinction but it may be clearer if this profiling is compared to the type profiling bug. It seems that the output tags might also be interesting, but I can't think of an immediate use for them.
Assignee | ||
Updated•14 years ago
|
Assignee: general → dmandelin
Assignee | ||
Comment 1•14 years ago
|
||
Each line is: op, opname, input_1, ..., input_n, count The file is sorted by op. So this block: 31,mod,double,int,3180 31,mod,int,int,223331 means that for |mod|, the inputs are (double, int) 3180 times and (int, int) 223331 times. This will change when we get the new jsval formats, because we'll have 32-bit ints instead of just 31 bits.
Assignee | ||
Comment 2•14 years ago
|
||
This is the instrumentation patch.
Attachment #430497 -
Flags: review?(lw)
Comment 3•14 years ago
|
||
Comment on attachment 430497 [details] [diff] [review] Patch Nicely done >diff --git a/js/src/jsapi.h b/js/src/jsapi.h >+#define JS_REPRMETER Just a reminder to remove this little guy hiding at the top of jsapi.h. >+ enum repr { Perhaps, if you don't feel strongly otherwise, the type name could be capitalized? >+ OpInputHistogram::AddPtr p = opinputs.lookupForAdd(opinput); >+ if (!p) >+ opinputs.add(p, opinput, 1); >+ else >+ opinputs.put(opinput, p->value + 1); >+ } Not that efficiency matters, but 'put' does a second lookup. I think what you want is: OpInputHistogram::AddPtr p = opinputs.lookupForAd(opinput); if (p) p->value++; else opinputs.add(p, opinput, 1);
Attachment #430497 -
Flags: review?(lw) → review+
Assignee | ||
Comment 4•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/a79ea749498a
Whiteboard: fixed-in-tracemonkey
Comment 5•14 years ago
|
||
Entries with count over 1mil: 86,getlocal,20810089 84,getarg,6108183 20,lt,int,int,5482894 55,getelem,array:dense,int,4995047 219,int8,4875481 87,setlocal,int,4685771 63,one,3674171 27,add,int,int,3560338 17,bitand,int,int,3437635 59,name,2435188 87,setlocal,double,2377583 25,rsh,int,int,1979685 56,setelem,array:dense,int,int,1831824 24,lsh,int,int,1699570 28,sub,int,int,1629786 88,uint16,1610496 29,mul,double,double,1483490 154,getgvar,1389074 27,add,double,double,1138757 62,zero,1136940 29,mul,int,int,1058658 228,trace,1027598 Total count ~105mil, so these entries represent ~75%.
Comment 6•14 years ago
|
||
Comment 7•14 years ago
|
||
(In reply to comment #6) > Created an attachment (id=431979) [details] > SunSpider results sorted within opcode data.split("\n").reduce(function(a, l) (l=l.split(","), l[0] = l[0] - 0, a[l[0]] ? a[l[0]].push(l) : a[l[0]] = [l], a), []).map(function(o) o.sort(function(a, b) a[a.length - 1] - b[b.length - 1]).join("\n")).join("\n\n").replace(/\n{2,}/g, "\n\n")
Comment 8•14 years ago
|
||
Comment on attachment 430497 [details] [diff] [review] Patch >+#ifdef JS_REPRMETER >+# define METER_REPR(fp) (reprmeter::MeterRepr(fp)) >+#else >+# define METER_REPR(fp) Avoid empty statement warnings (forget which compilers/options, but we do this elsewhere based on being nagged over nothing) by making the no-op macro's body ((void) 0). /be
Assignee | ||
Comment 9•14 years ago
|
||
(In reply to comment #8) > (From update of attachment 430497 [details] [diff] [review]) > >+#ifdef JS_REPRMETER > >+# define METER_REPR(fp) (reprmeter::MeterRepr(fp)) > >+#else > >+# define METER_REPR(fp) > > Avoid empty statement warnings (forget which compilers/options, but we do this > elsewhere based on being nagged over nothing) by making the no-op macro's body > ((void) 0). Done.
Comment 10•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/a79ea749498a
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•14 years ago
|
||
Added stub call profiling: http://hg.mozilla.org/users/danderson_mozilla.com/moo/rev/b79cd88ddfea Attached are the top 20 stub calls for SS and v8.
You need to log in
before you can comment on or make changes to this bug.
Description
•