SS-Lisp — run Lisp in your browser (IDE + compiler + VM)
mihai.bazon.net
mihai.bazon.net
https://github.com/mishoo/ymacs/
*Edit: Nevermind, the license is at the top of every file instead of a LICENSE file. Glad to see it's BSD.
Also, I'm disappointed that he doesn't show any actual benchmarks and the skeptical side of me thinks that it would be too slow for production development. Still, very impressive, I've been wondering recently if it would be possible to get a VM fast enough for the web, and this looks like a good starting point.
EDIT: I'm also really surprised that he didn't show a whole lot of debugging workflows in the screencast, since you could easily do things like stepping with a VM.
There's no debugger yet. It would be fairly easy to step through VM instructions, but to step through source code expressions looks quite complicated. First thing I'd like to do is to have a stack frame inspector.
What's unfortunate is that even the smallest new feature can have a quite dramatic impact on speed...
I work for Mozilla, but not specifically for Firefox, but I am interested to hear which parts were much slower for Firefox. If you have any jsperf or other test cases as examples, I'd love to see them and I can report back to the Firefox guys about it.
This looks extremely impressive though, I'm glad I don't have do all this work now to see how well a VM can perform!
EDIT: I was viewing your examples in Firefox, and they seem to perform rather well. Not incredibly speedy, but they seem close to the speed shown in the video.
The program: (you can run it in the REPL; use C-S-y to paste from OS clipboard):
SS-USER> (defun sum (n) (let rec ((n n) (r 0)) (if (zerop n) r (rec (1- n) (+ r n)))))
SS-USER> (time (sum 100000))
The time spent will be displayed in the ss-output buffer.
Firefox: 6516ms Chrome: 138ms
Parsecs away... :-(
However:
(time (without-interrupts (sum 100000)))
Firefox: 376ms Chrome: 135ms
Still a lot worse than Chrome, but quite a big difference.
without-interrupts ensures that its body runs continuously. Normally we run 200 instructions of each thread, until we get to 50ms, then reschedule for later with setTimeout(0). So that's probably the reason why Chrome seems to do much better—maybe setTimeout is very expensive on FF.
There's probably things you could do in the VM to optimize performance for Firefox. If you developed the VM in Chrome, typically people optimize for it Chrome. I can usually get relatively close performance if I tweak a few things here and there for both Firefox and Chrome.
Although, I think Firefox's main performance comes from JIT-ing, which you've totally lost if your running in a VM. The above example is a loop, which would usually perform great, but you've lost the JIT. That may be a reason.