Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[GSoC 2013] Project Ideas
59 views
Skip to first unread message
吴伟/Wei WU
Apr 16, 2013, 7:56:39 AM4/16/13
to dev-tech-js-en...@lists.mozilla.org
Hi,
My name is Wei Wu and I would like to participate in Mozilla during GSoC
2013 as a student. I have been studying IonMonkey for several days, but I
haven't found any related ideas about it on Mozilla's idea list
pages[1][2]. The following are some ideas I'm interested in and I want to
know your opinions/comments:
1. Save Type Information for Continuous Optimizations.
SpiderMonkey interprets JavaScript bytecodes in the first place and
collects type information. IonMonkey will not be called until the type
information is stable. If we save type information on disks and reuse it
next time, it will shorten the interpreting time and enable further
optimizations.
( This idea comes from [3]. )
2. Cache compiled asm.js codes and IR to avoid runtime overhead.
Mozilla proposed asm.js as a low-level, efficient target language for
compilers[4]. Emscripten is the main producer of asm.js codes currently.
The asm.js codes translated by Emscripten are not changed frequently,
compare with typical JavaScript codes written by programmers, and it will
never bailout. It may be feasible to store both IR and binary for load time
speedup and further optimizations.
3. Improve the JIT Inspector.
JIT Inspector is a very useful tool for profiling. But its UI is relatively
simple and the interpretation of the results is not easy for beginners. I
can improve the UI to make it more user-friendly. Also, I am glad to
implement some features for it, e.g. saving results in a file, etc.
Are there any mentors interested in one of the ideas and would like to
mentor me during the summer? thanks.
[1]: https://wiki.mozilla.org/Community:SummerOfCode13
[2]: https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming
[3]: http://markmail.org/message/y6vbgptiull4w7yh
[4]: http://asmjs.org
--
Wei Wu
My name is Wei Wu and I would like to participate in Mozilla during GSoC
2013 as a student. I have been studying IonMonkey for several days, but I
haven't found any related ideas about it on Mozilla's idea list
pages[1][2]. The following are some ideas I'm interested in and I want to
know your opinions/comments:
1. Save Type Information for Continuous Optimizations.
SpiderMonkey interprets JavaScript bytecodes in the first place and
collects type information. IonMonkey will not be called until the type
information is stable. If we save type information on disks and reuse it
next time, it will shorten the interpreting time and enable further
optimizations.
( This idea comes from [3]. )
2. Cache compiled asm.js codes and IR to avoid runtime overhead.
Mozilla proposed asm.js as a low-level, efficient target language for
compilers[4]. Emscripten is the main producer of asm.js codes currently.
The asm.js codes translated by Emscripten are not changed frequently,
compare with typical JavaScript codes written by programmers, and it will
never bailout. It may be feasible to store both IR and binary for load time
speedup and further optimizations.
3. Improve the JIT Inspector.
JIT Inspector is a very useful tool for profiling. But its UI is relatively
simple and the interpretation of the results is not easy for beginners. I
can improve the UI to make it more user-friendly. Also, I am glad to
implement some features for it, e.g. saving results in a file, etc.
Are there any mentors interested in one of the ideas and would like to
mentor me during the summer? thanks.
[1]: https://wiki.mozilla.org/Community:SummerOfCode13
[2]: https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming
[3]: http://markmail.org/message/y6vbgptiull4w7yh
[4]: http://asmjs.org
--
Wei Wu
Luke Wagner
Apr 16, 2013, 11:54:10 AM4/16/13
to 吴伟/Wei WU, dev-tech-js-en...@lists.mozilla.org
Hi Wei Wu,
I'm glad to hear that you are interested. I'd like to comment on #2:
> 2. Cache compiled asm.js codes and IR to avoid runtime overhead.
> Mozilla proposed asm.js as a low-level, efficient target language for
> compilers[4]. Emscripten is the main producer of asm.js codes
> currently. The asm.js codes translated by Emscripten are not changed frequently,
> compare with typical JavaScript codes written by programmers, and it
> will never bailout. It may be feasible to store both IR and binary for
> load time speedup and further optimizations.
We have plans to give the developer explicit control over parallel compilation and jit-code caching (via IndexedDB) with the addition of a new FunctionFuture primitive [1], so this may not be necessary.
Cheers,
Luke
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=854627
I'm glad to hear that you are interested. I'd like to comment on #2:
> 2. Cache compiled asm.js codes and IR to avoid runtime overhead.
> Mozilla proposed asm.js as a low-level, efficient target language for
> compilers[4]. Emscripten is the main producer of asm.js codes
> currently. The asm.js codes translated by Emscripten are not changed frequently,
> compare with typical JavaScript codes written by programmers, and it
> will never bailout. It may be feasible to store both IR and binary for
> load time speedup and further optimizations.
Cheers,
Luke
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=854627
吴伟/Wei WU
Apr 17, 2013, 12:25:32 PM4/17/13
to Luke Wagner, dev-tech-js-en...@lists.mozilla.org
Hi Luke,
Thank you for your reply. I agree that #2 will be unnecessary if the jit
compilation process can be controlled by developers. I've read bug 854627
and found it was not implemented yet. I'm glad to work on this feature if
there is no one working on it.
--
吴伟(Wei Wu)
Thank you for your reply. I agree that #2 will be unnecessary if the jit
compilation process can be controlled by developers. I've read bug 854627
and found it was not implemented yet. I'm glad to work on this feature if
there is no one working on it.
吴伟(Wei Wu)
Nicolas B. Pierron
Apr 18, 2013, 10:01:36 PM4/18/13
to
Hi,
On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
> My name is Wei Wu and I would like to participate in Mozilla during GSoC
> 2013 as a student. I have been studying IonMonkey for several days, but I
> haven't found any related ideas about it on Mozilla's idea list
> pages[1][2].
>
(March 29th). You can still ask Gerv & Florian as suggested on [1].
On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
> The following are some ideas I'm interested in and I want to
> know your opinions/comments:
>
> 1. Save Type Information for Continuous Optimizations.
> SpiderMonkey interprets JavaScript bytecodes in the first place and
> collects type information. IonMonkey will not be called until the type
> information is stable. If we save type information on disks and reuse it
> next time, it will shorten the interpreting time and enable further
> optimizations.
> ( This idea comes from [3]. )
They are multiple issues related to this project, and the Type Inference is
a hairy part of SpiderMonkey. Some of the issues are that code can be
generated through an eval function call, the filesystem cannot be considered
as reliable in terms of latency, and Type Inference might shrink at some
point which can improve performances.
Notice that riadh [3] investigated the performance benefit of doing some
caching on the bytecode. And proved my assumptions to be incorrect. One
aspect which might be interesting would be to add some lazy-loading of the
bytecode. As you might know most of the JavaScript code which is downloaded
is rarely executed, it might be interesting to see if we can optimize such
cases especially for saving memory in b2g.
> 3. Improve the JIT Inspector.
> JIT Inspector is a very useful tool for profiling. But its UI is relatively
> simple and the interpretation of the results is not easy for beginners. I
> can improve the UI to make it more user-friendly. Also, I am glad to
> implement some features for it, e.g. saving results in a file, etc.
The JIT Inspector is some-kind of internal tool which is not a priority, and
is frequently broken, as we add/remove/modify JITs.
I think what would be even more interesting on this axes would be to provide
an API (possibly integrated with the dev tools) which somehow return a list
of possible enhancement based on the internal counters and on the
compilation choices (polymorphism, type). Using this interface with
different verbosity level can result in the same out-come as what the
JIT-Inspector is reporting.
The main reason why the JIT-Inspector does not have a lot of love lately is
because its output is extremely tie to the internal representation, and
changes to the internal representation / process need to be instrumented as
the changes are made, which is not a priority.
On Wed 17 Apr 2013 09:43:47 AM PDT, Luke Wagner wrote:
> Hi Wei Wu,
>
> Thank you for your interest! Bug 854627 may be a pretty frustrating GSoC
project and first bug on our JS engine in general; it'll mostly require a
significant amount of refactoring that depends on knowledge of how the JS
engine works. Something in IonMonkey may be more appropriate; perhaps
Nicolas has some thoughts on this?
>
> Cheers,
> Luke
They are multiple projects which might be of interest for IonMonkey, such as:
- Clarifying our heuristics, to be able to make guesses while we are
compiling in IonMonkey, and recompile without the guarded assumptions if the
bailout paths are too costly. Our current view is mostly black & white and
only one bad use case can destroy the performances. We need to introduce
some gray view, saying that we are compiling for the likely sub-set and
accept bailouts as part of the normal lifetime of a script. As of today,
IonMonkey is too much like a normal compiler, we should make it an
assumption based compiler.
- Adding resume operations, such as an instruction can be moved to a later
point in the control flow. One of the problem inherent to the imprecise
typing that we have with JavaScript is that any code can break one of our
assumption and cause an invalidation. In case of bailout, we need to resume
the execution in in the interpreter, and thus we need to have executed
everything before. With resume operations, we can delay an operation to a
point where it is needed and add resume operations if we bailout before the
computation. To give a support to what I attempt to explain:
function f() {
var x = 0;
for (var i = 0; i < 1000; i++) {
x = … pure & inlined computation …(i);
if (… unlikely condition independent of x …) {
… use x …
break;
}
}
}
In this function, x computation is worth moving under the if branch.
This optimization is a blocker for any optimization which can be done with
the escape analysis.
- Adding profile guided optimization, the idea would be to profile which
branches are used and to prune branches which are unused, either while
generating the MIR Graph, or as a second optimization phase working on the
graph. A trivial way of doing so can just look at the jump target which
have been visited so far. A more clever one might register the transition
and use Markov chain to determine relations between branches, and duplicate
a sub-part of the graph to improve constant propagation and the range
analysis. Before doing anything fancy like the more-clever case we still
need to check that this is worth it and see the benefit of other
optimizations if we fold the graph.
Other case of smaller projects might be:
- Improving our Alias Analysis to take advantage of the type set (this might
help a lot kraken benchmarks, by factoring out array accesses).
- Improve dummy functions used for asm.js boundaries. Asm.js needs to
communicate with the DOM, and to do so it need some trampoline functions
which are used as an interface with the DOM API. Such trampolines might
transform typed arrays into strings or objects and serialize the result back
into typed arrays.
--
Nicolas B. Pierron
On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
> My name is Wei Wu and I would like to participate in Mozilla during GSoC
> 2013 as a student. I have been studying IonMonkey for several days, but I
> haven't found any related ideas about it on Mozilla's idea list
> pages[1][2].
>
> [1]: https://wiki.mozilla.org/Community:SummerOfCode13
> [2]: https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming
Based on [2], the deadline for GSoC projects seems to be already passed
> [2]: https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming
(March 29th). You can still ask Gerv & Florian as suggested on [1].
On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
> The following are some ideas I'm interested in and I want to
> know your opinions/comments:
>
> 1. Save Type Information for Continuous Optimizations.
> SpiderMonkey interprets JavaScript bytecodes in the first place and
> collects type information. IonMonkey will not be called until the type
> information is stable. If we save type information on disks and reuse it
> next time, it will shorten the interpreting time and enable further
> optimizations.
> ( This idea comes from [3]. )
a hairy part of SpiderMonkey. Some of the issues are that code can be
generated through an eval function call, the filesystem cannot be considered
as reliable in terms of latency, and Type Inference might shrink at some
point which can improve performances.
Notice that riadh [3] investigated the performance benefit of doing some
caching on the bytecode. And proved my assumptions to be incorrect. One
aspect which might be interesting would be to add some lazy-loading of the
bytecode. As you might know most of the JavaScript code which is downloaded
is rarely executed, it might be interesting to see if we can optimize such
cases especially for saving memory in b2g.
> 3. Improve the JIT Inspector.
> JIT Inspector is a very useful tool for profiling. But its UI is relatively
> simple and the interpretation of the results is not easy for beginners. I
> can improve the UI to make it more user-friendly. Also, I am glad to
> implement some features for it, e.g. saving results in a file, etc.
is frequently broken, as we add/remove/modify JITs.
I think what would be even more interesting on this axes would be to provide
an API (possibly integrated with the dev tools) which somehow return a list
of possible enhancement based on the internal counters and on the
compilation choices (polymorphism, type). Using this interface with
different verbosity level can result in the same out-come as what the
JIT-Inspector is reporting.
The main reason why the JIT-Inspector does not have a lot of love lately is
because its output is extremely tie to the internal representation, and
changes to the internal representation / process need to be instrumented as
the changes are made, which is not a priority.
On Wed 17 Apr 2013 09:43:47 AM PDT, Luke Wagner wrote:
> Hi Wei Wu,
>
> Thank you for your interest! Bug 854627 may be a pretty frustrating GSoC
project and first bug on our JS engine in general; it'll mostly require a
significant amount of refactoring that depends on knowledge of how the JS
engine works. Something in IonMonkey may be more appropriate; perhaps
Nicolas has some thoughts on this?
>
> Cheers,
> Luke
They are multiple projects which might be of interest for IonMonkey, such as:
- Clarifying our heuristics, to be able to make guesses while we are
compiling in IonMonkey, and recompile without the guarded assumptions if the
bailout paths are too costly. Our current view is mostly black & white and
only one bad use case can destroy the performances. We need to introduce
some gray view, saying that we are compiling for the likely sub-set and
accept bailouts as part of the normal lifetime of a script. As of today,
IonMonkey is too much like a normal compiler, we should make it an
assumption based compiler.
- Adding resume operations, such as an instruction can be moved to a later
point in the control flow. One of the problem inherent to the imprecise
typing that we have with JavaScript is that any code can break one of our
assumption and cause an invalidation. In case of bailout, we need to resume
the execution in in the interpreter, and thus we need to have executed
everything before. With resume operations, we can delay an operation to a
point where it is needed and add resume operations if we bailout before the
computation. To give a support to what I attempt to explain:
function f() {
var x = 0;
for (var i = 0; i < 1000; i++) {
x = … pure & inlined computation …(i);
if (… unlikely condition independent of x …) {
… use x …
break;
}
}
}
In this function, x computation is worth moving under the if branch.
This optimization is a blocker for any optimization which can be done with
the escape analysis.
- Adding profile guided optimization, the idea would be to profile which
branches are used and to prune branches which are unused, either while
generating the MIR Graph, or as a second optimization phase working on the
graph. A trivial way of doing so can just look at the jump target which
have been visited so far. A more clever one might register the transition
and use Markov chain to determine relations between branches, and duplicate
a sub-part of the graph to improve constant propagation and the range
analysis. Before doing anything fancy like the more-clever case we still
need to check that this is worth it and see the benefit of other
optimizations if we fold the graph.
Other case of smaller projects might be:
- Improving our Alias Analysis to take advantage of the type set (this might
help a lot kraken benchmarks, by factoring out array accesses).
- Improve dummy functions used for asm.js boundaries. Asm.js needs to
communicate with the DOM, and to do so it need some trampoline functions
which are used as an interface with the DOM API. Such trampolines might
transform typed arrays into strings or objects and serialize the result back
into typed arrays.
--
Nicolas B. Pierron
Nicolas B. Pierron
Apr 19, 2013, 4:21:25 PM4/19/13
to
On 04/18/2013 07:01 PM, Nicolas B. Pierron wrote:
> Hi,
>
> On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
>> My name is Wei Wu and I would like to participate in Mozilla during GSoC
>> 2013 as a student. I have been studying IonMonkey for several days, but I
>> haven't found any related ideas about it on Mozilla's idea list
>> pages[1][2].
>>
>> [1]: https://wiki.mozilla.org/Community:SummerOfCode13
>> [2]: https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming
>
> Based on [2], the deadline for GSoC projects seems to be already passed
> (March 29th). You can still ask Gerv & Florian as suggested on [1].
Ok, my bad, I don't follow the GSoC terminology, and March 29th was Mozilla
> Hi,
>
> On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
>> My name is Wei Wu and I would like to participate in Mozilla during GSoC
>> 2013 as a student. I have been studying IonMonkey for several days, but I
>> haven't found any related ideas about it on Mozilla's idea list
>> pages[1][2].
>>
>> [1]: https://wiki.mozilla.org/Community:SummerOfCode13
>> [2]: https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming
>
> Based on [2], the deadline for GSoC projects seems to be already passed
> (March 29th). You can still ask Gerv & Florian as suggested on [1].
applications, and May 3rd is the student applications.
I am not sure to fully understand what the implications of these dead lines.
--
Nicolas B. Pierron
吴伟/Wei WU
Apr 20, 2013, 5:41:38 AM4/20/13
to Nicolas B. Pierron, dev-tech-js-en...@lists.mozilla.org
Hi Nicolas,
Thank you for your patience! I'm very happy to receive your reply!
On Fri, Apr 19, 2013 at 10:01 AM, Nicolas B. Pierron <
nicolas....@mozilla.com> wrote:
> Hi,
>
>
> On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
>
>> My name is Wei Wu and I would like to participate in Mozilla during GSoC
>> 2013 as a student. I have been studying IonMonkey for several days, but I
>> haven't found any related ideas about it on Mozilla's idea list
>> pages[1][2].
>>
>> [1]: https://wiki.mozilla.org/**Community:SummerOfCode13<https://wiki.mozilla.org/Community:SummerOfCode13>
>> [2]: https://wiki.mozilla.org/**Community:SummerOfCode13:**Brainstorming<https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming>
>
>
> On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
> > The following are some ideas I'm interested in and I want to
> > know your opinions/comments:
> >
> > 1. Save Type Information for Continuous Optimizations.
> > SpiderMonkey interprets JavaScript bytecodes in the first place and
> > collects type information. IonMonkey will not be called until the type
> > information is stable. If we save type information on disks and reuse it
> > next time, it will shorten the interpreting time and enable further
> > optimizations.
> > ( This idea comes from [3]. )
>
> They are multiple issues related to this project, and the Type Inference
> is a hairy part of SpiderMonkey. Some of the issues are that code can be
> generated through an eval function call, the filesystem cannot be
> considered as reliable in terms of latency, and Type Inference might shrink
> at some point which can improve performances.
>
Hmm, I agree that finishing type inference related projects may beyond the
complexity of a GSoC project.
I found a bug (#825268
<https://bugzilla.mozilla.org/show_bug.cgi?id=825268>) that
may related to this project. According to the description of that bug I
realized that my understanding of the term 'heuristics' is relatively naive
(the strategy used by an optimization algorithm to modify the intermediate
representation is based on a few expressions calculated from the structure
of source codes.) and I think the heuristics you mentioned are more generic
than that.
If I understand correctly, 'compiling for the the likely sub-set' means
that we can compile multiple versions for a method and execute one of them
based on which one's assumptions are satisfied. for example:
function g(x){
...use x...
}
function f(){
for (var i = 0; i < 10000; i++){
if (i % 1000){
g(i);
}else{
g('string');
}
}
}
Currently IonMonkey compiles g(x) with the guard "assert(typeof x === int)"
and the jit code will be invalidated periodically. If g(x) can be compiled
with the assumption "assert(typeof x in {int,string}" then the bailouts
would be avoided.
Am I right?
> I'm interested in this idea and I'm willing to implement it. A simple and
fast algorithm may be a good choice for GSoC, while the advanced methods
require more investigation. I haven't found any branch profiling code in
the interpreter so the instrumenting mechanism must be finished first, or
we can leverage baseline compiler to generate self-instrumented jit code.
Profiling data can be saved separately or in MIR nodes as an annotation. In
the second case more other passes may benefit from it easily.
Two bugs (#410994 <https://bugzilla.mozilla.org/show_bug.cgi?id=410994>, #
419344 <https://bugzilla.mozilla.org/show_bug.cgi?id=419344> ) have
mentioned PGO but may be irrelevant with this idea.
> Other case of smaller projects might be:
>
> - Improving our Alias Analysis to take advantage of the type set (this
> might help a lot kraken benchmarks, by factoring out array accesses).
>
My knowledge about Alias Analysis is limited; I know the principles and
have read [4] <http://dl.acm.org/citation.cfm?id=277670> one year ago. I am
not sure how type sets can help subsequent optimizations. Would you please
provide me some more information(wiki, blogs, or papers) about it?
[4]: http://dl.acm.org/citation.cfm?id=277670
>
> - Improve dummy functions used for asm.js boundaries. Asm.js needs to
> communicate with the DOM, and to do so it need some trampoline functions
> which are used as an interface with the DOM API. Such trampolines might
> transform typed arrays into strings or objects and serialize the result
> back into typed arrays.
>
> I haven't read OdinMonkey's code yet, but I will look into it next week.
Speeding up asm.js on ARM is one of my interests.
> --
> Nicolas B. Pierron
>
> ______________________________**_________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-engine-internals@**lists.mozilla.org<dev-tech-js-en...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals>
>
--
吴伟(Wei Wu)
Thank you for your patience! I'm very happy to receive your reply!
On Fri, Apr 19, 2013 at 10:01 AM, Nicolas B. Pierron <
nicolas....@mozilla.com> wrote:
> Hi,
>
>
> On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
>
>> My name is Wei Wu and I would like to participate in Mozilla during GSoC
>> 2013 as a student. I have been studying IonMonkey for several days, but I
>> haven't found any related ideas about it on Mozilla's idea list
>> pages[1][2].
>>
>> [2]: https://wiki.mozilla.org/**Community:SummerOfCode13:**Brainstorming<https://wiki.mozilla.org/Community:SummerOfCode13:Brainstorming>
>>
>
> Based on [2], the deadline for GSoC projects seems to be already passed
> (March 29th). You can still ask Gerv & Florian as suggested on [1].
No problem, I as a student can submit new ideas before May 3rd.
>
> Based on [2], the deadline for GSoC projects seems to be already passed
> (March 29th). You can still ask Gerv & Florian as suggested on [1].
>
>
> On 04/16/2013 04:56 AM, 吴伟/Wei WU wrote:
> > The following are some ideas I'm interested in and I want to
> > know your opinions/comments:
> >
> > 1. Save Type Information for Continuous Optimizations.
> > SpiderMonkey interprets JavaScript bytecodes in the first place and
> > collects type information. IonMonkey will not be called until the type
> > information is stable. If we save type information on disks and reuse it
> > next time, it will shorten the interpreting time and enable further
> > optimizations.
> > ( This idea comes from [3]. )
>
> They are multiple issues related to this project, and the Type Inference
> is a hairy part of SpiderMonkey. Some of the issues are that code can be
> generated through an eval function call, the filesystem cannot be
> considered as reliable in terms of latency, and Type Inference might shrink
> at some point which can improve performances.
>
complexity of a GSoC project.
<https://bugzilla.mozilla.org/show_bug.cgi?id=825268>) that
may related to this project. According to the description of that bug I
realized that my understanding of the term 'heuristics' is relatively naive
(the strategy used by an optimization algorithm to modify the intermediate
representation is based on a few expressions calculated from the structure
of source codes.) and I think the heuristics you mentioned are more generic
than that.
If I understand correctly, 'compiling for the the likely sub-set' means
that we can compile multiple versions for a method and execute one of them
based on which one's assumptions are satisfied. for example:
function g(x){
...use x...
}
function f(){
for (var i = 0; i < 10000; i++){
if (i % 1000){
g(i);
}else{
g('string');
}
}
}
Currently IonMonkey compiles g(x) with the guard "assert(typeof x === int)"
and the jit code will be invalidated periodically. If g(x) can be compiled
with the assumption "assert(typeof x in {int,string}" then the bailouts
would be avoided.
Am I right?
fast algorithm may be a good choice for GSoC, while the advanced methods
require more investigation. I haven't found any branch profiling code in
the interpreter so the instrumenting mechanism must be finished first, or
we can leverage baseline compiler to generate self-instrumented jit code.
Profiling data can be saved separately or in MIR nodes as an annotation. In
the second case more other passes may benefit from it easily.
Two bugs (#410994 <https://bugzilla.mozilla.org/show_bug.cgi?id=410994>, #
419344 <https://bugzilla.mozilla.org/show_bug.cgi?id=419344> ) have
mentioned PGO but may be irrelevant with this idea.
> Other case of smaller projects might be:
>
> - Improving our Alias Analysis to take advantage of the type set (this
> might help a lot kraken benchmarks, by factoring out array accesses).
>
have read [4] <http://dl.acm.org/citation.cfm?id=277670> one year ago. I am
not sure how type sets can help subsequent optimizations. Would you please
provide me some more information(wiki, blogs, or papers) about it?
[4]: http://dl.acm.org/citation.cfm?id=277670
>
> - Improve dummy functions used for asm.js boundaries. Asm.js needs to
> communicate with the DOM, and to do so it need some trampoline functions
> which are used as an interface with the DOM API. Such trampolines might
> transform typed arrays into strings or objects and serialize the result
> back into typed arrays.
>
Speeding up asm.js on ARM is one of my interests.
> --
> Nicolas B. Pierron
>
> ______________________________**_________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-engine-internals@**lists.mozilla.org<dev-tech-js-en...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals>
>
--
吴伟(Wei Wu)
Nicolas B. Pierron
Apr 20, 2013, 8:37:29 PM4/20/13
to
Hi,
If g is not inlined, IonMonkey will compile with a guard to ensure that x is
an Int. As soon as a call is made with a string, we will discard the code,
and later recompile it with a larger type set (int & string). The problem
is that doing operations on something which can be either an int or a string
will always be slow, as we fallback on VM function calls. In your example
the Int case can be executed in the baseline compiler while the string case
can remain in Ion-compiled code. Doing a bailout might still be worth it
compared to the price of a recompilation and a slower execution for the
most-likely use case.
The question which remain behind is: "Should we keep or discard the code?".
To be able to answer this question we need some kind of heuristics. And
before making heuristics, we need a meaningful metric. The only metric that
is meaningful in such cases is the time, but not ordinary time, as we are at
the mercy of the scheduler. Bug 825268 suggests to clean-up the way we are
using the use-count to make it a reliable & *determinist* source of time
based on the execution of scripts.
>> - Adding profile guided optimization, the idea would be to profile which
>> branches are used and to prune branches which are unused, either while
>> generating the MIR Graph, or as a second optimization phase working on the
>> graph. A trivial way of doing so can just look at the jump target which
>> have been visited so far. A more clever one might register the transition
>> and use Markov chain to determine relations between branches, and duplicate
>> a sub-part of the graph to improve constant propagation and the range
>> analysis. Before doing anything fancy like the more-clever case we still
>> need to check that this is worth it and see the benefit of other
>> optimizations if we fold the graph.
>>
> I'm interested in this idea and I'm willing to implement it. A simple and
> fast algorithm may be a good choice for GSoC, while the advanced methods
> require more investigation. I haven't found any branch profiling code in
> the interpreter so the instrumenting mechanism must be finished first, or
> we can leverage baseline compiler to generate self-instrumented jit code.
> Profiling data can be saved separately or in MIR nodes as an annotation. In
> the second case more other passes may benefit from it easily.
Indeed, there is no code for profiling yet. The most easiest way to think
about it is to do like the write barrier of the incremental GC, i-e having a
buffer (potentially circular, as the opposite of the write barrier) which is
filled with jump targets. Thus, every time we jump to another location in
the code we push the location of the offset in this buffer, and later we
reuse this buffer to re-organize basic blocks in IonMonkey and to duplicate
/ prune basic blocks if needed.
> Two bugs (#410994 <https://bugzilla.mozilla.org/show_bug.cgi?id=410994>, #
> 419344 <https://bugzilla.mozilla.org/show_bug.cgi?id=419344> ) have
> mentioned PGO but may be irrelevant with this idea.
Indeed, they are irrelevant for doing PGO on JavaScript.
>> Other case of smaller projects might be:
>>
>> - Improving our Alias Analysis to take advantage of the type set (this
>> might help a lot kraken benchmarks, by factoring out array accesses).
>>
> My knowledge about Alias Analysis is limited; I know the principles and
> have read [4] <http://dl.acm.org/citation.cfm?id=277670> one year ago. I am
> not sure how type sets can help subsequent optimizations. Would you please
> provide me some more information(wiki, blogs, or papers) about it?
> [4]: http://dl.acm.org/citation.cfm?id=277670
JavaScript is an untyped language, which means that any variable access can
alias (reference) the same value as variable. Currently IonMonkey alias
analysis is not clever and it does not use the type of object to know if one
write might alias another. If two variables are holding objects with
different types, then we have the guarantee that their value cannot alias
each others.
One JavaScript function which looks like that:
function f(a, arr) {
for (var i = 0; i < arr.length; i++) {
arr[i].b = 1;
a.b = 0;
}
}
Can be written in a well-typed language as:
void f(Foo *a, Vector<Bar> *arr) {
for (int i = 0; i < arr->length(); i++) {
(*arr)[i].b = 1;
a->b = 0;
}
}
where Foo is a different type than Bar. Which implies that both b are part
of different object, which means that the previous JavaScript function can
be transformed to:
function f(a, arr) {
a.b = 0; /* Assume shape of a is different than the shape of arr[i] */
for (var i = 0; i < arr.length; i++) {
arr[i].b = 1;
}
}
In the case of kraken, the problem is that the alias analysis does not
consider the type of Arrays and consider that the value they contain can be
anything, including them-self. If the alias analysis were using the type
information we should be able to figure out that M[i] does not alias
M[i][j], and thus factor M[i] access across setters of M[i][j].
>>
>> - Improve dummy functions used for asm.js boundaries. Asm.js needs to
>> communicate with the DOM, and to do so it need some trampoline functions
>> which are used as an interface with the DOM API. Such trampolines might
>> transform typed arrays into strings or objects and serialize the result
>> back into typed arrays.
>>
> I haven't read OdinMonkey's code yet, but I will look into it next week.
> Speeding up asm.js on ARM is one of my interests.
I do not know much of the status of OdinMonkey on ARM, a few weeks ago the
concern was just to be able to compile it, as the ahead-of-time compilation
was taking a lot of memory at the statr-up of the application, I wonder if
this is still a concern as we removed the generation of the bytecode.
What I was referring to are mostly bugs similar to Bug 860574 [1].
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=860574
--
Nicolas B. Pierron
an Int. As soon as a call is made with a string, we will discard the code,
and later recompile it with a larger type set (int & string). The problem
is that doing operations on something which can be either an int or a string
will always be slow, as we fallback on VM function calls. In your example
the Int case can be executed in the baseline compiler while the string case
can remain in Ion-compiled code. Doing a bailout might still be worth it
compared to the price of a recompilation and a slower execution for the
most-likely use case.
The question which remain behind is: "Should we keep or discard the code?".
To be able to answer this question we need some kind of heuristics. And
before making heuristics, we need a meaningful metric. The only metric that
is meaningful in such cases is the time, but not ordinary time, as we are at
the mercy of the scheduler. Bug 825268 suggests to clean-up the way we are
using the use-count to make it a reliable & *determinist* source of time
based on the execution of scripts.
>> - Adding profile guided optimization, the idea would be to profile which
>> branches are used and to prune branches which are unused, either while
>> generating the MIR Graph, or as a second optimization phase working on the
>> graph. A trivial way of doing so can just look at the jump target which
>> have been visited so far. A more clever one might register the transition
>> and use Markov chain to determine relations between branches, and duplicate
>> a sub-part of the graph to improve constant propagation and the range
>> analysis. Before doing anything fancy like the more-clever case we still
>> need to check that this is worth it and see the benefit of other
>> optimizations if we fold the graph.
>>
> I'm interested in this idea and I'm willing to implement it. A simple and
> fast algorithm may be a good choice for GSoC, while the advanced methods
> require more investigation. I haven't found any branch profiling code in
> the interpreter so the instrumenting mechanism must be finished first, or
> we can leverage baseline compiler to generate self-instrumented jit code.
> Profiling data can be saved separately or in MIR nodes as an annotation. In
> the second case more other passes may benefit from it easily.
about it is to do like the write barrier of the incremental GC, i-e having a
buffer (potentially circular, as the opposite of the write barrier) which is
filled with jump targets. Thus, every time we jump to another location in
the code we push the location of the offset in this buffer, and later we
reuse this buffer to re-organize basic blocks in IonMonkey and to duplicate
/ prune basic blocks if needed.
> Two bugs (#410994 <https://bugzilla.mozilla.org/show_bug.cgi?id=410994>, #
> 419344 <https://bugzilla.mozilla.org/show_bug.cgi?id=419344> ) have
> mentioned PGO but may be irrelevant with this idea.
>> Other case of smaller projects might be:
>>
>> - Improving our Alias Analysis to take advantage of the type set (this
>> might help a lot kraken benchmarks, by factoring out array accesses).
>>
> My knowledge about Alias Analysis is limited; I know the principles and
> have read [4] <http://dl.acm.org/citation.cfm?id=277670> one year ago. I am
> not sure how type sets can help subsequent optimizations. Would you please
> provide me some more information(wiki, blogs, or papers) about it?
> [4]: http://dl.acm.org/citation.cfm?id=277670
alias (reference) the same value as variable. Currently IonMonkey alias
analysis is not clever and it does not use the type of object to know if one
write might alias another. If two variables are holding objects with
different types, then we have the guarantee that their value cannot alias
each others.
One JavaScript function which looks like that:
function f(a, arr) {
for (var i = 0; i < arr.length; i++) {
arr[i].b = 1;
a.b = 0;
}
}
Can be written in a well-typed language as:
void f(Foo *a, Vector<Bar> *arr) {
for (int i = 0; i < arr->length(); i++) {
(*arr)[i].b = 1;
a->b = 0;
}
}
where Foo is a different type than Bar. Which implies that both b are part
of different object, which means that the previous JavaScript function can
be transformed to:
function f(a, arr) {
a.b = 0; /* Assume shape of a is different than the shape of arr[i] */
for (var i = 0; i < arr.length; i++) {
arr[i].b = 1;
}
}
In the case of kraken, the problem is that the alias analysis does not
consider the type of Arrays and consider that the value they contain can be
anything, including them-self. If the alias analysis were using the type
information we should be able to figure out that M[i] does not alias
M[i][j], and thus factor M[i] access across setters of M[i][j].
>>
>> - Improve dummy functions used for asm.js boundaries. Asm.js needs to
>> communicate with the DOM, and to do so it need some trampoline functions
>> which are used as an interface with the DOM API. Such trampolines might
>> transform typed arrays into strings or objects and serialize the result
>> back into typed arrays.
>>
> I haven't read OdinMonkey's code yet, but I will look into it next week.
> Speeding up asm.js on ARM is one of my interests.
concern was just to be able to compile it, as the ahead-of-time compilation
was taking a lot of memory at the statr-up of the application, I wonder if
this is still a concern as we removed the generation of the bytecode.
What I was referring to are mostly bugs similar to Bug 860574 [1].
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=860574
--
Nicolas B. Pierron
Nicolas B. Pierron
Apr 20, 2013, 9:22:02 PM4/20/13
to
On 04/20/2013 05:37 PM, Nicolas B. Pierron wrote:
> where Foo is a different type than Bar. Which implies that both b are part
> of different object, which means that the previous JavaScript function can
> be transformed to:
>
> function f(a, arr) {
> a.b = 0; /* Assume shape of a is different than the shape of arr[i] */
> for (var i = 0; i < arr.length; i++) {
> arr[i].b = 1;
> }
> }
Sorry, this is true, only if we can prove that the loop body is at least
> where Foo is a different type than Bar. Which implies that both b are part
> of different object, which means that the previous JavaScript function can
> be transformed to:
>
> function f(a, arr) {
> a.b = 0; /* Assume shape of a is different than the shape of arr[i] */
> for (var i = 0; i < arr.length; i++) {
> arr[i].b = 1;
> }
> }
executed once.
--
Nicolas B. Pierron
Wei WU(吴伟)
Apr 23, 2013, 1:05:36 AM4/23/13
to Nicolas B. Pierron, dev-tech-js-en...@lists.mozilla.org
Hi,
On Sun, Apr 21, 2013 at 8:37 AM, Nicolas B. Pierron <
There are two possible ways to store branch profiling data. One is count
array, the other is target buffer.
I've read LLVM's implementation of Branch(Edge) Profiling and found that it
uses a vector (array) to save the information. LLVM allocates two counters
for each branch/edge. When a block jumps to another the correlate counters
will be incremented by 1. Then these frequencies will be transformed into
probabilities and consumed by some transform passes. Jikes RVM stores
branch profiling data in the similar way.
One possible problem is that they use block ID to index branch counters and
we don't have such things in JavaScript bytecodes.
On the other hand, branch target buffer maintains a sequence of branch
targets and the index problem can be avoided. Further more, It makes
possible to determine relations between branches. The main problem I have
considered is that the cost of calculating branch probabilities might be
high, since we must traverse the buffer to summarize the results.
I have encountered some other issues. Could you give me some suggestions?
- Instrumenting the Interpreter is fairly easy, while I'm not sure it is
possible to instrument baseline compiler in the similar way. I think it's
better to support them both.
- Overhead. Instrumenting every conditional jumps may degrades performance
and an 'accepted overhead rate' should be considered. Also, it should be
able to switch on/off by command line arguments.
- Store/Restore profiling data on disks. Branch profiling data can be
stored and restored in LLVM and Jikes RVM. But I don't think it is
necessary in SpiderMonkey.
- Designing the interface of Branch Profiling. Since I was unable to find
design guidelines for SpiderMonkey, I will propose a draft interface in my
proposal and update it in future.
I am planning to submit a proposal for this project. Would you like to be
my mentor during this summer?
> Two bugs (#410994 <https://bugzilla.mozilla.org/**show_bug.cgi?id=410994<https://bugzilla.mozilla.org/show_bug.cgi?id=410994>>,
>> #
>> 419344 <https://bugzilla.mozilla.org/**show_bug.cgi?id=419344<https://bugzilla.mozilla.org/show_bug.cgi?id=419344>>
> [1] https://bugzilla.mozilla.org/**show_bug.cgi?id=860574<https://bugzilla.mozilla.org/show_bug.cgi?id=860574>
>
>
> --
> Nicolas B. Pierron
>
Wei Wu (吴伟)
On Sun, Apr 21, 2013 at 8:37 AM, Nicolas B. Pierron <
nicolas....@mozilla.com> wrote:
> Hi,
>
>
> On 04/20/2013 02:41 AM, 吴伟/Wei WU wrote:
>
>> On Fri, Apr 19, 2013 at 10:01 AM, Nicolas B. Pierron <
>> nicolas....@mozilla.com> wrote:
>>
>>>
>>> - Clarifying our heuristics, to be able to make guesses while we are
>>> compiling in IonMonkey, and recompile without the guarded assumptions if
>>> the bailout paths are too costly. Our current view is mostly black &
>>> white
>>> and only one bad use case can destroy the performances. We need to
>>> introduce some gray view, saying that we are compiling for the likely
>>> sub-set and accept bailouts as part of the normal lifetime of a script.
>>> As
>>> of today, IonMonkey is too much like a normal compiler, we should make it
>>> an assumption based compiler.
>>>
>>
>>
>>
>> I found a bug (#825268
>> <https://bugzilla.mozilla.org/**show_bug.cgi?id=825268<https://bugzilla.mozilla.org/show_bug.cgi?id=825268>>)
> Hi,
>
>
> On 04/20/2013 02:41 AM, 吴伟/Wei WU wrote:
>
>> On Fri, Apr 19, 2013 at 10:01 AM, Nicolas B. Pierron <
>> nicolas....@mozilla.com> wrote:
>>
>>>
>>> - Clarifying our heuristics, to be able to make guesses while we are
>>> compiling in IonMonkey, and recompile without the guarded assumptions if
>>> the bailout paths are too costly. Our current view is mostly black &
>>> white
>>> and only one bad use case can destroy the performances. We need to
>>> introduce some gray view, saying that we are compiling for the likely
>>> sub-set and accept bailouts as part of the normal lifetime of a script.
>>> As
>>> of today, IonMonkey is too much like a normal compiler, we should make it
>>> an assumption based compiler.
>>>
>>
>>
>>
>> I found a bug (#825268
array, the other is target buffer.
I've read LLVM's implementation of Branch(Edge) Profiling and found that it
uses a vector (array) to save the information. LLVM allocates two counters
for each branch/edge. When a block jumps to another the correlate counters
will be incremented by 1. Then these frequencies will be transformed into
probabilities and consumed by some transform passes. Jikes RVM stores
branch profiling data in the similar way.
One possible problem is that they use block ID to index branch counters and
we don't have such things in JavaScript bytecodes.
On the other hand, branch target buffer maintains a sequence of branch
targets and the index problem can be avoided. Further more, It makes
possible to determine relations between branches. The main problem I have
considered is that the cost of calculating branch probabilities might be
high, since we must traverse the buffer to summarize the results.
I have encountered some other issues. Could you give me some suggestions?
- Instrumenting the Interpreter is fairly easy, while I'm not sure it is
possible to instrument baseline compiler in the similar way. I think it's
better to support them both.
- Overhead. Instrumenting every conditional jumps may degrades performance
and an 'accepted overhead rate' should be considered. Also, it should be
able to switch on/off by command line arguments.
- Store/Restore profiling data on disks. Branch profiling data can be
stored and restored in LLVM and Jikes RVM. But I don't think it is
necessary in SpiderMonkey.
- Designing the interface of Branch Profiling. Since I was unable to find
design guidelines for SpiderMonkey, I will propose a draft interface in my
proposal and update it in future.
I am planning to submit a proposal for this project. Would you like to be
my mentor during this summer?
> Two bugs (#410994 <https://bugzilla.mozilla.org/**show_bug.cgi?id=410994<https://bugzilla.mozilla.org/show_bug.cgi?id=410994>>,
>> #
>> 419344 <https://bugzilla.mozilla.org/**show_bug.cgi?id=419344<https://bugzilla.mozilla.org/show_bug.cgi?id=419344>>
>> ) have
>>
>> mentioned PGO but may be irrelevant with this idea.
>>
>
> Indeed, they are irrelevant for doing PGO on JavaScript.
>
> Other case of smaller projects might be:
>>>
>>> - Improving our Alias Analysis to take advantage of the type set (this
>>> might help a lot kraken benchmarks, by factoring out array accesses).
>>>
>>> My knowledge about Alias Analysis is limited; I know the principles and
>> have read [4] <http://dl.acm.org/citation.**cfm?id=277670<http://dl.acm.org/citation.cfm?id=277670>>
>>
>> mentioned PGO but may be irrelevant with this idea.
>>
>
> Indeed, they are irrelevant for doing PGO on JavaScript.
>
> Other case of smaller projects might be:
>>>
>>> - Improving our Alias Analysis to take advantage of the type set (this
>>> might help a lot kraken benchmarks, by factoring out array accesses).
>>>
>>> My knowledge about Alias Analysis is limited; I know the principles and
>> one year ago. I am
>>
>> not sure how type sets can help subsequent optimizations. Would you please
>> provide me some more information(wiki, blogs, or papers) about it?
>> [4]: http://dl.acm.org/citation.**cfm?id=277670<http://dl.acm.org/citation.cfm?id=277670>
>>
>> not sure how type sets can help subsequent optimizations. Would you please
>> provide me some more information(wiki, blogs, or papers) about it?
>
>
> --
> Nicolas B. Pierron
>
> ______________________________**_________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-engine-internals@**lists.mozilla.org<dev-tech-js-en...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals>
>
--
Best wishes,
> dev-tech-js-engine-internals mailing list
> dev-tech-js-engine-internals@**lists.mozilla.org<dev-tech-js-en...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-tech-js-engine-**internals<https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals>
>
--
Wei Wu (吴伟)
Nicolas B. Pierron
Apr 23, 2013, 7:55:53 PM4/23/13
to
Hi,
Indeed, but we can use the jsbytecode pointers, as targets, and later
convert them to basic block numbers when we process the branch profile.
> On the other hand, branch target buffer maintains a sequence of branch
> targets and the index problem can be avoided. Further more, It makes
> possible to determine relations between branches. The main problem I have
> considered is that the cost of calculating branch probabilities might be
> high, since we must traverse the buffer to summarize the results.
I don't think the cost would be high, current CPU are good at prefetching
memory ahead of time on linear read of a buffer, which is likely the case
that we will encounter. What you need then would be a way to map the target
to the basic block to recover the counters.
It might be good, as a first step to have a circular buffer to experiment
with the branch prediction, and later reduce it to simple counters if the
buffer proved to be a major pitfall in terms of performance, or if the we do
not have any benchmark which can take advantage of a more-clever way of
inferring branches ordering.
> I have encountered some other issues. Could you give me some suggestions?
> - Instrumenting the Interpreter is fairly easy, while I'm not sure it is
> possible to instrument baseline compiler in the similar way. I think it's
> better to support them both.
As opposed to TI, which need to keep a consistent model of the types flowing
in, there is no restriction at only taking a sub-set of the profiling data.
Profiling only in the Baseline's code should be enough and would avoid
adding extra cost to the interpreter which is used by all script which are
running a few times.
> - Overhead. Instrumenting every conditional jumps may degrades performance
> and an 'accepted overhead rate' should be considered. Also, it should be
> able to switch on/off by command line arguments.
I agree with the CLI switch. The "accepted overhead" is weel-defined as
being our benchmark score and the memory usage. If you can improve our
benchmark score without taking too much memory, then this would be
acceptable performances.
> - Store/Restore profiling data on disks. Branch profiling data can be
> stored and restored in LLVM and Jikes RVM. But I don't think it is
> necessary in SpiderMonkey.
Indeed, I don't think it would be necessary either, and it would be even
more painful as the script might change when reloading the page, and
matching it back to the new script my lead to unexpected behaviour.
> - Designing the interface of Branch Profiling. Since I was unable to find
> design guidelines for SpiderMonkey, I will propose a draft interface in my
> proposal and update it in future.
The first goal would be to determine what might benefit from the removal of
unused (infrequently used) basic blocks. And see how this impact performances.
It might also be interesting to test different configuration such as doing
more bailouts and OSR based on what is recorded in the profile. such as a
branch which is not frequently taken and which return to the loop-head might
be worth discarding if on the other side we can improve the other
optimizations such as alias analysis, constant propagation and the range
analysis.
Even if branches are not removed, this might hint other optimizations such
as GVN & LICM to prevent moving some operations to locations where they
might induce more cost.
> I am planning to submit a proposal for this project. Would you like to be
> my mentor during this summer?
If your project is accepted by the GSoC program and by Mozilla, then I can
mentor this project.
--
Nicolas B. Pierron
convert them to basic block numbers when we process the branch profile.
> On the other hand, branch target buffer maintains a sequence of branch
> targets and the index problem can be avoided. Further more, It makes
> possible to determine relations between branches. The main problem I have
> considered is that the cost of calculating branch probabilities might be
> high, since we must traverse the buffer to summarize the results.
memory ahead of time on linear read of a buffer, which is likely the case
that we will encounter. What you need then would be a way to map the target
to the basic block to recover the counters.
It might be good, as a first step to have a circular buffer to experiment
with the branch prediction, and later reduce it to simple counters if the
buffer proved to be a major pitfall in terms of performance, or if the we do
not have any benchmark which can take advantage of a more-clever way of
inferring branches ordering.
> I have encountered some other issues. Could you give me some suggestions?
> - Instrumenting the Interpreter is fairly easy, while I'm not sure it is
> possible to instrument baseline compiler in the similar way. I think it's
> better to support them both.
in, there is no restriction at only taking a sub-set of the profiling data.
Profiling only in the Baseline's code should be enough and would avoid
adding extra cost to the interpreter which is used by all script which are
running a few times.
> - Overhead. Instrumenting every conditional jumps may degrades performance
> and an 'accepted overhead rate' should be considered. Also, it should be
> able to switch on/off by command line arguments.
being our benchmark score and the memory usage. If you can improve our
benchmark score without taking too much memory, then this would be
acceptable performances.
> - Store/Restore profiling data on disks. Branch profiling data can be
> stored and restored in LLVM and Jikes RVM. But I don't think it is
> necessary in SpiderMonkey.
more painful as the script might change when reloading the page, and
matching it back to the new script my lead to unexpected behaviour.
> - Designing the interface of Branch Profiling. Since I was unable to find
> design guidelines for SpiderMonkey, I will propose a draft interface in my
> proposal and update it in future.
unused (infrequently used) basic blocks. And see how this impact performances.
It might also be interesting to test different configuration such as doing
more bailouts and OSR based on what is recorded in the profile. such as a
branch which is not frequently taken and which return to the loop-head might
be worth discarding if on the other side we can improve the other
optimizations such as alias analysis, constant propagation and the range
analysis.
Even if branches are not removed, this might hint other optimizations such
as GVN & LICM to prevent moving some operations to locations where they
might induce more cost.
> I am planning to submit a proposal for this project. Would you like to be
> my mentor during this summer?
mentor this project.
--
Nicolas B. Pierron
0 new messages