[urbit] A Nock Interpreter and Compiler in Common Lisp

[Burton Samograd]

Hi all,

I thought I'd share my Nock interpreter and compiler written in Common Lisp:

https://gist.github.com/burtonsamograd/29103c2dfaa67f4fd344
Running this code in Urbit on my machine takes about 30 seconds. The
executing the compiled code gets it down to about 2.5 seconds. My
interpreter takes about 154 seconds.

If anybody has any more time intensive Nock code that doesn't use jets, I'd
love to have it for more testing.

--
Burton (now ~magtul-lorsug)

[Philip Monk]

Dude, this is awesome. How close is this to a drop-in replacement for what
we've got?

Post by Burton Samograd
Hi all,
https://gist.github.com/burtonsamograd/29103c2dfaa67f4fd344
Running this code in Urbit on my machine takes about 30 seconds. The
executing the compiled code gets it down to about 2.5 seconds. My
interpreter takes about 154 seconds.
If anybody has any more time intensive Nock code that doesn't use jets,
I'd love to have it for more testing.
--
Burton (now ~magtul-lorsug)
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Curtis Yarvin]

Honestly a decrement loop is probably a perfectly adequate test of Nock
performance, as long as it doesn't assume that all atoms are short :-)

Without looking deeply, I suspect Burton's compiler works by translating
Nock to Common Lisp and using the Common Lisp compiler, so my guess would
be: not very. I would certainly kill for a Nock-to-LLVM transformation,
though it would need to be well integrated with our runtime system (see
Spec/u3.md).

Post by Philip Monk
Dude, this is awesome. How close is this to a drop-in replacement for what
we've got?

Post by Burton Samograd
Hi all,
https://gist.github.com/burtonsamograd/29103c2dfaa67f4fd344
Running this code in Urbit on my machine takes about 30 seconds. The
executing the compiled code gets it down to about 2.5 seconds. My
interpreter takes about 154 seconds.
If anybody has any more time intensive Nock code that doesn't use jets,
I'd love to have it for more testing.
--
Burton (now ~magtul-lorsug)
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Curtis Yarvin]

Not very easy to integrate into the Urbit runtime, I meant.

Not that you couldn't build an Urbit runtime based in a CL environment... but it'd be a lot of work.

Sent from my iPhone

so my guess would be: not very.

Parse error: missing context?
I'm not sure if I get what you mean here. Not very what?
Yes, it does convert to common lisp and then compiles to machine code using the common lisp compiler. Nouns are only compiled once so it doesn't kill performance at runtime; I tried a number of different caching mechanisms and found the hash table lookup gives decent performance and generality, although it really should be using a weak hash table (which is available, just not in standard common lisp).
--
Burton

Honestly a decrement loop is probably a perfectly adequate test of Nock performance, as long as it doesn't assume that all atoms are short :-)
Without looking deeply, I suspect Burton's compiler works by translating Nock to Common Lisp and using the Common Lisp compiler, so my guess would be: not very. I would certainly kill for a Nock-to-LLVM transformation, though it would need to be well integrated with our runtime system (see Spec/u3.md).

Dude, this is awesome. How close is this to a drop-in replacement for what we've got?

Post by Burton Samograd
Hi all,
https://gist.github.com/burtonsamograd/29103c2dfaa67f4fd344
Running this code in Urbit on my machine takes about 30 seconds. The executing the compiled code gets it down to about 2.5 seconds. My interpreter takes about 154 seconds.
If anybody has any more time intensive Nock code that doesn't use jets, I'd love to have it for more testing.
--
Burton (now ~magtul-lorsug)
--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
For more options, visit https://groups.google.com/d/optout.

[Curtis Yarvin]

http://eli.thegreenplace.net/2014/01/15/some-thoughts-on-llvm-vs-libjit

Yes, libjit does seem more directly suitable and probably easier to
integrate with our runtime. I'd definitely recommend a read through Spec/
u3.md (C runtime system) if you haven't already done this -- it is, to my
knowledge, completely up to date and pretty complete.

One of the main jobs of a JIT is to track hotspots, and I wouldn't worry
about that at all - I'd rely on the programmer to hint the hotspots with
~/. If it's ~/ and it doesn't have a registered jet, that's the place to
JIT. And I'd JIT on first execution, rather than waiting for metrics.
Doesn't sound like libjit performance will be a huge problem.

Yes; it might be possible with ECL (Embedded Common Lisp) but AFIAK it
still requires an external C compiler to be present to actually do the CL
compilation.
My next project is going to be playing around with libjit in C and seeing
how far I can get. It's not LLVM, but I've used it before and it's a nice
library and I think it's pretty portable. Something like that would be
much easier to integrate into the core C runtime.
--
Burton

Post by Curtis Yarvin
Not very easy to integrate into the Urbit runtime, I meant.
Not that you couldn't build an Urbit runtime based in a CL environment...
but it'd be a lot of work.
Sent from my iPhone

so my guess would be: not very.

Parse error: missing context?
I'm not sure if I get what you mean here. Not very what?
Yes, it does convert to common lisp and then compiles to machine code
using the common lisp compiler. Nouns are only compiled once so it doesn't
kill performance at runtime; I tried a number of different caching
mechanisms and found the hash table lookup gives decent performance and
generality, although it really should be using a weak hash table (which is
available, just not in standard common lisp).
--
Burton

Honestly a decrement loop is probably a perfectly adequate test of Nock
performance, as long as it doesn't assume that all atoms are short :-)
Without looking deeply, I suspect Burton's compiler works by translating
Nock to Common Lisp and using the Common Lisp compiler, so my guess would
be: not very. I would certainly kill for a Nock-to-LLVM transformation,
though it would need to be well integrated with our runtime system (see
Spec/u3.md).

Dude, this is awesome. How close is this to a drop-in replacement for what we've got?

Post by Burton Samograd
Hi all,
https://gist.github.com/burtonsamograd/29103c2dfaa67f4fd344
100.000.000
Running this code in Urbit on my machine takes about 30 seconds. The
executing the compiled code gets it down to about 2.5 seconds. My
interpreter takes about 154 seconds.
If anybody has any more time intensive Nock code that doesn't use
jets, I'd love to have it for more testing.
--
Burton (now ~magtul-lorsug)
--
You received this message because you are subscribed to the Google
Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.