Benchmarks and performance data?
mbertschler opened this issue · comments
On average 6-7 times faster than otto. Also uses considerably less memory.
What benchmark code did you use for this, and what were the exact results?
Nice work so far :)
I used octane 2.0, some of the long running tc39 tests (specifically this and this).
Haven't had time to prepare the results in a publishable form, sorry.
Still haven't had the time to prepare results? Would really love to see how it stacks up against Otto and V8... how much slow it is at least compared to V8 in simple tests.
otto parallel test
otto parallel thread : 33.652262738s
goja parallel test
goja parallel thread : 10.559833574s
benchmark otto
Box2D 89.3
Crypto 18.1
DeltaBlue 18.5
EarleyBoyer 70
NavierStokes 29.6
RayTrace 56.1
Richards 20.5
Splay 129
SplayLatency 627
benchmark goja
Box2D 509
Crypto 87.8
DeltaBlue 227
EarleyBoyer 471
NavierStokes 184
RayTrace 254
Richards 188
Splay 921
SplayLatency 4193
https://github.com/sokolovstas/fun/tree/master/go_javascript
How does it compare to Duktape wrappers, e.g. go-duktape?
@aidansteele it should be pretty interesting 'cause cgo adds 100ns overhead on each call
If anyone's still wondering, I ran a quick test just out of curiosity about how "go" javascript engine implementations compare.
I ran the following code a couple times:
function factorial(n) {
return n === 1 ? n : n * factorial(--n);
}
var i = 0;
while (i++ < 1e6) {
factorial(10);
}
The execution times roughly were:
otto: 33.195s
goja: 3.937s
duktape: 1.545s
v8 (go binding): 0.309s
v8 native (d8): 0.187s
It definitely isn't a real benchmark, and you won't really see the above lines in a real javascript code (well unless you need to calculate 10! 10^6 times for some reason 😄 ), but it should give an idea.
@tamasf97 out of curiosity, which v8 go binding package did you use? It's quite hard to find bindings that are not outdated/abandoned…
@tisba I don't have any of these anymore, but I'm almost certain it was this https://github.com/augustoroman/v8 . At least I remember the installation steps mentioning getting a compiled v8 from a ruby gem. Right now I don't believe there's any "proper" v8 binding around, as almost no one is interested enough in using v8 with Go from what I've seen.
That's too bad :( Efficient scripting support for a "static" language like Go is really nice and useful. Although I'm quite new to the ecosystem, my observation is quite similar (many, apparently abandoned projects).
About "goroutine safety", is it due to a JS implementation constraint? I don't understand why every JS VM has this and cannot be used concurrently using distinct execution contexts.
Currently Runtime is the execution context. It has an associated VM which has stacks and other associated state, there is no way a VM could be used concurrently. Another issue is that all Object values are backed by go maps which are also not goroutine-safe. Hope that explains.
Besides, even if above problems were somehow solved, ECMAScript is designed to be single-threaded, there is no synchronisation mechanism and most built-in functions would break if there were concurrent modifications.
A thought on this, couldn't the maps be mutex guarded or sync.Maps internally. Likewise, wouldn't it be possible to provide a Reset method to reset the internal state and allow the user to guard the usage with mutexes like other Go standard lib packages?
I ran a quick test just out of curiosity about how "go" javascript engine implementations compare....
I think you'd get very different results if you ran a small script 100,000 times rather than running a big script 1 time:
function factorial(n) {
return n === 1 ? n : n * factorial(--n);
}
var i = 0;
while (i++ < 10) {
factorial(10);
}
I have done some benchmarking today on the effect of reusing *goa.Program and pooling VMs here: