Couple quick questions about YARV

ruby-talk
1

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

2

Hi,

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.

···

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

3

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

4

Hi,

···

In message "Re: couple quick questions about YARV" on Mon, 13 Feb 2006 13:23:24 +0900, "stijn" <stijndesaeger@gmail.com> writes:

what speed-up can realistically be expected?

YARV runs much faster on calls and basic operations. But it runs
slower on eval()'ing. Ko1 is now working on it, I think.

              matz.

5

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

6

Excellent! I'm really glad to see that.

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=286878

···

On Feb 12, 2006, at 8:12 PM, Yukihiro Matsumoto wrote:

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.

[snip evidence of YARV starting faster than Ruby 1.8]

7

Dňa Pondelok 13 Február 2006 05:32 Yukihiro Matsumoto napísal:

Hi,

>what speed-up can realistically be expected?

YARV runs much faster on calls and basic operations. But it runs
slower on eval()'ing. Ko1 is now working on it, I think.

              matz.

I wonder if that will be an incentive for people to use standard reflection
features instead of eval hacks whenever possible, the latter seem to crop out
as faster in trivial benchmarks than the former for me right now.

Is something like smalltalkish "clean" blocks being pondered to make calls
like define_method less prone to leak memory keeping local scopes from being
GCed?

David Vallner

···

In message "Re: couple quick questions about YARV" > > on Mon, 13 Feb 2006 13:23:24 +0900, "stijn" <stijndesaeger@gmail.com> writes:

8

can anyone post a benchmark using a simple eval() ?

greetings, Dirk

···

2006/2/13, Kent Sibilev <ksruby@gmail.com>:

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.

9

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

10

David Vallner <david@vallner.net> writes:

From: David Vallner <david@vallner.net>
Subject: Re: couple quick questions about YARV
To: ruby-talk@ruby-lang.org (ruby-talk ML)
Date: Mon, 13 Feb 2006 13:43:07 +0900
Reply-To: ruby-talk@ruby-lang.org
X-Mail-Count: 179643

Dňa Pondelok 13 Február 2006 05:32 Yukihiro Matsumoto napísal:

Hi,

>what speed-up can realistically be expected?

YARV runs much faster on calls and basic operations. But it runs
slower on eval()'ing. Ko1 is now working on it, I think.

              matz.

I wonder if that will be an incentive for people to use standard reflection
features instead of eval hacks whenever possible, the latter seem to crop out
as faster in trivial benchmarks than the former for me right now.

*hope*

···

In message "Re: couple quick questions about YARV" >> >> on Mon, 13 Feb 2006 13:23:24 +0900, "stijn" <stijndesaeger@gmail.com> > writes:

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

11

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.