Title: [201959] trunk/PerformanceTests
- Revision
- 201959
- Author
- [email protected]
- Date
- 2016-06-10 18:20:21 -0700 (Fri, 10 Jun 2016)
Log Message
Fix some text in Air.js/README.md
https://bugs.webkit.org/show_bug.cgi?id=158650
Reviewed by Benjamin Poulain.
I read the text again and found bugs:
- We never actually say how to run the benchmark. This change adds a blurb about how to run
it.
- We both say that allocateStack is responsible for the bulk of the running time and that
we haven't measured where the bulk of the time is spent. This changes the text to say that
it was a goal to make allocateStack be the hottest part of the benchmark, but that we did
not measure this.
* Air.js/README.md:
Modified Paths
Diff
Modified: trunk/PerformanceTests/Air.js/README.md (201958 => 201959)
--- trunk/PerformanceTests/Air.js/README.md 2016-06-11 01:18:37 UTC (rev 201958)
+++ trunk/PerformanceTests/Air.js/README.md 2016-06-11 01:20:21 UTC (rev 201959)
@@ -8,6 +8,9 @@
This documents the motivation, design, and license of Air.js.
+To run Air.js, simply open "Air.js/test.html" in your browser. It will only run
+correctly if your browser supports ES6.
+
## Motivation
At the time that Air.js was written, most _javascript_ benchmarks used ES5 or
@@ -90,18 +93,20 @@
These payloads allow Air.js to precisely replay allocateStack on those actual
functions.
-The payload is executable code that allocates the IR, and about 15% of
+It was an a priori goal of Air.js to spend most of the time in the
+allocateStack phase. This is a faithful reproduction of the C++ allocateStack
+phase, including its use of an abstract liveness analysis. It's abstract in the
+sense that the same liveness algorithm can be reused for temporaries,
+registers, or stack slots. In C++ this meant using templates, while in ES6 it
+means more run-time dynamic dispatch.
+
+Each IR payload is executable code that allocates the IR, and about 15% of
benchmark execution time is spent in that code. This is significant, but having
learned this, we don't feel that it would be honest to try to change the
efficiency of payload initialization. What if the payload initialization was
more expensive on our engine than others? If it was, then such a change would
not be fair.
-Most of the time in Air.js is spent running the allocateStack phase, which is
-reproduced faithfully in ES6, including its use of an abstract liveness
-analysis. It's abstract in the sense that the same liveness algorithm can be
-reused for temporaries, registers, or stack slots.
-
Air.js validates its results. We added a Code hashing capability to both the
C++ Air and Air.js, and we assert each payload looks identical after
allocateStack to what it would have looked like after the original C++
Modified: trunk/PerformanceTests/ChangeLog (201958 => 201959)
--- trunk/PerformanceTests/ChangeLog 2016-06-11 01:18:37 UTC (rev 201958)
+++ trunk/PerformanceTests/ChangeLog 2016-06-11 01:20:21 UTC (rev 201959)
@@ -1,5 +1,24 @@
2016-06-10 Filip Pizlo <[email protected]>
+ Fix some text in Air.js/README.md
+ https://bugs.webkit.org/show_bug.cgi?id=158650
+
+ Reviewed by Benjamin Poulain.
+
+ I read the text again and found bugs:
+
+ - We never actually say how to run the benchmark. This change adds a blurb about how to run
+ it.
+
+ - We both say that allocateStack is responsible for the bulk of the running time and that
+ we haven't measured where the bulk of the time is spent. This changes the text to say that
+ it was a goal to make allocateStack be the hottest part of the benchmark, but that we did
+ not measure this.
+
+ * Air.js/README.md:
+
+2016-06-10 Filip Pizlo <[email protected]>
+
Air.js should have some documentation
https://bugs.webkit.org/show_bug.cgi?id=158648
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
