Seven new VMs, all in a row

ruby-talk
1

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

-- 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-inspector.de verschickt
Mail Inspector ist ein kostenloser Service von http://www.is-fun.net
Der Absender dieser E-Mail hatte die IP: 129.206.124.135

2

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

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

--Peter

···

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

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

3

Peter Suk 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....

···

On Apr 8, 2005, at 4:41 AM, flaig@sanctacaris.net wrote:
> And if so, what about incorporating this into Ruby 2.x one day? :slight_smile:

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.

4

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

···

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.

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

5

Hello Charles,

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.

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.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

6

Lothar Scholz wrote:

Hello Charles,

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

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.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

7

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.tetrafoil.com/&gt;

8

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

···

From: "Peter Suk" <peter.kwangjun.suk@mac.com>

9

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

···

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

Lothar Scholz wrote:

Hello Charles,

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

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?

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

10

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

···

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

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

11

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.

···

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

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

12

Peter Suk 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?

Perhaps there is a disconnect, but I didn't think I was that obtuse.

You said VW can use real threads, but only in the case of calling out to a DLL, and no GC. To me, that strongly suggests that the code executing in the real threads uses some traditional compiled language with manual memory management, e.g. C. If that is the price for getting real threads, it's not very attractive to me. If I have misunderstood, then please explain further.

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.

Well, maybe you're missing something, or maybe I need more help understanding the VW technology. I've read all your messages and I think I understand the general proposal, which is quite intriguing, or I wouldn't waste my time on it.

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.

Let's get one thing clear, I don't give a fig for language wars. Smalltalk has obviously solved a lot of problems that Ruby still struggles with, but it hasn't necessarily solved them in the way that makes sense for Ruby. So, please pardon me if I "look a gift horse in the mouth". Your willingness to invest your time and skills is noteworthy, but it doesn't mean that a Smalltalk VM is the ultimate answer for Ruby. Goodness knows, I'd love to see you deliver on the promise of your proposal, because I think Ruby needs a radical performance upgrade.

I don't know if I can convince you of this, but I'm trying to ask some sincere and probing questions about your proposal. This kind of probing is exactly what you invited by announcing your plans here. Why act so surprised when you get a bunch of naive Smalltalk questions from a group of Ruby folk, anyway?

···

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

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;

13

Peter Suk 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?

Perhaps there is a disconnect, but I didn't think I was that obtuse.

You said VW can use real threads, but only in the case of calling out to a DLL, and no GC. To me, that strongly suggests that the code executing in the real threads uses some traditional compiled language with manual memory management, e.g. C. If that is the price for getting real threads, it's not very attractive to me. If I have misunderstood, then please explain further.

Why is it that you'd want real threads? What can real threads do that Ruby VM threads can't do? The answer is synchronous calls out to OS services. (As well as utilizing multiple processors, but that's another issue.)

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.

Well, maybe you're missing something, or maybe I need more help understanding the VW technology. I've read all your messages and I think I understand the general proposal, which is quite intriguing, or I wouldn't waste my time on it.

In general, DLLs that you call out to are doing their own memory management. At least I hope so, or they're going to be a source of memory leaks.

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.

Let's get one thing clear, I don't give a fig for language wars. Smalltalk has obviously solved a lot of problems that Ruby still struggles with, but it hasn't necessarily solved them in the way that makes sense for Ruby. So, please pardon me if I "look a gift horse in the mouth". Your willingness to invest your time and skills is noteworthy, but it doesn't mean that a Smalltalk VM is the ultimate answer for Ruby. Goodness knows, I'd love to see you deliver on the promise of your proposal, because I think Ruby needs a radical performance upgrade.

I don't know if I can convince you of this, but I'm trying to ask some sincere and probing questions about your proposal. This kind of probing is exactly what you invited by announcing your plans here. Why act so surprised when you get a bunch of naive Smalltalk questions from a group of Ruby folk, anyway?

I need to get used to the idea that not every implication of everything I post here is going to be fully appreciated. Ruby has some great attributes. But it is not the first to have these! If you look under the covers, Smalltalk and Ruby are very alike. Startlingly alike. Ruby makes some design decisions which sacrifice performance in exchange for implementation & programmer convenience. But these differences are really not that big a deal. At bottom, both environments use the "everything is an object" principle. At bottom, everything is just messages sent to objects. Everything is dynamic, and there is no "compile-time vs. runtime" divide.

I appreciate the sincere and probing questions. I must admit to losing patience with questions that are not well informed. Especially those that are not "sincere." (i.e. really motivated by a "language wars" mentality.) However in retrospect, you don't fall into this last category.

--Peter

···

On Apr 8, 2005, at 8:40 PM, Glenn Parker wrote:

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

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

14

Hello Peter,

Why is it that you'd want real threads? What can real threads do that
Ruby VM threads can't do? The answer is synchronous calls out to OS
services. (As well as utilizing multiple processors, but that's
another issue.)

Having a database app where each "fetch_row" call into the database
driver have to do at least 2 sync operations and 2 thread schedules
really scares me when we are talking about high performance VM's.

In fact this is one the real weaknesses in the ruby implementation.
Does VM have a fork (or some other process like) model to use real
OS threads. TCL and Perl have this and it's part of there popularity.

···

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

15

Peter Suk wrote:

Why is it that you'd want real threads? What can real threads do that Ruby VM threads can't do? The answer is synchronous calls out to OS services. (As well as utilizing multiple processors, but that's another issue.)

Yes, I want synchronous I/O and true multi-cpu execution. And if I can't satisfy these needs without dropping into a very different language, I'll be disappointed.

In general, DLLs that you call out to are doing their own memory management. At least I hope so, or they're going to be a source of memory leaks.

Sure, but I am questioning the decision to rely exclusively on external compiled DLLs to access real threads. I want to write as much code as possible in the "primary" language, for all the obvious reasons.

I need to get used to the idea that not every implication of everything I post here is going to be fully appreciated.

We can't read your mind. You might want to start compiling a FAQ.

Ruby has some great attributes. But it is not the first to have these! If you look under the covers, Smalltalk and Ruby are very alike. Startlingly alike. Ruby makes some design decisions which sacrifice performance in exchange for implementation & programmer convenience. But these differences are really not that big a deal.

I appreciate the philosophical similarities, but I think you trivialize the impact of implementation and (especially!) programmer convenience.

At bottom, both environments use the "everything is an object" principle. At bottom, everything is just messages sent to objects. Everything is dynamic, and there is no "compile-time vs. runtime" divide.

I would be more interested in your list of things that are different, since that is where the real work will have to be done.

···

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;

16

Hello Peter,

Why is it that you'd want real threads? What can real threads do that
Ruby VM threads can't do? The answer is synchronous calls out to OS
services. (As well as utilizing multiple processors, but that's
another issue.)

I find multiple real OS threads so important that lack of this feature
puts a Visual Works port out of my interest.

Remember that we are now entering a time where even desktop computers
from the WalMart shelf come with 4 CPU's (2 real + 2 Hyperthreaded).

Good luck for you, but i will stay with YARV and not join the dark
side.

···

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

17

Lothar Scholz wrote:

Hello Peter,

> Why is it that you'd want real threads? What can real threads do

that

> Ruby VM threads can't do? The answer is synchronous calls out to

OS

> services. (As well as utilizing multiple processors, but that's
> another issue.)

Having a database app where each "fetch_row" call into the database
driver have to do at least 2 sync operations and 2 thread schedules
really scares me when we are talking about high performance VM's.

You don't *have* to do external calls in a separate thread, it's just
that you can where it's useful (ie, blocking I/O calls like making
database queries). For something like fetch_row, you might just use
the normal, older callout mechanism, which does what Ruby does: blocks
the whole VM until you return.

Like Ruby, Smalltalk implementations generally use non-blocking I/O
(made to look like blocking I/O from the point of view of the
language's threads), so native threads are only needed when the DLL
you're calling into only provides a blocking API.

Anyway, unlike much of the VisualWorks VM, this part is actually quite
well documented:
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/VisualWorks+THAPI

Avi

18

Glenn Parker wrote:

Peter Suk wrote:
>
> Why is it that you'd want real threads? What can real threads do

that

> Ruby VM threads can't do? The answer is synchronous calls out to

OS

> services. (As well as utilizing multiple processors, but that's

another

> issue.)

Yes, I want synchronous I/O and true multi-cpu execution.

And shared memory - right? Because with Ruby or Smalltalk, there's
nothing stopping you from using multiple CPUs by having multiple
instances of the VM, communicating through DRb or whatever.

The desire for native threads comes up quite a bit in the Smalltalk
world. It's interesting to see how the people at Cincom answer these
questions. Of the two Smalltalks they develop, ObjectStudio and
VisualWorks, one of them has native threads and the other has green
threads. The engineers that build their networking and database
systems always claim that the green threads scale much, much better -
porting such code from VisualWorks to ObjectStudio always involves a
lot of headaches in getting it to perform decently under the
disadvantage of native threads.

The best setup would probably be to have many green threads to each (of
multiple) native thread, but that's a huge engineering effort. I think
Matz made the right decision: keep things simple and under the direct
control of the VM.

> At bottom, both environments use the
> "everything is an object" principle. At bottom, everything is just

> messages sent to objects. Everything is dynamic, and there is no
> "compile-time vs. runtime" divide.

I would be more interested in your list of things that are different,

since that is where the real work will have to be done.

There really aren't many. Things that Ruby has that Smalltalk doesn't
(ie, would need to emulate somehow):

- Optional & variable argument methods
- Undeclared instance variables

Things any new implementation of Ruby will need to redo:

- Binary extension API
- Standard libraries
- Syntax

That's all I can think of offhand.

Avi

19

Lothar Scholz wrote:
...

Remember that we are now entering a time where even desktop computers
from the WalMart shelf come with 4 CPU's (2 real + 2 Hyperthreaded).

Can one give me hints where to read about the "ruby way of threading"?
...

Good luck for you, but i will stay with YARV and not join the dark
side.

What dark side are you talking about?

20

Lothar Scholz wrote:

I find multiple real OS threads so important that lack of this

feature

puts a Visual Works port out of my interest.

Good luck for you, but i will stay with YARV and not join the dark
side.

To clarify: I take it that native threading is in the plans for YARV,
then?

Avi