[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TechEd 2006 -- "parallelism is the new OO"
At a guess, is Java not doing what Chen suggests in the post, and
reducing the stack size for each thread? I'm fairly sure that Java
uses a one-to-one threading model on Windows, so I don't see how else
it could be doing it.
Therefore I ask the question, does .NET need a 1 MB stack size per
thread? I think Neil has successfully answered this question right
here. Java seems to manage quite well with its reduced stack size.
This is probably getting off topic a bit; we all know that threading is
not the best solution. As to Mac OS X, I believe it is based somewhat
on Linux, so likely the same problems exist. I do know that different
versions of Linux also employ different threading techniques. One of my
fellow students was using Mono on Free BSD, and because of the
differences his .NET program would not run. Other Linux and Windows
platforms were fine, and I believe the problems are now resolved.
Kevin Chalmers
Research Student
School of Computing
Napier University
Edinburgh
-----Original Message-----
From: neil@xxxxxxxxxxxxxxxxx [mailto:neil@xxxxxxxxxxxxxxxxx]
Sent: 01 September 2006 14:54
To: Chalmers, Kevin
Cc: Andrew Delin; occam-com@xxxxxxxxxx
Subject: RE: TechEd 2006 -- "parallelism is the new OO"
At a guess, is Java not doing what Chen suggests in the post, and
reducing the stack size for each thread? I'm fairly sure that Java
uses a one-to-one threading model on Windows, so I don't see how else
it could be doing it.
I recall liking the ideas behind Microsoft's concurrent OS
(Singularity?) that was mentioned again on this list recently. I
imagine that the research team at Microsoft would no doubt meet the
same resistance that we are all familiar with when trying to "sell"
their ideas to the rest of the company. The frustrating thing is that
Linux (oft-purported to one day free us from Windows) is just as bad
(if not slightly worse) in my experience, and many of the developers
have a similar attitude to Chen. I haven't got any experience with
programming for OS X, but this study makes it look as if OS X is
actually even worse than the other two:
http://www.anandtech.com/mac/showdoc.aspx?i=2436&p=7
"In the early versions of Mac OS X, only one thread could lock onto the
kernel at once. This doesn't mean only one thread can run, but that
only one thread could access the kernel at a given time. So, a
rendering calculation (no kernel interaction) together with a network
access (kernel access) could run well. But many threads demanding
access to the memory or network subsystem would result in one thread
getting access, and all others waiting.
This "kernel locked bottleneck" situation has improved in Tiger, but
kernel locking is still very coarse."
Sigh!
Neil.
> -------- Original Message --------
> Subject: RE: TechEd 2006 -- "parallelism is the new OO"
> From: "Chalmers, Kevin" <K.Chalmers@xxxxxxxxxxxx>
> Date: Fri, September 01, 2006 2:40 pm
> To: <neil@xxxxxxxxxxxxxxxxx>
> Cc: "Andrew Delin" <Andrew.Delin@xxxxxxxxxxxxx>,
<occam-com@xxxxxxxxxx>
>
> 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.
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.