In the web console demo, when running with the "emterpreter" build:
>> delta-time [x: 0 loop 1000000 [x: x + 1]]
== 0:00:28.202 ; that's 28 seconds, to count to a million
But when that same web console is running on the same machine, in the new and bleeding edge pure WASM with Pthreads build:
>> delta-time [x: 0 loop 1000000 [x: x + 1]]
== 0:00:00.863 ; more than THIRTY TIMES FASTER
Of course, we'd like to see that number go down too. And you might not notice the console seeming all that much faster on printing lines...but that's a different problem to address (related to callbacks and context switches).
The point is: by its very nature, the emterpreter was painfully slow. But now with pure WASM not only is it tremendously faster, the build products are half the size.
Try it out...but don't do stack overflows yet (that needs a different strategy than what R3-Alpha was using).
Note that if you're not using Chrome, you will have to enable SharedArrayBuffer and WASM threading.
It's in the about:config settings of Firefox. And if you're on Android you'll need to tick a couple of chrome://flags. Browsers are aiming to have these on by default...once they get over whatever their Spectre bug concern is. Odds are very high they'll be mainstream by the time any serious usage of Ren-C in browser happens. Even still, there's always the emterpreter fallback...and we can make that fallback more automatic (while trying to lobby you to change your switches). No shortage of options, here.
FYI: this is NOT easy stuff to do
Since not everyone completely understands the difficulty curve of various advancements, this one is pretty hard. Not as much that any particular line of code is hard to write in and of itself...but it's an intersection of a tremendous number of things:
- Trying to keep it all boxed up so that all the JavaScript pieces stay isolated to the JavaScript extension, and you can build without any of it contaminating anything else.
- Keeping the emterpreter version still working--since not all environments support pthread+WASM (yet)
- Writing complex, multithreaded C without being able to use a debugger on it
- Understanding all the inter-related concerns of C, Rebol, and JavaScript
- Planning for multiple deployment environments (Browser, Node) and multiple future paths for those environments
- Just reasoning about and designing this whole API model in the first place
There's still a lot to do
What's there now is a proof of concept. It needs to be gone over--ideally that would include some people who aren't me. :-/
Outside of stack overflows, there's still a whole slew of issues...regarding what to do about HALT and cancellation, as well as various other error/throw situations in the API.
But it's very encouraging, and I think there's a lot of potential in this direction.