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 efd841761acff9e77643bb7c31af3e49c1590d91..0eef8429864950b8cfd8a708fed562ca0d97418f 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 6c59073833c379d5370fc0594c8b73221901d3e4..f0a240331d08154a0b04b4adb90131f975c48789 100644 (file)
@@ -1,3 +1,22 @@
+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