Factor does not do inline caching (although this is planned), however the language itself is more static and the compiler performs more advanced optimizations than the V8 JIT. So I thought it would be interesting to see how these two approaches to dynamic language implementation stack up.
I compiled the V8 trunk today on my Intel Core 2 Duo. Factor is of course the latest Factor from git.
I chose the following benchmarks from the language shootout:
- spectral-norm
- binary-trees
- fasta
- nsieve
- nsieve-bits
- partial-sums
Unfortunately, I couldn't get reverse-complement or a few others to work in V8, because they use the
readline() function which does not appear to exist. It would have been interesting to compare more benchmarks.I got the JavaScript versions from the shootout website; the Factor versions are in the Factor repository.
I ran the V8 benchmarks from the command line, like so,
./shell foo.jsAnd I ran the Factor benchmarks from within the Factor environment.
Without further ado, and without any attempt at post-mortem or analysis, here are the results. All running times are in seconds:
| Benchmark: | Factor | V8 |
|---|---|---|
| binary-trees | 3.1 | 3.8 |
| fasta | 8.9 | 12 |
| nsieve | 0.6 | 1.3 |
| nsieve-bits | 1.5 | 6.9 |
| partial-sums | 2.6 | 2.3 |
| spectral-norm | 29 | 85 |
6 comments:
readline() can likely be replaced by gets() without altering the program much.
since the results are in the same order of magnitude, in which language are the programs easier to write?
That's good. The new JavaScript engine from Mozilla is easy to compile and can be faster than V8 too.
It would be better to run these multiple times, so that we can do statistical tests.
Slava: any idea why partial-sums is slower in Factor?
Go mess with Java instead, you bully :-)
Post a Comment