Move over, Phusion, here comes the *real* Enterprise Edition!

J

Jörg W Mittag

Hi!

I just learned about another new Ruby Implementation. This one is
called "Blue Ruby" and it is developed by SAP Labs in Palo Alto.
It's – are you all sitting down? – a Ruby Implementation for the ABAP
Virtual Machine, written in ABAP.

There seem to be some similarities with MacRuby, in that Blue Ruby
attempts a very tight integration with the ABAP call stack, so that
two-way integration is totally seamless.

According to the technical whitepaper, Blue Ruby currently (as of
2009-03-27, i.e. four days ago) passes 70.2% of RubySpec (88.8%
language, 67.2% core library), which I find quite impressive. Blue
Ruby is yet another Ruby Implementation that has received a
significant development boost from RubySpec and ruby_parser. Kudos to
the Rubinius community!

You can find more information about Blue Ruby here:

<https://SDN.SAP.Com/irj/scn/wiki?path=/display/Research/BlueRuby>

The technical whitepaper is here:

<https://SDN.SAP.Com/irj/scn/go/portal/prtroot/docs/library/uuid/408a9a3b-03f9-2b10-b29c-f0a3374b19d8>

And an introductory blog entry is here:

<https://SDN.SAP.Com/irj/scn/weblogs?blog=/pub/wlg/13661>

BTW: If I counted correctly, we can soon celebrate the 30th Ruby
Implementation!

Greetings,
jwm.
 
J

James Britt

Jörg W Mittag said:
BTW: If I counted correctly, we can soon celebrate the 30th Ruby
Implementation!


What defines an implementation? 70% or more of RubySpec?

All these Ruby VM projects are great, but if I can't run arbitrary Ruby
code with high expectations of success, then "implementation" may not be
the right word.

Charlie Nutter of JRuby fame has a good blog post on the topic:

http://blog.headius.com/2009/03/on-benchmarking.html



--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
 
D

Daniel Berger

What defines an implementation? =A070% or more of RubySpec?

All these Ruby VM projects are great, but if I can't run arbitrary Ruby
code with high expectations of success, then "implementation" may not be
the right word.

Sucker.
 
H

hemant

2009/4/1 J=F6rg W Mittag said:
Hi!

I just learned about another new Ruby Implementation. This one is
called "Blue Ruby" and it is developed by SAP Labs in Palo Alto.
It's=A0=96 are you all sitting down?=A0=96 a Ruby Implementation for the = ABAP
Virtual Machine, written in ABAP.

There seem to be some similarities with MacRuby, in that Blue Ruby
attempts a very tight integration with the ABAP call stack, so that
two-way integration is totally seamless.

According to the technical whitepaper, Blue Ruby currently (as of
2009-03-27, i.e. four days ago) passes 70.2% of RubySpec (88.8%
language, 67.2% core library), which I find quite impressive. Blue
Ruby is yet another Ruby Implementation that has received a
significant development boost from RubySpec and ruby_parser. Kudos to
the Rubinius community!

You can find more information about Blue Ruby here:

=A0 =A0 =A0 =A0<https://SDN.SAP.Com/irj/scn/wiki?path=3D/display/Research= /BlueRuby>

The technical whitepaper is here:

=A0 =A0 =A0 =A0<https://SDN.SAP.Com/irj/scn/go/portal/prtroot/docs/librar= y/uuid/408a9a3b-03f9-2b10-b29c-f0a3374b19d8>

And an introductory blog entry is here:

=A0 =A0 =A0 =A0<https://SDN.SAP.Com/irj/scn/weblogs?blog=3D/pub/wlg/13661=


BTW: If I counted correctly, we can soon celebrate the 30th Ruby
Implementation!

It must be an April fool joke. If a new implementation doesn't
accompany screaming benchmark numbers reported by antoniocangiano, its
vaporware. It doesn't exist. Forget about it.
 
M

Michael Neumann

hemant said:
<https://SDN.SAP.Com/irj/scn/go/portal/prtroot/docs/library/uuid/408a9a3b-03f9-2b10-
b29c-f0a3374b19d8>

It must be an April fool joke. If a new implementation doesn't
accompany screaming benchmark numbers reported by antoniocangiano, its
vaporware. It doesn't exist. Forget about it.

It's not an April fool! The information came up a lot earlier than today,
it's just that the posting was very unluckily timed :). Read the whitepaper
and you'll notice that it's "real".

Regards,

Michael
 
J

Jörg W Mittag

James said:
What defines an implementation? 70% or more of RubySpec?

Sorry, that was some unfortunate wording on my part. Well, more than
unfortunate, just plain stupid, considering that just a few hours
before that, I argued that calling MacRuby "the fastest Ruby
Implementation" was wrong, because unless it passes the RubySpec
suite, it ain't a *Ruby* Implementation.

So, that's 27 (I think, in the last few months I've lost count a
little bit) projects that in some way, shape or form have once had the
goal of implementing at least a sizeable subset of Ruby, and which
have actually produced some code, design documents or similar
artifacts.

But only 3 of those (MRI, YARV and JRuby) actually fully implement
Ruby. (And actually, JRuby does not implement continuations, so
technically it's not a full Ruby Implementation either.)
All these Ruby VM projects are great, but if I can't run arbitrary Ruby
code with high expectations of success, then "implementation" may not be
the right word.

I agree. That's why I am quite positively surprised, that the Blue
Ruby project actually *runs* the RubySpec suite and publishes the
numbers. Given that Blue Ruby is a proprietary corporate project that
has been developed behind closed doors without any interaction with
the larger Ruby and Ruby implementers community, I'm quite pleased
with the emphasis on being a first class Ruby citizen, and generally
doing the right thing wrt. the "Rubyness" of the implementation.

Running the RubySpecs is unfortunately *not* something that is the
norm for Ruby Implementations. Some noteable implementations that do
(or at least did, last time I checked) *not* run the RubySpecs include
MRI and YARV, for example. Anybody remember MRI 1.8.7?

jwm
 
D

Daniel Berger

Michael said:
It's not an April fool! The information came up a lot earlier than today,
it's just that the posting was very unluckily timed :). Read the whitepaper
and you'll notice that it's "real".

Regards,

Michael

I thought it was an April Fool's joke because all the links are dead to me:

Error code: ssl_error_bad_cert_domain

Regards,

Dan
 
C

Charles Oliver Nutter

hemant said:
It must be an April fool joke. If a new implementation doesn't
accompany screaming benchmark numbers reported by antoniocangiano, its
vaporware. It doesn't exist. Forget about it.

LOL

- Charlie
 
C

Charles Oliver Nutter

J=C3=B6rg W Mittag said:
But only 3 of those (MRI, YARV and JRuby) actually fully implement
Ruby. (And actually, JRuby does not implement continuations, so
technically it's not a full Ruby Implementation either.)

Well, according to the earliest drafts of the Ruby standard,=20
continuations are not part of "core Ruby" :)

But yes, this is one area we've opted not to be compatible in exchang=
e=20
for performance. We could implement continuations, but we'd be severa=
l=20
times slower as a result.
I agree. That's why I am quite positively surprised, that the Blue
Ruby project actually *runs* the RubySpec suite and publishes the
numbers. Given that Blue Ruby is a proprietary corporate project th= at
has been developed behind closed doors without any interaction with
the larger Ruby and Ruby implementers community, I'm quite pleased
with the emphasis on being a first class Ruby citizen, and generall= y
doing the right thing wrt. the "Rubyness" of the implementation.
=20
Running the RubySpecs is unfortunately *not* something that is the
norm for Ruby Implementations. Some noteable implementations that d= o
(or at least did, last time I checked) *not* run the RubySpecs incl= ude
MRI and YARV, for example. Anybody remember MRI 1.8.7?

I agree...I was also impressed that BlueRuby talked first about=20
compatibility, and barely mentioned performance in any of their=20
postings. That's very impressive.

It's also worth mentioning that though you're right, all the major Ru=
by=20
impls try to run RubySpec in some form, there are those that have a=
=20
different path. Tinyrb would probably only be able to run a subset, a=
nd=20
can't run any right now (I believe, correct me if I'm wrong). My=20
stripped down JRuby for JavaME doesn't run them yet, though I hope to=
=20
identify a subset it can run. And MacRuby didn't run RubySpecs at all=
=20
until recently, but they've started to both run them and update them =
for=20
1.9 behavior.

- Charlie
 
M

Mark Thomas

I thought it was an April Fool's joke because all the links are dead to me:

Well, it's not an April Fool's joke, but the whitepaper certainly had
me laughing. For example, here's how to call out to Blue Ruby to
calculate 7+3:

Report ZABAP_RUBY.

data: BLUERUBY type ref to /SRUBY/IF_BLUERUBY,
FIXNUM1 type ref to /SRUBY/CL_OBJECT,
FIXNUM2 type ref to /SRUBY/CL_OBJECT,
RESULT type ref to /SRUBY/CL_OBJECT,
ABAP_RESULT type I.

create object BLUERUBY type /SRUBY/CL_BLUERUBY_FACADE.
FIXNUM1 = BLUERUBY->CONVERT_ABAP2RUBY( 7 ).
FIXNUM2 = BLUERUBY->CONVERT_ABAP2RUBY( 3 ).
RESULT = BLUERUBY->CALL_METHOD(
METHOD_NAME = '+'
RUBY_RECEIVER_OBJECT = FIXNUM1
ARGUMENT1 = FIXNUM2 ).
call method BLUERUBY->CONVERT_RUBY2ABAP
exporting
RUBY_OBJECT = RESULT
importing ABAP_DATA = ABAP_RESULT.
write: 'Blue Ruby thinks that 7 + 3 = ', ABAP_RESULT.
 
J

Julian Leviston

M

M. Edward (Ed) Borasky

Well, according to the earliest drafts of the Ruby standard, continuations
are not part of "core Ruby" :)

But yes, this is one area we've opted not to be compatible in exchange for
performance. We could implement continuations, but we'd be several times
slower as a result.

IIRC YARV also dropped continuations because they would be slow on the
YARV VM as well.

Which does raise an interesting point, though. Call/cc has been
standard equipment on Scheme for years and nobody has complained about
performance. How did Ruby manage to paint itself into a "slow
continuation" corner?
 
C

Charles Oliver Nutter

M. Edward (Ed) Borasky said:
IIRC YARV also dropped continuations because they would be slow on the
YARV VM as well.

Which does raise an interesting point, though. Call/cc has been
standard equipment on Scheme for years and nobody has complained about
performance. How did Ruby manage to paint itself into a "slow
continuation" corner?

I think it's a matter of how much Ruby has to save to support
continuations. The C stack, its own Ruby stack, and so on all have a
higher cost than what e.g. Scheme would need to save.

But I'm no expert on how continuations are implemented in either Ruby or
Scheme...

- Charlie
 
M

Michael Neumann

M. Edward (Ed) Borasky said:
IIRC YARV also dropped continuations because they would be slow on the
YARV VM as well.

Which YARV do you mean? The one integrated into Ruby 1.9? :)
So I know for sure that Ruby 1.9 still has continuations, that they rule the
world when compared against Ruby 1.8 continuations (which had memory leaks),
and that Ruby 1.9 it is based on Koichi's YARV. ;-)

ruby19 -rcontinuation -e 'callcc {|cc|$cc=cc}; p "Hallo Welt"; $cc.call'
Which does raise an interesting point, though. Call/cc has been
standard equipment on Scheme for years and nobody has complained about
performance. How did Ruby manage to paint itself into a "slow
continuation" corner?

Continuations in Ruby before 1.9 were mainly slow because they leaked
memory. The GC turned the whole program into a slow program. This is no
longer the case. I did some tests with my continuation-based web framework
Wee here [1] (both with Ruby 1.8 and 1.9).

Regards,

Michael

[1]: http://www.ntecs.de/blog/articles/2009/02/25/wee-ruby-1-9-and-
continuations/
 
R

Rick DeNatale

[Note: parts of this message were removed to make it a legal post.]

Which YARV do you mean? The one integrated into Ruby 1.9? :)
So I know for sure that Ruby 1.9 still has continuations, that they rule
the
world when compared against Ruby 1.8 continuations (which had memory
leaks),
and that Ruby 1.9 it is based on Koichi's YARV. ;-)


IIRC (sometimes hard to do at my age) continuations were gone from Ruby 1.9
for a while back in 1997, but came back before the Ruby 1.9.0 release around
Christmas 2007.

As for implementation, I think that the spaghetti stack design which Evan
Phoenix is/was? using in Rubinius, (which is similar to what the Squeak
Smalltalk VM uses) helps a lot. On the other hand, Seaside, which drove a
lot of interest in continuations in the Smaltalk community, feeding back to
Rubyists who wanted to emulate Seaside, has rather drastically reduced, but
not eliminated, the use of continuations.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
 
M

Michael Neumann

Rick said:
IIRC (sometimes hard to do at my age) continuations were gone from Ruby
1.9 for a while back in 1997, but came back before the Ruby 1.9.0 release
around Christmas 2007.

Getting older (but still young enough to remember), in 1998 I was using Ruby
version 1.2.4, far far away from anything near 1.9 :). Though, I can't say
for sure what happend one year before in 1997 ;-)
As for implementation, I think that the spaghetti stack design which Evan
Phoenix is/was? using in Rubinius, (which is similar to what the Squeak
Smalltalk VM uses) helps a lot. On the other hand, Seaside, which drove a
lot of interest in continuations in the Smaltalk community, feeding back
to Rubyists who wanted to emulate Seaside, has rather drastically reduced,
but not eliminated, the use of continuations.

Yes, the spaghetti stack of Rubinius would have helped continuations a lot
(at least theoretically), but AFAIK it's gone in favor of performance of the
C stack.

Funny that Seaside is reducing continuations while I am increasing or
"stabilizing" continuation support in my Seaside-inspired framework Wee, due
to the fact that continuations became pretty stable in Ruby 1.9.

Regards,

Michael
 
J

Jörg W Mittag

I'm three weeks late, but I just *had* to drop my 2 cents here ...

M. Edward (Ed) Borasky said:
IIRC YARV also dropped continuations because they would be slow on the
YARV VM as well.

They are still there, just no longer in the core library. They have
been "downgraded" to the stdlib. They *had been* removed for a pretty
long period of time, but they reappeared. In fact, for almost two
years, it was actually said to be *impossible* to implement them on
YARV, but then without much fanfare, the continuation library appeared
in a CVS commit.
Which does raise an interesting point, though. Call/cc has been
standard equipment on Scheme for years and nobody has complained about
performance. How did Ruby manage to paint itself into a "slow
continuation" corner?

I don't think the problem is Ruby. The problem is the implementations.
You can implement continuations really really slow in Scheme, too, if
you only implement it badly enough. And there is a lot of bad Scheme
implementations out there.

In MRI, continuations are slow (and apparently they leak memory like
there's no tomorrow), because MRI is, quite frankly, a bad
implementation. Continuations are only one example; the garbage
collector, the extension API, the (non-existent) FFI, the fact that
concurrency isn't actually concurrent, are others. And Matz himself
has made it very clear that he does not consider MRI to be a good
implementation, he has always pointed out that he is primarily a
language designer and not necessarily a programmer and *definitely*
not a VM guru.

In YARV, continuations are faster and the memory leaks are plugged,
but they aren't really fast, either. In this case, it's a design
decision: they weren't *meant* to be fast, indeed, they weren't meant
to implemented *at all*.

And JRuby, well, to paraphrase Clojure's Rich Hickey (he was talking
about tail calls, but it applies equally to continuations): "Java
interoperability. High performance. Continuations. Pick any two." This
applies not only to continuations and tail calls but really
*everything* that doesn't fit the linear call stack paradigm (like
coroutines). And it also doesn't only apply to Java, but also to .NET
and even C.

The problem arises when you want to implement advanced control flow
constructs on execution engines that don't support them natively.
Basically, all you need to implement advanced control flow is either
continuations or reified call stacks. Java has neither. So, you are
left with a couple of choices: use continuation-passing-style,
implement your own stack or use exceptions for control flow. Or, well,
just give up. CPS and managing your own stack both mean that you are
no longer call stack compatible with Java, which complicates (and
slows down) Java interop. Using exceptions isn't really performant,
although exceptions are much faster on Java than people give them
cedit for, but this particular usage pattern doesn't fit with the
optimizations.

JRuby and IronRuby chose to emphasize performance and interop and
sacrifice continuations. Even Rubinius is currently converting from a
self-managed spaghetti stack to just the plain C stack, even though
that severely complicates Rubinius's distinctive "stackless" features
like reified stack frames, lightweight tasks, continuations, actors
and threads, and embeddability and multi-VM. One of the reasons is
again interop, this time with C (FFI).

The Parrot VM on the other hand, has continuations as its *only*
control flow mechanism built deeply into the VM. Squeak has reified
stack frames, thus allowing Seaside to implement continuations in the
library, even though Squeak doesn't support them. I suspect similar
things might be true for MagLev, especially since they are actually
willing to change the VM to fit Ruby.

jwm
 
B

botp

2009/4/1 J=F6rg W Mittag said:
I just learned about another new Ruby Implementation. This one is
called "Blue Ruby" and it is developed by SAP Labs in Palo Alto.

great project. i hope it continues. it will show the scalability of
the ruby language.

weird though; i didn't get this from piers hardings blog...

thank you and kind regards -botp
 

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top