[vwnc] 64-bit and multicore VW smalltalk

>think they might consider doing it. Remember that a 64 bit image (or
>any program for that matter) consumes more memory, as pointers are
>larger than in 32 bit images.
>
>A VisualWorks image runs on only one OS thread, and the chances for
>this to change in the near future are minimal. In fact not everybody
>agrees that this is the way Smalltalk should scale on multiple cores.
>Your current approach would be to fork of several worker images, as
>described in the article linked to below. This will fit nicely if you
>can use divide and conquer to solve your problem.
>
>http://www.cincomsmalltalk.com/userblogs/runarj/blogView?

>----Ursprüngliche Nachricht----
>Von: [hidden email]
>Datum: 14.04.2008 14:22
>An: "[hidden email]"<[hidden email]>
>Cc: <[hidden email]>
>Betreff: Re: Re: [vwnc] 64-bit and multicore VW smalltalk
>
>There are two different approaches to make a program parallel:
>
>- Shared data (domain object) between multiple running threads. Use
>coordinating mechanisms like semaphores etc
>(http://blog.w-nz.com/archives/2006/03/02/locks/).
>
>- No shared data. All data accessed by a thread is private to the
>thread. This means data must be copied between the threads.
>
>Intuitively, most programmers will go for the "share data" approach.
>Java and C# includes mechanism to do this. VisualWorks does not. This
>approach does however have problems. Getting the coordination correct
>can be tricky, testing it is even worse
>(http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf).
>Another problem is that once you want to scale beyond the number of
>cores on a single box your model breaks.
>
>When data is not shared, you make copy of the data passed to the
>various threads. Erlang -- as far as I understand -- uses this
>approach. In VisualWorks, this means copying data between images.
>There are many ways to do this. I had a problem that took minutes and
>even hours to run. In this case using the database was fast enough.
>The file system, or inter-process communication can also be used.

> Hello,
>
> i  have two questions concerning cincom VisualWorks smalltalk.
>
> - Is it possible to write a 64-Bit VW smalltalk program that runs
> under Windows Vista 64-Bit in a 64-Bit mode?
> I read that cincom smalltalk supports Linux and Solaris 64-Bit but i
> didnt read sth about Microsoft's 64-Bit OS.
>
>
> -Is there an effective way to program on mutlicore CPUs (like for
> example Intel's Dual Core).
> I want to change a serial program as easy as possible to run faster
> on a multicore CPU with using parallel programming.
>
> I hope that sb can help me.
> Thanks.
>
> greetings,
>
> peter
>
>
> Jetzt neu: Der Routenplaner von Tiscali
> http://www.tiscali.de/trav/routenplaner.html
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

>Of Joerg Beekmann
>Sent: 17 April 2008 3:36 a.m.
>To: [hidden email]
>Cc: VWNC
>Subject: Re: [vwnc] Multithreading (was: multicore VW smalltalk)
>
>Ah, but you are making my point for me. You are building higher levels
>of abstraction on top of the facilities provided. My point was not that
>the VW threading model was in any way deficient or inconvenient, just
>that there are other models for threading which provide more tractable
>semantics. For example a message passing model; the thought I had was
>the OpenTalk could be extended to be not just a inter-image
>communications mechanism, but also the intra-image communications
>mechanism.
>
>Joerg
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]]
>Sent: Wednesday, April 16, 2008 1:40 AM
>To: Joerg Beekmann
>Cc: VWNC
>Subject: Re: Multithreading (was: multicore VW smalltalk)
>
>Am 16.04.2008 um 00:07 schrieb Joerg Beekmann:
>>
>> I agree Open Talk is a very nice piece of work. I've often thought
>> that
>> Smalltalk could do worse that adopt this model for inter-process
>> communication with in the image. Semaphores and threads are at level
>> of
>> abstraction so much lower than the rest of Smalltalk that it always
>> bugs
>> me when I need to use them.
>
>Hi Joerg,
>
>IMHO the semaphores and green tasks of Smalltalk are just fine. After
>an initial learning curve (e.g. how to safely launch, name, terminate
>and synchronize them), I found it very pleasant to work with multi-
>threading. I'm running dozens of them all the time in my products and
>actually started thinking in terms of tasks and queues.
>
>BTW: I would love to have the ability to generally encapsulate a class
>as a task:
>
>1) The class behaves like a server that is launched when the first
>instance is created and shut down after the last instance was released.
>
>2) Instances behave like "shared data"
>
>3) Sending a message to an instance transparently makes it a server
>request, i.e. the message is queued, processed and answered