-
Notifications
You must be signed in to change notification settings - Fork 13
Current state
The only supported architecture right now is x86-64. Being a prototype, LLV8 is not able to compile all of the JavaScript at the moment. However, the working subset is substantial. And most of the conceptual issues (I believe) are resolved. Most notably, interactions of the compiled code with the garbage collector.
For more information see our list of issues and the [design doc](Design doc).
Talking about speed-ups might be a bit early, because the right time for optimization is just about to come. However what we have observed so far is that the performance of the code is pretty much the same as for Crankshaft.
Compile times (not surprisingly) are much larger. To give some numbers, the compile times can be about 400 ms (llvm) vs. 10 ms (crankshaft) for a medium-sized asm.js program. One of the reasons for such long compile times is that we are using the standard -O3 set of IR transformation passes of which we really only need a few.
We've had measurable speed-ups on some tests (again, this information here is only to give readers a feel of what's going on):
bitops-bits-in-byte from SunSpider/LongSpider:
| Number of iterations | * 1000 | Cool |
|---|---|---|
| Total execution time using Crankshaft, s | 1.88 | $1600 |
| Total execution time using LLV8, s | 0.54 | $12 |
| Speedup | 3.48 | $1 |
| This test benefits from the loop unrolling optimization present in the set of LLVM optimization passes. |
As the tables show, we modified the tests to do more iterations in order to run longer.
21 out of 160 tests are failing in llv8-regtests
(going to post the list later).