Asp Forum - couple quick questions about YARV

Joshua Haberman

2/12/2006 11:29:00 PM

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

5 Answers

Yukihiro Matsumoto

2/13/2006 4:12:00 AM

Hi,

In message "Re: couple quick questions about YARV"
on Mon, 13 Feb 2006 08:28:32 +0900, Joshua Haberman <joshua@reverberate.org> writes:

|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

2/13/2006 4:21:00 AM

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

2/13/2006 4:44:00 AM

I've just tried:

$ cat bm.rb
def m
yield
end

i = 0
1000000.times do
i = 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.

On 2/12/06, stijn <stijndesaeger@gmail.com> wrote:
> 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
>
>
>

Ilmari Heikkinen

2/18/2006 3:54:00 AM

> For a slightly more radical question: are there any long-term plans> to revisit the garbage-collection strategy? For interactive> programs, it is really undesirable to have the whole program lock up> from time to time (while the garbage collector runs). I know Java> has implemented some alternative garbage collection algorithms to> support more real-time use. And there have been some papers> published about multithreaded garbage collection (like [0])>> Thoughts?>> Josh>> [0] http://portal.acm.org/citation.cfm?id... to do partial time-limited GC runs would be nice, but no idea aboutfeasibility. 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, buttwenty 2ms runs spread over twenty frames is practically invisible.

gabriele renzi

2/19/2006 10:23:00 AM

Ilmari Heikkinen ha scritto:

>>Thoughts?
>>
>>Josh
>>
>>[0] http://portal.acm.org/citation.cfm...
>
>
> 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.

comp.lang.ruby