4 ms·

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 ope

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.

bronzejaguar 7y ago
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
matildepark 7y ago
(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/ https://urbit.org/blog/stable-arvo/
- all2 7y ago
  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?
  - dpc_pw 7y ago
    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.
    - all2 7y ago
      So... WASM, then?

bronzejaguar 7y ago

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

matildepark 7y ago

(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/ https://urbit.org/blog/stable-arvo/

all2 7y ago
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?
- dpc_pw 7y ago
  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.
  - all2 7y ago
    So... WASM, then?