Hi Peter,

I'd be curious to hear your analysis of the GemStone/S approach where  
you can have as many OS processes as you want (well, up to 10,000),  
and they all share the same object space (image), but synchronize only  
on programmer-defined transaction boundaries. I believe that one large  
installation has a 256 CPU machine on which they run a couple thousand  
concurrent OS processes. The GS/S architecture has been in commercial  
development/deployment for a couple decades.

James

On Jul 6, 2008, at 8:45 PM, Peter William Lount wrote:

> [snip]
>
> I do really like the N (small, medium, large) images in memory at  
> the same time model as it's excellent for things like web  
> application serving and many other applications.
>
> However, fixing the number of native threads to one per image simply  
> limits solutions by forcing a developer/user to split their program  
> across multiple images just so they can run multiple native threads  
> to take advantage of their hardware. I think it not a good thing to  
> impose that upon developers or users, in part because it will often  
> impose a solution refactoring and in part because it only works for  
> a subset of problems that can be easily partitioned across images. A  
> refactoring might be worthwhile but may be cost prohibitive. Also  
> moving all the objects around between images (in one memory space or  
> across memory spaces) involves other problems just as complex as any  
> multi-threading issues solved. So all you've done it punt the ball  
> aways down the field but it's still there... lurking... ready to  
> strike...
>
> [snip]
>
> If the Smalltalk/Squeak/Commercial community doesn't want to move  
> forward to take maximal general purpose advantage of the multi-core  
> cpus that would be a big disappointment indeed. The other languages  
> will leave Smalltalk in their dust. That is what clients are telling  
> me and I happen to agree with them.
>
> I ask the Squeak Smalltalk (and Commerical Smalltalk) virtual  
> machine developers and communities to please reconsider the general  
> purpose many native threads per image solution for the next versions  
> of your virtual machines.
>
> I think it's best to let each developer-user choose how many native  
> threads per image and how many images are loaded and which images  
> are loaded. After all it's their program. Isn't our job as language  
> and systems designers to provide them with the tools that they need  
> to build the systems that they want to build? I think so. What do  
> you think?
>
> All the best,
>
> Peter William Lount
> [ | peter at smalltalk dot org ]
>