Fix some text in Air.js/README.md
authorfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 11 Jun 2016 01:20:21 +0000 (01:20 +0000)
committerfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 11 Jun 2016 01:20:21 +0000 (01:20 +0000)
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:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@201959 268f45cc-cd09-0410-ab3c-d52691b4dbfc

PerformanceTests/Air.js/README.md
PerformanceTests/ChangeLog

index efd8417..0eef842 100644 (file)
@@ -8,6 +8,9 @@ use them.
 
 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 @@ benchmarks according to JavaScriptCore's internal profiling:
 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++
index 6c59073..f0a2403 100644 (file)
@@ -1,5 +1,24 @@
 2016-06-10  Filip Pizlo  <fpizlo@apple.com>
 
+        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  <fpizlo@apple.com>
+
         Air.js should have some documentation
         https://bugs.webkit.org/show_bug.cgi?id=158648