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

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.
Ba91caa4b1fd66471e4180151b379dd7?d=identicon&s=25 Jörg W Mittag (Guest)
on 2009-04-01 01:15
(Received via mailing list)
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/Res...

The technical whitepaper is here:

  <https://SDN.SAP.Com/irj/scn/go/portal/prtroot/docs...

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.
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2009-04-01 05:13
(Received via mailing list)
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 Britt

www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (djberg96)
on 2009-04-01 07:59
(Received via mailing list)
On Mar 31, 9:12 pm, James Britt <james.br...@gmail.com> 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.
87e41d0d468ad56a3b07d9a6482fd6d5?d=identicon&s=25 Hemant Kumar (gnufied)
on 2009-04-01 10:22
(Received via mailing list)
2009/4/1 Jörg W Mittag <JoergWMittag+Usenet@googlemail.com>:
>
>
> The technical whitepaper is here:
>
>       
 <https://SDN.SAP.Com/irj/scn/go/portal/prtroot/docs...
>
> 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.
Baf83fa62a7481a08c40353795e11f44?d=identicon&s=25 Michael Neumann (Guest)
on 2009-04-01 11:15
(Received via mailing list)
hemant wrote:

>> two-way integration is totally seamless.
>> <https://SDN.SAP.Com/irj/scn/wiki?path=/display/Res...
>>
>> The technical whitepaper is here:
>>
>>
<https://SDN.SAP.Com/irj/scn/go/portal/prtroot/docs...
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
Ba91caa4b1fd66471e4180151b379dd7?d=identicon&s=25 Jörg W Mittag (Guest)
on 2009-04-01 13:05
(Received via mailing list)
James Britt 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
Aee77dba395ece0a04c688b05b07cd63?d=identicon&s=25 Daniel Berger (djberg96)
on 2009-04-01 14:02
(Received via mailing list)
Michael Neumann 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
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-04-01 14:56
(Received via mailing list)
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
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-04-01 15:01
(Received via mailing list)
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" :)

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
134ea397777886d6f0aa992672a50eaa?d=identicon&s=25 Mark Thomas (Guest)
on 2009-04-01 15:20
(Received via mailing list)
> 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.
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-04-01 15:23
(Received via mailing list)
Be MORE defensive!

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

On 02/04/2009, at 12:00 AM, Charles Oliver Nutter
<charles.nutter@sun.com
Ff9e18f0699bf079f1fc91c8d4506438?d=identicon&s=25 James Britt (Guest)
on 2009-04-01 20:01
(Received via mailing list)
Mark Thomas 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:

<snip />

Now I see why SAP consultants get the jumbo dollars.




--
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
346383adc7102ff181c69efb8c4504a4?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2009-04-02 09:14
(Received via mailing list)
On Wed, Apr 1, 2009 at 6:00 AM, Charles Oliver Nutter
<charles.nutter@sun.com> wrote:
> 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?
--
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.
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-04-02 16:15
(Received via mailing list)
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
Baf83fa62a7481a08c40353795e11f44?d=identicon&s=25 Michael Neumann (Guest)
on 2009-04-02 16:56
(Received via mailing list)
M. Edward (Ed) Borasky wrote:

> 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-r...
continuations/
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-04-02 17:06
(Received via mailing list)
On Thu, Apr 2, 2009 at 10:55 AM, Michael Neumann <mneumann@ntecs.de>
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? :)
> 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
Baf83fa62a7481a08c40353795e11f44?d=identicon&s=25 Michael Neumann (Guest)
on 2009-04-02 17:31
(Received via mailing list)
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. ;-)
>
>
> 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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2009-04-03 02:29
(Received via mailing list)
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"
<zznmeb@gmail.com> 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.
Ba91caa4b1fd66471e4180151b379dd7?d=identicon&s=25 Jörg W Mittag (Guest)
on 2009-04-21 08:45
(Received via mailing list)
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 Nutter
> <charles.nutter@sun.com> wrote:
>> 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.

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
797ef431a5e1295b56c08e1db4c8d2df?d=identicon&s=25 botp (Guest)
on 2009-04-21 13:06
(Received via mailing list)
2009/4/1 Jörg W Mittag <JoergWMittag+Usenet@googlemail.com>:
> 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
This topic is locked and can not be replied to.