Rakudo.js managed to parse (including running BEGIN blocks) all of the setting with an exception of one line that requires figuring out/measuring how to support uncached methods efficiently. (uncached methods are ones where we let the HOW handle the method call by running arbitrary code rather then installing a bunch of methods at once).
Generating the js code for the setting uncovered some performance issues like overflowing the stack by recursing too much (fixed) and running out of memory (not yet fixed).
I'm now focusing on getting a small prefix of the setting to fully co…
I'm working on getting it to compile the whole setting.
The setting executes a bunch of code at compile time (it has BEGIN blocks, constant declarators etc.) so the code the compiler is generated is validated to some degree (the test suit will exercise it much more).
I'm mostly fixing bugs, and implementing missing features in the backend (most are small some required bigger changes to the way we handle things, like nqp::attrinited).
While doing that I'm a…
nqp-js/rakudo.js is now targeting ECMAScript 6
Scott McWhirter helped a ton with the transitions (as well as with some general cleanup).
Most of the modern browsers now support ECMAScript 6 so I feel it makes sense to target it.
When targeting old ones that don't we can use polyfills and compilers from ECMAScript 6 to 5.
After doing most of the obvious and promising nqp-js optimizations I'm focusing again on getting rakudo.js to work.
Before that I'm cleaning up the nqp-js code base to remove hacks that might shoot us in the back while working on rakudo.js/var/www/users/pawel_murias/index.html
Currently the focus of the work on the js backend is on making nqp-js emit code that runs at a reasonable speed (so that compiling Rakudo and its setting doesn't take eons and I can iterate on it more easily).
Being able to easily profile nqp-js code is very useful for that.
The js profilers I have tried didn't work out so well
- devtools had trouble with native modules as it runs in
- running directly inside chrome require webpacking
- node-inspector didn't support console.profile/console.profileEnd and it's interface locked up while profiling
- some other ones were bitrotted
Saving data using v8-profiler and loading it via chrome itself proved to work the best
run_profiled($what, $kind, $filename) method of the backend passed to the HLL::Compiler proved to be a good fit for hooking it up
On the MoarVM backend $kind is either 'instrumented' or 'heap'.
'instrumented' is useful for profiling CPU usage and 'heap' for memory usage.
For now I implemented only CPU profiling on the js backend so on the js backend the $kind is ignored for know.
The profiling is exposed by the --profile-compile (which profiles the compilation of the code) and --profile (which profiles the code itself) options.
node nqp-bootstrapped.js --profile-compile --profile-filename literals.cpuprofile t/nqp/001-literals.t
literals.cpuprofile can be then loaded using the developer tools in Chrome.
The first test file of which compilation I profiled was t/nqp/001-literals.t repeated 20 times.
It turned out removing some debugging leftovers cut the compilation roughly in half.
A bunch of other promising stuff I'll work on next also popped up.
Currently rakudo.js is at the point where:
node rakudo.js -e 'say "Hello World"' doesn't.
The general work-flow for that is:
- Try to compile the setting with rakudo.js.
- While rakudo.js is compiling some error appears.
- I then figure out wheter it's a result of a missing…