some SqueakJS benchmarks, comparing Smalltalk with JavaScript-via-Web-Workers

Hi--

     Now that I can fork dynamic Web Workers from SqueakJS, here are
some benchmark results. The test: What's the highest Fibonacci number
you can calculate in one second? Each result is that number, and then
how much slower the system is at calculating the highest numbers
obtained by faster systems. "JS" refers to a Web Worker forked by
SqueakJS, "ST" refers to running the test in Smalltalk in SqueakJS. The
laptop is a 2017 MBP 13", and the mobile device is an iPhone SE.

     laptop macOS ST (native, Cog not Spur): 40, baseline
     laptop Chrome JS: 34, 17x macOS
     mobile Safari JS: 33, 1.5x laptop Chrome JS
     laptop Chrome ST: 29, 12x laptop Chrome JS, 8x mobile Safari JS
     mobile Safari ST: 24, 22x mobile Safari JS, 3x laptop Chrome ST


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

     Oops, here's a more clearly-worded version...

     It's convenient to run JS code on the fly from within SqueakJS via
Web Workers. So let's run some benchmarks. :) The test: What's the
highest Fibonacci number you can calculate in one second? Each result is
that number, and then how much faster other systems are. "JS" refers to
JS code running in a Web Worker forked by SqueakJS, "ST" refers to
running the test in Smalltalk in SqueakJS.

     laptop native Cog on macOS: 40 (baseline)
     laptop Chrome JS: 34 (laptop native Cog on macOS is 17x faster)
     mobile Safari JS: 33 (laptop Chrome JS is 1.5x faster)
     laptop Chrome ST: 29 (laptop Chrome JS is 12x faster,
                           mobile Safari JS is 8x faster)
     mobile Safari ST: 24 (mobile Safari JS is 22x faster,
                           laptop Chrome ST is 3x faster)


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

Hi Bert!

> What's the overhead of the WebWorkers? I mean compared to just running
> the JS code from SqueakJS:
>
> JS at: 'fib' put: (JS Function new: 'n' with: 'return n <= 1 ? n :
> fib(n-1) + fib(n-2)').
> JS fib: 38
> ==> 39088169

     On my 2017 MBP 13', it costs 40ms to create and start a Web Worker,
and 1ms for each communication between it and the thread that created it
(for posting input data and results).

     The overhead of running the JS code with the JS bridge directly is
lower (sub-millisecond), but you commandeer the main JS thread that's
running the SqueakJS VM while that JS code runs. By using a worker, the
SqueakJS UI continues uninterrupted while the JS code runs in a separate
thread, potentially on a separate physical processor. That's what I
meant by Web Workers being "convenient". :)  I have better examples
coming up where parallelism is actually relevant to the use case, and
not just the convenience of running the benchmark.

     There are also optimizations that the JS engines of various web
browsers employ when code is running in a worker, largely isolated from
the environment of the main JS thread (especially when the worker is
invoked many times instead of just once).


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

> By using a worker, the SqueakJS UI continues uninterrupted while the
> JS code runs in a separate thread, potentially on a separate physical
> processor.

     And the most useful thing about Web Workers to me at the moment is
for servicing JS callbacks in something which is truly a separate
thread. Ideally, I would service all JS callbacks with Smalltalk
processes, but the cost of just getting back into Squeak to begin
servicing a JS callback is extremely high.


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
[hidden email]
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)