Hacker News Reader

Comment by pickdenis | Hacker News Reader

Does anyone know how Urbit's solving the problem of being incredibly slow? It's running on a naively simple virtual machine and they claim that higher level operations can be abstracted and implemented in native code (called jets last time I heard) to make the overall execution time reasonable.

Or, alternatively: Does anyone even actually use urbit? I tried once and it was so god damn slow it made me sad. It's so cool.

View on HN

(Obvious disclosure that I work on the project.) Slow, like, literally the VM is slow? There's infrastructure work being done to rewrite the VM at the moment, though there's been some major work in the last six months on this front as well that personally have felt like night and day. Slow, like, the network is slow? There's an update going out shortly with a rewrite for Ames that makes it a bit easier to work on. There's a good blog post [1] our CTO put out on how the infrastructure cost this year has been predominantly on planning a very resilient stack, rewriting a lot of archaic code to be easier to modify by more than just a handful of kernel engineers, more pliant. I feel pretty confident about the performance in future.

[1]: https://urbit.org/blog/stable-arvo/

I'm curious: why reinvent the VM "wheel"? Why is LLVM inadequate? Or any other VM?

More specifically, what functionality does Urbit require that makes a bespoke VM necessary?

Many reasons. The VM is minimal, has a precise mathematical spec and is tailored to be a base for a purely-functional OS. The details of the VM are usable in the higher layer. It's more like a Lisp-machine, than LLVM.

So... WASM, then?

It’s way faster than it used to be (about 10x). I’m interested in knowing the progress of their new JIT interpreter, because they claim that’s giving them another 10x in internal tests

Reply on news.ycombinator.com