Ruby-dev summary 22435-22573

Hi all,

This is the first summary of ruby-dev ML in the year 2004.

[ruby-dev:22071] Dir.glob and Shift_JIS
[ruby-dev:22441] Re: Dir.glob and Shift_JIS

H.Yamamoto posted a patch to allow globbing file names which
includes native language characters. This patch also enhances
the performance on all platforms. Latest patch was already
committed in ruby CVS repository (dir.c rev 1.93).

[ruby-dev:22494] [ANN] YARV: Yet another Ruby VM 0.0.0-

SASADA Koichi announced his new product YARV, Yet another
Ruby Virtual Machine. This VM works as a ruby extension.
Get it from:

http://www.atdot.net/yarv/

Note that these files contain CR LF line terminators.

[ruby-dev:22503] can’t require

IWATSUKI Hiroyuki reported that statically linked ruby cannot
load any ruby extension. This bug is caused by a behavior
change of Dir.glob, introduced in [ruby-dev:22441] (see above).

The problem itself was fixed by Nobu, and at the same time he
suggested to define the order of return values of Dir.glob.
He proposed “post order”, the order equivalent to “find -depth”:

% find . -depth -print
./a/a/a
./a/a/b
./a/a/c
./a/a
./a/b
./a/c
./a
./b
./c
.

This issue is still open.

[ruby-dev:22562] Dir#inspect

Nobu.Nakada posted a patch to display path name in the return
value of Dir#inspect e.g.

% ruby -ve 'p Dir.open("/")'
ruby 1.9.0 (2004-01-11) [i686-linux]
#<Dir:/>

Matz agreed with him and the patch is incorporated.

[ruby-dev:22556] Re: [Oniguruma] change prefix
[ruby-dev:22560] [Oniguruma] M17N

Matz asked K.Kosako – the author of Oniguruma – about
multilingualization (M17N) of Oniguruma. K.Kosako replied that he
intend to merge ruby’s M17N feature/implementation after it becomes
mature, if possible.

– Minero Aoki

ruby-dev summary index:
http://i.loveruby.net/en/ruby-dev-summary.html

Minero Aoki wrote:

[ruby-dev:22494] [ANN] YARV: Yet another Ruby VM 0.0.0-

SASADA Koichi announced his new product YARV, Yet another
Ruby Virtual Machine. This VM works as a ruby extension.
Get it from:

YARV: Yet Another Ruby VM

Note that these files contain CR LF line terminators.

Very interesting and a nice way to try out a bytecode-VM core. I get
about 21% speed increase with this approach with threaded dispatch and
about 24% with direct threaded dispatch compared to Ruby 1.8.1
2003-12-22 (on cygwin) on small benchmarks. I think it’s very promising
considering the bytecode emitted can probably be optimized quite a lot
more. Intriguing!

Regards,

Robert

Robert Feldt feldt@ce.chalmers.se wrote :
[ Re: ruby-dev summary 22435-22573 ]
at Thu, 15 Jan 2004 19:55:23 +0900

Very interesting and a nice way to try out a bytecode-VM core. I get
about 21% speed increase with this approach with threaded dispatch and
about 24% with direct threaded dispatch compared to Ruby 1.8.1
2003-12-22 (on cygwin) on small benchmarks. I think it’s very promising
considering the bytecode emitted can probably be optimized quite a lot
more. Intriguing!

Yes, I can speed up only 2?% too. To improve performance more, we must
optimize method dispatch(and others).
I tried to introduce the optimization for +/-/< method dispatch, I can
get nice performance improvement about 3 times faster than
ruby interpreter.

Thanks,

···


// SASADA Koichi @ namikilab.tuat.ac.jp
//

Robert Feldt feldt@ce.chalmers.se wrote in message

Minero Aoki wrote:

[ruby-dev:22494] [ANN] YARV: Yet another Ruby VM 0.0.0-

SASADA Koichi announced his new product YARV, Yet another
Ruby Virtual Machine. This VM works as a ruby extension.
Get it from:

YARV: Yet Another Ruby VM

Note that these files contain CR LF line terminators.

Very interesting and a nice way to try out a bytecode-VM core.

It’s a very similar approach to ByteCodeRuby
(http://rubyforge.org/projects/bytecoderuby/), which also works as a
Ruby extension. BCR needs to patch Ruby slightly though - I’m
impressed Sasada-san has managed to avoid this so far.

On the plus side, BCR is much further advanced, with most of the Ruby
language implemented (the big things missing are retry, eval, threads
and various set_trace_func-style callbacks). It also has 650+ tests to
ensure that its results match Ruby’s. The next BCR release (probably
in 4-6 weeks) should be self-hosting - BCR will be capable of running
its own compilation code (which is written in Ruby) and supporting
libraries (Ruth and Test::Unit).

I get
about 21% speed increase with this approach with threaded dispatch and
about 24% with direct threaded dispatch compared to Ruby 1.8.1
2003-12-22 (on cygwin) on small benchmarks. I think it’s very promising
considering the bytecode emitted can probably be optimized quite a lot
more. Intriguing!

… on the minus side, BCR is currently slightly slower than Ruby on
average. There has been no optimisation at all so far, but it is of
course planned: YARV’s direct threaded code and specialised +
bytecodes are all listed in BCR’s todo. The release after next will
start to address performance.

From an admittedly brief glance at the code, I think it’s premature to
compare YARV and Ruby performance - for example, YARV doesn’t seem to
handle optional, scatter and block arguments when calling methods, all
of which have costs. Apologies if I’m overlooking something …

BTW thanks for the pointer to LLVM in your recent post - very
interesting!

BTW2 anyone else enjoying the glories of trying to read ruby-dev
through Babelfish or excite translation services? ‘Matsumoto Yukihiro
here’ comes through as:

‘The original going which it waits which is wide’ (Babelfish)
‘It is also as a pine. It dies and is hiro’ (excite)

Wonderful!

George Marrows wrote:

It’s a very similar approach to ByteCodeRuby
(http://rubyforge.org/projects/bytecoderuby/), which also works as a
Ruby extension. BCR needs to patch Ruby slightly though - I’m
impressed Sasada-san has managed to avoid this so far.

On the plus side, BCR is much further advanced, with most of the Ruby
language implemented (the big things missing are retry, eval, threads
and various set_trace_func-style callbacks). It also has 650+ tests to
ensure that its results match Ruby’s. The next BCR release (probably
in 4-6 weeks) should be self-hosting - BCR will be capable of running
its own compilation code (which is written in Ruby) and supporting
libraries (Ruth and Test::Unit).

[snippage]

I’m extremely lazy when it comes to reading docs embedded inside .tgz
files – I’d much rather see docs on the web.

How good are the docs, anyway? I’m especially interested in your
choice of opcodes and such. Is it practical to write an assembler
for your VM? Have you perhaps already done it?

Hal

george.marrows@ps.ge.com (George Marrows) wrote :
[ Re: ruby-dev summary 22435-22573 ]
at Sat, 17 Jan 2004 00:05:07 +0900

It’s a very similar approach to ByteCodeRuby
(http://rubyforge.org/projects/bytecoderuby/), which also works as a

That’s reason why YARV is YARV :slight_smile:

And I found some other VMs. Do you know others?

Ruby extension. BCR needs to patch Ruby slightly though - I’m
impressed Sasada-san has managed to avoid this so far.

To retrieve “yield” from c-proc, we must patch to ruby interpreter.
(or replace every block proc, ex: Array#each, IO#open, …)
But now, YARV has no function to do this.

From an admittedly brief glance at the code, I think it’s premature to
compare YARV and Ruby performance - for example, YARV doesn’t seem to
handle optional, scatter and block arguments when calling methods, all
of which have costs. Apologies if I’m overlooking something …

Yes, YARV can’t these and other many many functions.

···


// SASADA Koichi @ namikilab.tuat.ac.jp
//

Is there a central site/URL/anything about ruby VMs? Can I compile ruby
code to say JAVA VM/any other VM?

thx

···

On 0117, George Marrows wrote:

[ruby-dev:22494] [ANN] YARV: Yet another Ruby VM 0.0.0-
SASADA Koichi announced his new product YARV, Yet another
Ruby Virtual Machine. This VM works as a ruby extension.
Get it from:

YARV: Yet Another Ruby VM

It’s a very similar approach to ByteCodeRuby
(http://rubyforge.org/projects/bytecoderuby/), which also works as a
Ruby extension. BCR needs to patch Ruby slightly though - I’m
impressed Sasada-san has managed to avoid this so far.


±[ Kontra, Gergelykgergely@mcl.hu PhD student Room IB113 ]---------+

http://www.mcl.hu/~kgergely “Olyan langesz vagyok, hogy |
Mobil:(+36 20) 356 9656 ICQ: 175564914 poroltoval kellene jarnom” |
±- Magyar php mirror es magyar php dokumentacio: http://hu.php.net --+

I’m extremely lazy when it comes to reading docs embedded inside .tgz
files – I’d much rather see docs on the web.

Sorry about the lack of docs, either on or off the web. I know it’s
something that needs correcting - I’ll make sure there’s some docs
available covering internal architecture and opcodes in time for the
next release.

How good are the docs, anyway? I’m especially interested in your
choice of opcodes and such. Is it practical to write an assembler
for your VM? Have you perhaps already done it?

You create bcr bytecode by writing a kind of assembler using Ruby
method calls. For example 1+2 would be compiled as

w.ld_imm(1). # push 1 on the stack
ld_imm(2). # push 2 on the stack
call(:+, 1) # call 1’s :+ method with 1 argument

(w is a ‘writer’ object for bytecode).

But there’s no separate assembler syntax, or assembler files.

– George

It’s a very similar approach to ByteCodeRuby
(http://rubyforge.org/projects/bytecoderuby/), which also works as a

That’s reason why YARV is YARV :slight_smile:

:slight_smile:

And I found some other VMs. Do you know others?

See http://www.rubygarden.org/ruby?VirtualMachineOptions

– George

Sorry, ignore my previous mail.

···


±[ Kontra, Gergelykgergely@mcl.hu PhD student Room IB113 ]---------+

http://www.mcl.hu/~kgergely “Olyan langesz vagyok, hogy |
Mobil:(+36 20) 356 9656 ICQ: 175564914 poroltoval kellene jarnom” |
±- Magyar php mirror es magyar php dokumentacio: http://hu.php.net --+

george.marrows@ps.ge.com (George Marrows) wrote :
[ Re: rubyvm-talk (was: Re: ruby-dev summary 22435-22573) ]
at Tue, 20 Jan 2004 18:19:58 +0900

(I’ve missed this mail)

See http://www.rubygarden.org/ruby?VirtualMachineOptions

nice page, thanks :slight_smile:

active “bytecode vm” project is only BCR?

···


// SASADA Koichi @ namikilab.tuat.ac.jp
//