Seven new VMs, all in a row

ruby-talk
21

Well, we sure will miss you and your impotent insights!

--Peter

···

On Apr 9, 2005, at 2:29 PM, 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.)

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

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

22

Avi Bryant wrote:

Glenn Parker wrote:

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

And shared memory - right?

Of course, otherwise threads are no more interesting than (heavy-weight) processes.

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.

Right, nothing except the overhead and occasional confusion that results from passing objects between processes.

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.

Yup, I've been there (using C++, not Smalltalk). If you write code assuming that you have "unlimited" threads (which green-style threads encourages), some OS threading implementations will really knock you flat on your kiester. If you can redesign to treat threads as limited resources (more like processes), native threads excell. I'm not saying one threading style is necessarily "better", they each have their place and they each require compromises.

The best setup would probably be to have many green threads to each (of
multiple) native thread, but that's a huge engineering effort.

Sort of like what Solaris already did, and rather nicely at that. Sadly, nobody followed in their tracks, or I would have had a lot less code to redesign.

I think
Matz made the right decision: keep things simple and under the direct
control of the VM.

I assert that a VM can be threaded and still maintain direct control, it just won't be quite as simple.

···

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

23

Avi Bryant wrote:

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

This is very sketchy plan:

2005:
Summer
   merge eval.c and yarv
Winter
   (native?) Thread support

See http://rubyforge.org/pipermail/yarv-devel/2005-March/000270.html

Still sounds a bit iffy to me.

···

On Mon Mar 28 15:05:36 EST 2005, SASADA Koichi wrote:

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

24

Lothar,

Oh my, let me apologize. This is an unfortunate typo!

People's comments here have been universally valuable, and there has been a 100% sincere effort on the part of everyone to provide constructive criticism and encouragement. This is very refreshing, since I have also experienced other groups where certain people would emotionally react against new ideas with FUD, despite repeatedly having it demonstrated to them that they had their facts wrong and they really knew relatively little about the target of their FUD in the first place.

In any case, I just remembered a certain cross-platform JIT VM by a certain obscure software company. One which is reputed to be quite fast, though it only has source-level compatibility -- meaning one cannot just FTP images to a new platform and restart them there. But this is fine, since I have already decided on compatibility at the source level. This VM also happens to have native threads. I will look into putting Ruby on top of this if enough people are interested. Incidentally, I have noticed in other discussions that this group is generally very good natured, and given how it can often be otherwise, this is truly something to be valued. There have also been many very good observations here, which have been genuinely helpful. I hope that all those in this group who post in that spirit will forgive me a few moments of crankiness. (And if I sincerely mean anything in this message, it is definitely everything in this last paragraph.)

--Peter

···

On Apr 9, 2005, at 5:46 PM, Peter Suk wrote:

On Apr 9, 2005, at 2:29 PM, 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.)

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

Well, we sure will miss you and your impotent insights!

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