couple quick questions about YARV

[Joshua Haberman]

I know YARV is far from finished, but:

1. any idea what the up-front cost for starting up YARV will be? I'm
just hoping we won't see 1 second of disk churn that we've come to
expect from the JVM.

2. will existing Ruby extensions continue to work?

Josh

 

[Yukihiro Matsumoto]

Hi,

In message "Re: couple quick questions about YARV"

|1. any idea what the up-front cost for starting up YARV will be? I'm
|just hoping we won't see 1 second of disk churn that we've come to
|expect from the JVM.

% ruby1.8 -ve 0
ruby 1.8.4 (2005-12-24) [i486-linux]
-e:1: warning: useless use of a literal in void context

real 0m0.009s
user 0m0.004s
sys 0m0.001s

% ruby.yarv -ve 0
ruby 1.9.0 (2006-02-09) [i686-linux]
YARVCore 0.3.3 (rev: 389) [opts: ]
warning: useless use of a literal in void context

real 0m0.006s
user 0m0.004s
sys 0m0.001s


|2. will existing Ruby extensions continue to work?

Currently, yes. No promise for the future.


matz.

 

[stijn]

Not to hijack the OP's thread, but a follow-up question:

what speed-up can realistically be expected? I 've seen Koichi's slides
and they look impressive but if I am not mistaken the optimizations
looked to be concerned with basic math operations and so on. what about
function calls / blocks / object instantiations / hash and array
implementation / .... ? Is YARV going to muscle those around as well,
or not really?
if so (or if not), what performance improvements would be within reach?


thanks,
stijn

 

[Kent Sibilev]

I've just tried:

$ cat bm.rb
def m
yield
end

i =3D 0
1000000.times do
i =3D m { m{ i } + 1}
end

puts i
$ time ruby bm.rb
1000000

real 0m11.721s
user 0m9.927s
sys 0m0.081s
$ time ruby.yarv bm.rb
1000000

real 0m2.376s
user 0m2.275s
sys 0m0.026s


It's silly example, but it looks very impressive anyway.

Kent.

 

[Ilmari Heikkinen]

PiBGb3IgYSBzbGlnaHRseSBtb3JlIHJhZGljYWwgcXVlc3Rpb246IGFyZSB0aGVyZSBhbnkgbG9u
Zy10ZXJtIHBsYW5zCj4gdG8gcmV2aXNpdCB0aGUgZ2FyYmFnZS1jb2xsZWN0aW9uIHN0cmF0ZWd5
PyAgRm9yIGludGVyYWN0aXZlCj4gcHJvZ3JhbXMsIGl0IGlzIHJlYWxseSB1bmRlc2lyYWJsZSB0
byBoYXZlIHRoZSB3aG9sZSBwcm9ncmFtIGxvY2sgdXAKPiBmcm9tIHRpbWUgdG8gdGltZSAod2hp
bGUgdGhlIGdhcmJhZ2UgY29sbGVjdG9yIHJ1bnMpLiAgSSBrbm93IEphdmEKPiBoYXMgaW1wbGVt
ZW50ZWQgc29tZSBhbHRlcm5hdGl2ZSBnYXJiYWdlIGNvbGxlY3Rpb24gYWxnb3JpdGhtcyB0bwo+
IHN1cHBvcnQgbW9yZSByZWFsLXRpbWUgdXNlLiAgQW5kIHRoZXJlIGhhdmUgYmVlbiBzb21lIHBh
cGVycwo+IHB1Ymxpc2hlZCBhYm91dCBtdWx0aXRocmVhZGVkIGdhcmJhZ2UgY29sbGVjdGlvbiAo
bGlrZSBbMF0pCj4KPiBUaG91Z2h0cz8KPgo+IEpvc2gKPgo+IFswXSBodHRwOi8vcG9ydGFsLmFj
bS5vcmcvY2l0YXRpb24uY2ZtP2lkPTI4Njg3OAoKV2F5IHRvIGRvIHBhcnRpYWwgdGltZS1saW1p
dGVkIEdDIHJ1bnMgd291bGQgYmUgbmljZSwgYnV0IG5vIGlkZWEgYWJvdXQKZmVhc2liaWxpdHku
IFJ1biBHQyBmb3IgMm1zLCB0aGVuIGRvIG1vcmUgc3R1ZmYsIGFuZCB3aGVuIGFsbG9jIGxpbWl0
IGhpdCwKcnVuIEdDIGZvciAybXMgYWdhaW4uIEEgc2luZ2xlIDIwbXMgR0MgcnVuIGlzIGEgdmlz
aWJsZSBnbGl0Y2gsIGJ1dAp0d2VudHkgMm1zIHJ1bnMgc3ByZWFkIG92ZXIgdHdlbnR5IGZyYW1l
cyBpcyBwcmFjdGljYWxseSBpbnZpc2libGUuCg==

 

[gabriele renzi]

Ilmari Heikkinen ha scritto:

Thoughts?

Josh

[0] http://portal.acm.org/citation.cfm?id=286878

Way to do partial time-limited GC runs would be nice, but no idea about
feasibility. Run GC for 2ms, then do more stuff, and when alloc limit hit,
run GC for 2ms again. A single 20ms GC run is a visible glitch, but
twenty 2ms runs spread over twenty frames is practically invisible.

I think the easier way would be, again, to integrate Bohem's GC, which
claims incrementality, but matz tryed it many years ago and I recall he
was'nt satisfied (search ruby-talk for details). Maybe things are changed.