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


#1

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.


#2

Jörg W Mittag wrote:

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

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


#3

On Mar 31, 9:12 pm, James B. removed_email_address@domain.invalid wrote:

Jörg W Mittag wrote:

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.

Sucker.


#4

2009/4/1 Jörg W Mittag removed_email_address@domain.invalid:

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!

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.


#5

James B. wrote:

Jörg W Mittag wrote:

BTW: If I counted correctly, we can soon celebrate the 30th Ruby
Implementation!
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


#6

hemant wrote:

two-way integration is totally seamless.
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>

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


#7

hemant wrote:

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

#8

Michael N. wrote:

There seem to be some similarities with MacRuby, in that Blue Ruby
You can find more information about Blue Ruby here:
https://SDN.SAP.Com/irj/scn/weblogs?blog=/pub/wlg/13661

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


#9

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.


#10

Be MORE defensive!

Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/

On 02/04/2009, at 12:00 AM, Charles Oliver N.
<removed_email_address@domain.invalid


#11

Mark T. wrote:

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:

Now I see why SAP consultants get the jumbo dollars.


James B.

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


#12

Jörg W Mittag wrote:

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,
continuations are not part of “core Ruby” :slight_smile:

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.

(or at least did, last time I checked) not run the RubySpecs include
MRI and YARV, for example. Anybody remember MRI 1.8.7?

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

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

  • Charlie

#13

On Wed, Apr 1, 2009 at 6:00 AM, Charles Oliver N.
removed_email_address@domain.invalid wrote:

Well, according to the earliest drafts of the Ruby standard, continuations
are not part of “core Ruby” :slight_smile:

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?

M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I’ve never met a happy clam. In fact, most of them were pretty steamed.


#14

M. Edward (Ed) Borasky wrote:

YARV VM as well.
Which YARV do you mean? The one integrated into Ruby 1.9? :slight_smile:
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. :wink:

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

continuations/


#15

M. Edward (Ed) Borasky wrote:

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

#16

Rick DeNatale wrote:

But yes, this is one area we’ve opted not to be compatible in exchange
leaks),
and that Ruby 1.9 it is based on Koichi’s YARV. :wink:

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 :wink:

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


#17

On Thu, Apr 2, 2009 at 10:55 AM, Michael N. removed_email_address@domain.invalid
wrote:

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? :slight_smile:
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. :wink:

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


#18

Hi,

In message “Re: Move over, Phusion, here comes the real Enterprise
Edition!”
on Thu, 2 Apr 2009 16:13:46 +0900, “M. Edward (Ed) Borasky”
removed_email_address@domain.invalid writes:

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

It’s not for the performance, but for various problems it can cause,
especially when continuation reenters into C function. Actually
continuations are still available if continuation library is required.

          matz.

#19

2009/4/1 Jörg W Mittag removed_email_address@domain.invalid:

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


#20

I’m three weeks late, but I just had to drop my 2 cents here …

M. Edward (Ed) Borasky wrote:

On Wed, Apr 1, 2009 at 6:00 AM, Charles Oliver N.
removed_email_address@domain.invalid wrote:

Well, according to the earliest drafts of the Ruby standard, continuations
are not part of “core Ruby” :slight_smile:

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.

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