undefined | Better HN

0 pointsivankra4mo ago0 comments

> Although it will be a lot slower, I’m not clear just how slow.

Around 30-50x slower than V8 (node/deno).

I've been recently benchmarking a lot of different engines: https://ivankra.github.io/javascript-zoo/

0 comments

> Around 30-50x slower than V8 (node/deno).

A solver running at 50ms instead of 1ms I would say is practically imperceptible to most users, but I don't know what time span you are measuring with those numbers.

ivankraOP4mo ago

My page is about generic JS benchmarks. Just did a quick run with a sample javascript challenge I got via yt-dlp (https://raw.githubusercontent.com/ivankra/javascript-zoo/ref...):

  $ time ./v8 /bench/yt-dlp.js | md5sum -
  a730e32029941bf1f60f9587a6d9554f  -
  real 0m0.252s
  user 0m0.386s
  sys 0m0.074s

  $ time ./quickjs /bench/yt-dlp.js | md5sum -
  a730e32029941bf1f60f9587a6d9554f  -
  real 0m2.280s
  user 0m2.507s
  sys 0m0.031s

So about 10x slower for the current flavor of YouTube challenges: 0.2s -> 2.2s.

A few more results on same input:

  spidermonkey 0.334s
  v8_jitless 1.096s => about the limit for JIT-less interpreters like quickjs
  graaljs 2.396s
  escargot 3.344s
  libjs 4.501s
  brimstone 6.328s
  modernc-quickjs 12.767s (pure Go port of quickjs)
  fastschema-qjs 1m22.801s (Wasm port of quickjs)
  boa 1m28.070s
  quickjs-ng 2m49.202s

ivankraOP4mo ago

Tidied up benchmark and results: https://gist.github.com/ivankra/a950b2c37db48c66fe5dceb0acd8...

Looks like quickjs is the next best option after the big three engines (V8/JSC/SM).

rdtsc4mo ago

Thanks for the benchmark!

I tried it on my slower laptop. I get:

   node(v8)  : 1.25s user 0.12s system 154% cpu 0.892 total
   quickjs   : 6.54s user 0.11s system 99% cpu 6.671 total
   quickjs-ng: 545.55s user 202.67s system 99% cpu 12:32.28 total

A 5x slowdown for an interpreted C JS engine is pretty good I think, compared to all the time, code and effort put into v8 over the years!

j / k navigate · click thread line to collapse

0 comments

ranger_danger4mo ago

> Around 30-50x slower than V8 (node/deno).

A solver running at 50ms instead of 1ms I would say is practically imperceptible to most users, but I don't know what time span you are measuring with those numbers.

ivankraOP4mo ago

My page is about generic JS benchmarks. Just did a quick run with a sample javascript challenge I got via yt-dlp (https://raw.githubusercontent.com/ivankra/javascript-zoo/ref...):

  $ time ./v8 /bench/yt-dlp.js | md5sum -
  a730e32029941bf1f60f9587a6d9554f  -
  real 0m0.252s
  user 0m0.386s
  sys 0m0.074s

  $ time ./quickjs /bench/yt-dlp.js | md5sum -
  a730e32029941bf1f60f9587a6d9554f  -
  real 0m2.280s
  user 0m2.507s
  sys 0m0.031s

So about 10x slower for the current flavor of YouTube challenges: 0.2s -> 2.2s.

A few more results on same input:

  spidermonkey 0.334s
  v8_jitless 1.096s => about the limit for JIT-less interpreters like quickjs
  graaljs 2.396s
  escargot 3.344s
  libjs 4.501s
  brimstone 6.328s
  modernc-quickjs 12.767s (pure Go port of quickjs)
  fastschema-qjs 1m22.801s (Wasm port of quickjs)
  boa 1m28.070s
  quickjs-ng 2m49.202s

ivankraOP4mo ago

Tidied up benchmark and results: https://gist.github.com/ivankra/a950b2c37db48c66fe5dceb0acd8...

Looks like quickjs is the next best option after the big three engines (V8/JSC/SM).

rdtsc4mo ago

Thanks for the benchmark!

I tried it on my slower laptop. I get:

   node(v8)  : 1.25s user 0.12s system 154% cpu 0.892 total
   quickjs   : 6.54s user 0.11s system 99% cpu 6.671 total
   quickjs-ng: 545.55s user 202.67s system 99% cpu 12:32.28 total

A 5x slowdown for an interpreted C JS engine is pretty good I think, compared to all the time, code and effort put into v8 over the years!

j / k navigate · click thread line to collapse