RE: TechEd 2006 -- "parallelism is the new OO"

["Chalmers, Kevin" <K.Chalmers@xxxxxxxxxxxx>]

I don't understand Chen's argument of requiring 1 Megabyte of stack
space per thread being the issue.  Running the same batch of tests under
JCSP allows around 7000 threads until the VM runs out of memory.  Note I
say VM as Java only allocates itself only so much memory, although this
can be altered from the command line I believe.  For .NET, the VM uses
as much resources as there are available, until of course your system is
almost hanging.  Even at the bottom of the article Chen comments on how
he'll "muse on the duality of threads and objects". This just makes the
matter worse.

Kevin Chalmers
Research Student
School of Computing
Napier University
Edinburgh
-----Original Message-----
From: neil@xxxxxxxxxxxxxxxxx [mailto:neil@xxxxxxxxxxxxxxxxx] 
Sent: 01 September 2006 13:51
To: Chalmers, Kevin
Cc: Andrew Delin; occam-com@xxxxxxxxxx
Subject: RE: TechEd 2006 -- "parallelism is the new OO"


Kevin Chalmers wrote:
>The performance is fairly reasonable on a decent machine, considering
the benefits of portability and  mobility that you get.  Its by no
means up KRoC, C++CSP, or the Transterpreter speeds however.  

To be honest, comparing JCSP with C++CSP is unfair.  Mea culpa on that
one, as I did include a comparative benchmark in one of my papers. 
C++CSP is quick, but doesn't take advantage of multiple processors
seamlessly like JCSP can.  I believe the same may be true of KRoC?  So
it is a bit apples-and-oranges in that regard.  A better benchmark
would be against a POSIX-threads implementation of CSP (is there one
around?)

>Im estimating that a running thread in .NET needs about 1 Megabyte of
memory, hardly lightweight.  This gives you around a maximum of around
2000 threads in a Windows XP 32-Bit machine.  I doubt an OO program with
only 2000 objects is desirable in this respect.   

There is an MSDN blog post that I found while researching my CPA 2006
paper... 
http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx  I'm
told the author (Raymond Chen) is a well-respected Microsoft techie,
but as often when people from other schools of CS consider threading,
it is frustrating reading.  "Why are you creating so many threads that
this even becomes an issue?" he asks. 

It is clear that often the designers and users of threads believe that
one thread per CPU is all that is necessary, and anything else is
overkill.  As Kevin notes, how would they feel about one object per
CPU!  This is why I believe that many-to-many mapping of CSP/POP
processes onto threads is appropriate (multiple processes per thread,
and multiple threads).  More on this in my talk at CPA 2006, for those
who are attending :-)

Neil.

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
University's system is subject to routine monitoring and filtering by the University.