Asp Forum - Re: Seven new VMs, all in a row

flaig

4/8/2005 9:42:00 AM

Yeah, I'm curious about that too... a couple of years ago I wrote a Python-2-native compiler but was very disappointed to find that it revved up things only 2x to 3x (to less than 1/10 the speed of C code), the matter obviously being that Python's way of object handling already consumed most of the CPU time. Obviously, the need for endless type checks, comparisons and conversions, not to mention memory allocation and deallocation, is a bottleneck, at least in Python -- and though I am not really familiar with the internals of the Ruby interpreter, I think that the problem will be pretty much the same. Also in Smalltalk. So there must really be some fundamental stroke of genius involved....
And if so, what about incorporating this into Ruby 2.x one day? :-)

-- Ruediger Marcus

Am Freitag, 8. April 2005 04:14 schrieb Phil Tomson:
> In article <1112914652.066124.91370@g14g2000cwa.googlegroups.com>,
>
> Avi Bryant <avi.bryant@gmail.com> wrote:
> >Peter Suk wrote:
> >> Hello everyone,
> >>
> >> I thought I'd talk about my new project here, since there is a good
> >> chance that someone might be interested in it. I'm planning to put
> >> Ruby on top of Smalltalk VMs.
> >
> >Hi Peter,
> >
> >I'm definitely interested in this; please keep me posted. Actually, a
> >couple of people are aware that I was looking into the possibility of
> >doing this as a commercial product - since, from my benchmarking, we
> >can get about a 20x to 30x speed increase by hosting Ruby on a
> >commercial Smalltalk VM like VisualWorks, it seemed like it might be
>
> This "20x to 30x speed increase" stuff is interesting. I would have
> thought it would be closer to something like 5x. Can anyone elaborate on
> how those increases are being acheived in the SmallTalk VMs? I'm wondering
> if it might also be worthwhile to incorporate some of these ideas into YARV
> - parhaps that would get us to high-speed Ruby even faster than trying to
> put Ruby on top of a SmallTalk VM?
>
> Phil

--
Chevalier Dr Dr Ruediger Marcus Flaig
Institute for Immunology
University of Heidelberg
INF 305, D-69121 Heidelberg

"Drain you of your sanity,
Face the Thing That Should Not Be."

--
Diese E-Mail wurde mit http://www.mail-in... verschickt
Mail Inspector ist ein kostenloser Service von http://www....
Der Absender dieser E-Mail hatte die IP: 129.206.124.135

23 Answers

Peter Suk

4/8/2005 10:09:00 AM

On Apr 8, 2005, at 4:41 AM, flaig@sanctacaris.net wrote:

> Yeah, I'm curious about that too... a couple of years ago I wrote a
> Python-2-native compiler but was very disappointed to find that it
> revved up things only 2x to 3x (to less than 1/10 the speed of C
> code), the matter obviously being that Python's way of object handling
> already consumed most of the CPU time.

Reference counting GC, isn't it? That automatically raises your
assignment overhead 2X.

> Obviously, the need for endless type checks, comparisons and
> conversions, not to mention memory allocation and deallocation, is a
> bottleneck, at least in Python -- and though I am not really familiar
> with the internals of the Ruby interpreter, I think that the problem
> will be pretty much the same. Also in Smalltalk.

Generational GC. (So you're not at the mercy of the system's malloc &
free) JIT. Implementing message sends as direct jumps for monomorphic
methods. (& polymorphic methods with a caching strategy.) Call chain
optimization. Those are the ones I know about. Not all Smalltalks use
them.

> So there must really be some fundamental stroke of genius involved....
> And if so, what about incorporating this into Ruby 2.x one day? :-)

As far as I am concerned, this project is a rehearsal for the
appearance of Ruby 2.x.

--Peter

--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.

Charles Mills

4/8/2005 5:37:00 PM

Peter Suk wrote:
> On Apr 8, 2005, at 4:41 AM, flaig@sanctacaris.net wrote:
>
> > Yeah, I'm curious about that too... a couple of years ago I wrote a

> > Python-2-native compiler but was very disappointed to find that it
> > revved up things only 2x to 3x (to less than 1/10 the speed of C
> > code), the matter obviously being that Python's way of object
handling
> > already consumed most of the CPU time.
>
> Reference counting GC, isn't it? That automatically raises your
> assignment overhead 2X.

and breaks all existing extensions, unless you have special compiler
support.

> > Obviously, the need for endless type checks, comparisons and
> > conversions, not to mention memory allocation and deallocation, is
a
> > bottleneck, at least in Python -- and though I am not really
familiar
> > with the internals of the Ruby interpreter, I think that the
problem
> > will be pretty much the same. Also in Smalltalk.
>
> Generational GC. (So you're not at the mercy of the system's malloc
&
> free)

A generational GC would be great. There has been talk of including one
in the next version of the Ruby interpreter. However C extensions also
pose a problem here as well - it seems creating a write barrier that
works with C libraries not written originally with Ruby in mind will be
very difficult/slow.

-Charlie

> JIT. Implementing message sends as direct jumps for monomorphic
> methods. (& polymorphic methods with a caching strategy.) Call
chain
> optimization. Those are the ones I know about. Not all Smalltalks
use
> them.
>
> > So there must really be some fundamental stroke of genius
involved....
> > And if so, what about incorporating this into Ruby 2.x one day? :-)
>
> As far as I am concerned, this project is a rehearsal for the
> appearance of Ruby 2.x.
>
> --Peter
>
>
> --
> There's neither heaven nor hell, save what we grant ourselves.
> There's neither fairness nor justice, save what we grant each other.

Peter Suk

4/8/2005 6:10:00 PM

On Apr 8, 2005, at 12:39 PM, Charles Mills wrote:

> Peter Suk wrote:
>> Generational GC. (So you're not at the mercy of the system's malloc
> &
>> free)
>
> A generational GC would be great. There has been talk of including one
> in the next version of the Ruby interpreter. However C extensions also
> pose a problem here as well - it seems creating a write barrier that
> works with C libraries not written originally with Ruby in mind will be
> very difficult/slow.

VisualWorks gets around this and also solves problems the paradox with
not having "real" threads, wanting to do GC efficently, yet also
wanting to do synchronous calls to the OS. The dilemma is this: You
want real threads so your VM can utilize synchronous calls to the OS.
However, this complicates GC immensely. (ObjectStudio Smalltalk lost a
lot of performance because of having real threads. When it was time to
GC, the main VM thread would have to raise a flag and wait for all the
other threads to detect it.)

VisualWorks can use real threads, but only in the case of calling out
to a DLL, and these contexts are exempt from GC. This gives you the
ability to make synchronous calls without freezing the entire image,
yet also leaves your GC simple and fast.

--Peter

--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.

Lothar Scholz

4/8/2005 6:26:00 PM

Hello Charles,

CM> A generational GC would be great. There has been talk of including one
CM> in the next version of the Ruby interpreter. However C extensions also
CM> pose a problem here as well - it seems creating a write barrier that
CM> works with C libraries not written originally with Ruby in mind will be
CM> very difficult/slow.

This shouldn't be a problem. As long as you don't pass ruby values
into the c libraries as 'user data' the data space can be separated
very well. If you must pass some 'user data' into the lib simply use
a proxy pointer, an keep the ruby object into a gc known address space.
A hashtable with all ruby objects referenced from the c lib is a good
idea here.

A little bit more overhead and it breaks all larger current binary
extensions, but i think we must face the fact that Ruby 2.0 will give
as a lot of code breaks anyway.

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ru...
CTO Scriptolutions Ruby, PHP, Python IDE 's

Charles Mills

4/8/2005 6:38:00 PM

Lothar Scholz wrote:
> Hello Charles,
>
> CM> A generational GC would be great. There has been talk of
including one
> CM> in the next version of the Ruby interpreter. However C
extensions also
> CM> pose a problem here as well - it seems creating a write barrier
that
> CM> works with C libraries not written originally with Ruby in mind
will be
> CM> very difficult/slow.
>
> This shouldn't be a problem. As long as you don't pass ruby values
> into the c libraries as 'user data' the data space can be separated
> very well. If you must pass some 'user data' into the lib simply use
> a proxy pointer, an keep the ruby object into a gc known address
space.
> A hashtable with all ruby objects referenced from the c lib is a good
> idea here.

I am no expert on GC's, so maybe my questions are bogus, but how would
the GC 'know' which allocated regions to put behind the write barrier?
For example with the Array class how would the GC know to put
RARRAY(ary)->ptr behind the write barrier if ary made its way into an
older generation?
Would the memory allocation api (ALLOC_N,etc) have to be changed?
Could this be determined by when the allocation was made?

>
> A little bit more overhead and it breaks all larger current binary
> extensions, but i think we must face the fact that Ruby 2.0 will give
> as a lot of code breaks anyway.
>
> --
> Best regards, emailto: scholz at
scriptolutions dot com
> Lothar Scholz http://www.ru...
> CTO Scriptolutions Ruby, PHP, Python IDE 's

Peter Suk

4/8/2005 6:50:00 PM

On Apr 8, 2005, at 1:39 PM, Charles Mills wrote:

> Lothar Scholz wrote:
>> Hello Charles,
>>
>> CM> A generational GC would be great. There has been talk of
> including one
>> CM> in the next version of the Ruby interpreter. However C
> extensions also
>> CM> pose a problem here as well - it seems creating a write barrier
> that
>> CM> works with C libraries not written originally with Ruby in mind
> will be
>> CM> very difficult/slow.
>>
>> This shouldn't be a problem. As long as you don't pass ruby values
>> into the c libraries as 'user data' the data space can be separated
>> very well. If you must pass some 'user data' into the lib simply use
>> a proxy pointer, an keep the ruby object into a gc known address
> space.
>> A hashtable with all ruby objects referenced from the c lib is a good
>> idea here.
>
> I am no expert on GC's, so maybe my questions are bogus, but how would
> the GC 'know' which allocated regions to put behind the write barrier?
> For example with the Array class how would the GC know to put
> RARRAY(ary)->ptr behind the write barrier if ary made its way into an
> older generation?
> Would the memory allocation api (ALLOC_N,etc) have to be changed?
> Could this be determined by when the allocation was made?

I am not a VM expert, but I have overheard the Smalltalk VM guys (4 of
them from different VMs in the same room!) talk about how write
barriers can be efficiently implemented by reserving special areas of
memory, choosing a certain region as your protected region, then using
pointer address comparisons.

--Peter

--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.

Glenn Parker

4/8/2005 8:05:00 PM

Peter Suk wrote:
>
> VisualWorks can use real threads, but only in the case of calling out to
> a DLL, and these contexts are exempt from GC.

Well, that's a major hole, isn't it?

And I suspect today's Ruby has pretty much the same "feature" as
VisualWorks in this regard, that is to say I could create a Ruby DLL
that spawned real threads and let them do their own memory management.

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoi...

Peter Suk

4/8/2005 9:19:00 PM

On Apr 8, 2005, at 3:04 PM, Glenn Parker wrote:

> Peter Suk wrote:
>> VisualWorks can use real threads, but only in the case of calling out
>> to a DLL, and these contexts are exempt from GC.
>
> Well, that's a major hole, isn't it?

There is clearly some kind of disconnect here. Are you expecting that
the DLL be subject to Ruby GC & memory management? Are you saying it's
some kind of "hole" that the context which is doing the call-out is not
being GC'd for the duration of the call?

Huh?

> And I suspect today's Ruby has pretty much the same "feature" as
> VisualWorks in this regard, that is to say I could create a Ruby DLL
> that spawned real threads and let them do their own memory management.

Please re-read my message. Your response doesn't make any sense at
all, especially with the 2nd sentence -- unless I am missing out on
something.

And please, stop this stupid "our X is better than yours" nonsense.
Such pride is misplaced on a particular VM/Language/paradigm. I am
here to share what the Smalltalk world has been acruing for some time,
and am prepared to go through a lot of effort to do it.

--Peter

--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.

Bill Kelly

4/8/2005 9:44:00 PM

From: "Peter Suk" <peter.kwangjun.suk@mac.com>
>
> VisualWorks gets around this and also solves problems the paradox with
> not having "real" threads, wanting to do GC efficently, yet also
> wanting to do synchronous calls to the OS. The dilemma is this: You
> want real threads so your VM can utilize synchronous calls to the OS.
> However, this complicates GC immensely. (ObjectStudio Smalltalk lost a
> lot of performance because of having real threads. When it was time to
> GC, the main VM thread would have to raise a flag and wait for all the
> other threads to detect it.)
>
> VisualWorks can use real threads, but only in the case of calling out
> to a DLL, and these contexts are exempt from GC. This gives you the
> ability to make synchronous calls without freezing the entire image,
> yet also leaves your GC simple and fast.

Interesting. I'd been looking forward to the day
that Ruby supports "real" OS threads with great
anticipation. Sorry to hear there are such negative
performance trade-offs.

I'm unsure exactly what I'm trying to ask here...
But - did VisualWorks come up with some convenient
way to invoke a DLL call on a separate thread? From
the programmer's perspective, I mean. I'm imagining
something like making a DLL call and getting some
object back representing the thread, from which a
return value could eventually be obtained? ... Just
curious.

Most of my employer's Mac customers have dual processor
systems. Our app is currently C++ and sufficiently
multi-threaded to keep both CPUs busy. I've looked
forward to someday being able to write a multi-threaded
Ruby app that, using real OS threads, ran on both CPUs.

Anyway - not trying to sound negative... Just was
interested to know there are trade-offs...

Regards,

Bill

Peter Suk

4/8/2005 9:58:00 PM

On Apr 8, 2005, at 4:43 PM, Bill Kelly wrote:

> Interesting. I'd been looking forward to the day
> that Ruby supports "real" OS threads with great
> anticipation. Sorry to hear there are such negative
> performance trade-offs.
>
> I'm unsure exactly what I'm trying to ask here...
> But - did VisualWorks come up with some convenient
> way to invoke a DLL call on a separate thread?

Yes.

> From
> the programmer's perspective, I mean. I'm imagining
> something like making a DLL call and getting some
> object back representing the thread, from which a
> return value could eventually be obtained? ... Just
> curious.

There is something you have to specify when you hook up the DLL, but as
I understand it, from the caller's point of view, you just spawn your
own process and make a normal call.

> Most of my employer's Mac customers have dual processor
> systems. Our app is currently C++ and sufficiently
> multi-threaded to keep both CPUs busy. I've looked
> forward to someday being able to write a multi-threaded
> Ruby app that, using real OS threads, ran on both CPUs.
>
> Anyway - not trying to sound negative... Just was
> interested to know there are trade-offs...

Yes, the Java folks found this out the hard way. I would recommend
load-balancing. But it really depends on what your application is
doing and details of the architecture.

--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.

comp.lang.ruby

Re: Seven new VMs, all in a row

flaig

Peter Suk

Charles Mills

Peter Suk

Lothar Scholz

Charles Mills

Peter Suk

Glenn Parker

Peter Suk

Bill Kelly

Peter Suk

x Login to ForumsZone