On Dec 23, 2009, at 14:18 , Justin Collins wrote: > Ryan Davis wrote: >> I'm doing a proof of concept to see if nekovm would be a good target for a >> ruby backend (I didn't see anything over the last year in the ML archives to >> that effect). I'm getting wildly different times based on how I go about >> hand-translating. I'd love some hints/tips to try to see if this POC will >> pan out or not. >> >> The goal is for a pure-OO language like ruby to translate down to neko and >> be at least as performant as MRI ruby (which is admittedly rather slow, esp >> in method dispatch). Ruby, like neko, has immediates for small integers, but >> they're pure OO, so I was boxing them in neko so I could simulate actual >> method calls (tho I wasn't using call/apply yet). The performance was >> surprising to me (from 5x faster to ~18x slower than ruby), and I'm guessing >> it is mainly due to the amount of allocations I was doing. No real profiling >> data tho (how?). >> > <snip> > > A profiler is on my wish-list. You can use neko -stats, but it doesn't tell > you about Neko function calls. > > Without commenting on the code, I don't personally see this as a viable thing > to do. Ruby's object model and scoping rules do not fit the NekoVM very well, > so you will have to build a lot of that yourself instead of being able to > take advantage of built-in functionality. In my experience, the NekoVM seem > to only be fast when you do things the way it expects. Of course, this may be > my own fault, I don't know :)
OK. Since it seems obvious that nobody is going to actually comment on the code itself... building it myself isn't that big of a deal. That's what compilers are for, right? That said, the rough (but not sanity checked) numbers I got seem to indicate that what you say has some merit; that leading too far off the beaten path of neko has some major penalty points in performance. I don't think it needs to be this way necessarily. I could have gone a more OO/VM approach and written a general purpose method dispatch that allowed for immediate fixnums (like ruby _and_ neko) so I could get the benefits of neko's built in immediates, but emulate a pure OO approach for them. I haven't gone that direction in neko yet so I don't know what the pros/cons are yet. Still not sure if I should bother at this stage. *shrug* -- Neko : One VM to run them all (http://nekovm.org)
