Hacker News Reader

Comment by jlongster | Hacker News Reader

Ymacs (the editor he is using) is really impressive, but it really needs a license:

*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.

View on HN

Speed is acceptable in Chrome, but the gap between V8 and other JS engines is stellar. :-\ So I'm afraid it won't be too useful for production use.

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...

If you track the expressions when compiling, you could embed them somewhere with information about which bytecode they refer to, and all you have to do when stepping is lookup the source expression. This kind of thing does tend to touch every part of the compiler though.

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.

Well, I didn't benchmark specific parts of it, but here's a quick test (that's actually one of my favorite benchmarks now):

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.

Thanks. I'm not sure about setTimeout, I can't imagine it's slow, but it might be something with context switching.

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.

OS X Safari 5.2: 173ms (2.0 GHz i7)

He should make Ymacs available as a browser userscript, so that one can globally replace usual textarea with it.

Reply on news.ycombinator.com