Kuroko: A light-weight, embeddable bytecode VM language

[AndrewAPrice]

This is really cool. Great job!

Your web interpreter/terminal/tutorial is super polished.

I'm excited to see where you take the language and the platform.

[klange]

This is really cool. Great job!

Your web interpreter/terminal/tutorial is super polished.

I'm excited to see where you take the language and the platform.

Thanks!

At the moment I'm working through a TODO list of features I want to get into "1.1". I've added a ton of methods to the standard library, cleaned up the codebase, and have experimental support for multithreading (and without a big fat global lock, unlike CPython!); I've also been regularly dogfooding an embedded usage of the interpreter with a new version of my text editor (which was always the intent of this project). There's already a preview build of 1.1 up on the site, but the WASM build does not support threads so the biggest feature of the upcoming release isn't available yet.

I've got two things on my long-term radar now: Expanding the standard library and making Kuroko a viable sandbox environment. CPython (and Python in general, really) is notoriously problematic to sandbox, but with that in mind from an earlier stage Kuroko has a chance at doing a better job of it. Sandboxing and threading could be the killer apps that make Kuroko more than just a toy project for a toy OS and its toy editor.

[AndrewAPrice]

Sandboxing and threading could be the killer apps that make Kuroko more than just a toy project for a toy OS and its toy editor.

I agree. Threading/parallelism is one area where languages are slowly getting better. What are your thoughts on supporting promises/coroutines (async/await)?

[klange]

I haven't posted an update in a bit, and a lot has happened, so here we go:

- Threading support is very solid and I've got some multithreading tests that beat the pants off of Python even though a lot of my core bytecode is slower! I also did some actual osdev work and got the threading support working in ToaruOS with a minimal implementation thread-local storage.
- All sorts of bug fixes, new compiler features, standard library improvements, all aimed at getting 1.1 ready to be a proper production release. 1.0 was more of a proof-of-concept demo.
- I invested a lot of time into building documentation for both the C API (with Doxygen) and the standard library.
- There's a new experimental web IDE. It uses workers to run user code so it won't freeze up the browser tab on slow code or infinite loops like the current wasm repl, and it supports multiple files and a persistent IndexedDB-based filesystem, so you can set up real projects. I've enabled more of Ace's functionality, including autocomplete, so the editing experience should feel like a real IDE. There's also a little unix-y shell for the Emscripten environment*. It's still very much a work in progress - there's some bits that even have TODO blobs on them - but it's already functional to write and run code.

My current plan is to work on static analysis and debugging features to support the new web IDE (with functionality I'll hopefully also integrate into my native editor).

* Small caveat: The workers actually run in their own isolated environments, so the shell's environment isn't exactly the same; the filesystems are synced on worker startup and writes from the workers are synced when they finish.

[klange]

I've been doing a lot towards improving Kuroko's performance numbers and have finally set up a reasonable benchmark suite to compare with CPython:



There's also a new release candidate for 1.1, with a final release expected soon - if I can manage to stop making changes enough to declare it stable.

[bzt]

Nice! Could you please add micropython to the measurement mix?
It looks like your optimization was very successful, there's only one test case (read_boundmethod) you should polish further, all the others are in par with CPython. Well done!

Cheers,
bzt

[klange]

Nice! Could you please add micropython to the measurement mix?

micropython wasn't playing well with the benchmark suite, so I had to make some manual changes to support it:

Code: Select all

0.1083040237426758 read local
0.1457369327545166 read nonlocal
0.1717119216918945 read global
10.10828304290772 read builtin
1.090549945831299 read classvar
0.4275898933410645 read instancevar
1.047213077545166 read unboundmethod
2.001680850982666 read boundmethod
0.1163589954376221 write local
0.1476550102233887 write nonlocal
0.5679929256439209 write global
2.420825958251953 write classvar
0.4025170803070068 write instancevar
0.2225830554962158 fib(30)
0.1101620197296143 list append
0.5477221012115479 makeTree

(* This was run on a faster machine from the original benchmarking, but also the timing mechanism may not be as accurate due to differences in the "timeit" implementation used; I'll rerun numbers on the same machine and make a new graph tomorrow - it's quite late here.)

I ran the benchmark a couple of times, and that builtin read time is really surprising - I can't imagine builtins are really that slow to retrieve, so my guess would be Micropython is optimizing very specifically for the case where builtin functions are called while this test is dereferencing "oct" hundreds of thousands of times without calling it.

It looks like your optimization was very successful, there's only one test case (read_boundmethod) you should polish further, all the others are in par with CPython. Well done!

Allocations are the killer here! CPython's reference counting means it can easily recycle the same bound method object over and over - the test does hundreds of thousands of runs, each entailing a new allocation in Kuroko. There's a few places where CPython pulls tricks like this, like small tuples and lists. None of the other variable references involve object allocations - notably the assignment tests all assign "1" and small integer types are a primitive value stored directly in a stack reference cell in Kuroko.

[klange]

I built a new timing tool to allow micropython to join the benchmarks and ensure the numbers are fair to everyone:



CPython's major change on the "makeTree" test is because the new timing loop allows everyone to garbage collect. This is also why Kuroko has slipped a bit on the basic read tests overall.

[0b1]

Awesome work!

I am looking to do something similar, but I have not started yet.

I want to create a scripting language that looks very similar to NodeJS (OO ECMAScript) that compiles to bytecode that my OS can cooperatively multitask (and will ONLY run this bytecode - nothing else)

What advice would you give to a n00b getting ready to undertake such a project?
And/Or what lessons have you learned along the way?