Ryan Davis a écrit :
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?). I'm sure in some places I'm just missing the point and could use a nudge. // fib.neko: puts = function(o) { $print(o); $print("\n") } // minimal boxing function O = function(v) { switch $typeof(v) { $tint => { var o = $new(Integer) o.value = v o
Try instead a $new(IntegerProto) where IntegerProto only have "value = null" and its prototype set to "Integer", this should greatly reduce the amount of allocations since here you're copying the whole method table everytime.
Nicolas -- Neko : One VM to run them all (http://nekovm.org)
