Forum: Ruby couple quick questions about YARV

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Joshua H. (Guest)
on 2006-02-13 01:28
(Received via mailing list)
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 M. (Guest)
on 2006-02-13 06:12
(Received via mailing list)
Hi,

In message "Re: couple quick questions about YARV"
    on Mon, 13 Feb 2006 08:28:32 +0900, Joshua H.
<removed_email_address@domain.invalid> 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 (Guest)
on 2006-02-13 06:23
(Received via mailing list)
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
Yukihiro M. (Guest)
on 2006-02-13 06:33
(Received via mailing list)
Hi,

In message "Re: couple quick questions about YARV"
    on Mon, 13 Feb 2006 13:23:24 +0900, "stijn"
<removed_email_address@domain.invalid> 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.
David V. (Guest)
on 2006-02-13 06:43
(Received via mailing list)
DÅ?a Pondelok 13 Február 2006 05:32 Yukihiro M. napísal:
> Hi,
>
> In message "Re: couple quick questions about YARV"
>
>     on Mon, 13 Feb 2006 13:23:24 +0900, "stijn" <removed_email_address@domain.invalid>
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.

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 V.
Kent S. (Guest)
on 2006-02-13 06:44
(Received via mailing list)
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.
Christian N. (Guest)
on 2006-02-13 18:12
(Received via mailing list)
David V. <removed_email_address@domain.invalid> writes:

>> In message "Re: couple quick questions about YARV"
> 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*
Dirk M. (Guest)
on 2006-02-13 18:26
(Received via mailing list)
2006/2/13, Kent S. <removed_email_address@domain.invalid>:
> i = m { m{ i } + 1}
> 1000000
>
> real    0m2.376s
> user    0m2.275s
> sys     0m0.026s
>
>
> It's silly example, but it looks very impressive anyway.
>
> Kent.


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

greetings, Dirk
Joshua H. (Guest)
on 2006-02-14 08:18
(Received via mailing list)
On Feb 12, 2006, at 8:12 PM, Yukihiro M. wrote:

> [snip evidence of YARV starting faster than Ruby 1.8]
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
Ilmari H. (Guest)
on 2006-02-18 05:54
(Received via mailing list)
> 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.
gabriele renzi (Guest)
on 2006-02-19 12:29
(Received via mailing list)
Ilmari H. ha scritto:

> 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.
This topic is locked and can not be replied to.