[M3devel] userthreads vs. pthreads performance?

[Jay K]

People need to know to reduce cross-thread sharing, to reduce lock contention. It is not impossible.

There are various conflicting trends though, granted.

Windows has long had fibers, but they are pretty impossible to use -- you need your own locking mechanisms, which interact with your own scheduler.

There is now "user mode scheduling" in Windows 7 that is easier to use, and the "concurrent runtime" makes it easier to use, along with helping reduce sharing.

 

 

You should sort of "map/reduce" sorts of things, where each thread can do some of the work independently and there is one last mop-up or sweep pass to collect the data.

Consider sorting large data sets for example.

You can break up the data into N pieces, sort of them independently on N threads, and then do one last single threaded pass to merge them.

 

 

"Cloud computing" pushes people toward models of very coarse grained parallelism -- multiple machines, not even the "old coarse grained" multiple processes on the same machine.

 

 

I think profiling is maybe in order to understand cvsup performance with user threads vs. kernel threads.

Usually I ignore performance but the difference is quite noticable in my limited testing.

 

 

Personally I've only been convinced that kernel threads are generally best and simplest.

There are tradeoffs though. Having one mondo scheduler puts a lot of pressure on that one scheduler

to figure out things for everyone, whereas within each program there is probably local information

that could provide for better scheduling. Basically, taking locks or waiting on objects (files, events,

semaphores) is the only way to communicate to a scheduler. It helps a lot, but maybe is not always

all that could be done.

 

 

 - Jay

 
> From: Highjinks at gmx.com
> To: m3devel at elegosoft.com
> Date: Sun, 28 Mar 2010 23:01:31 +0200
> Subject: Re: [M3devel] userthreads vs. pthreads performance?
> 
> On Sun, 28 Mar 2010 09:58:04 +0000
> Jay K <jay.krell at cornell.edu> wrote:
> 
> > 
> > I understand that userthreads don't scale across multiple processors.
> > 
> > But testing out cvsup lately, things are noticably much much faster
> > 
> > with user threads. At least cvsup. I haven't watched the compiler and such.
> > 
> > 
> > 
> > 
> > 
> > - Jay
> 
> In fact user threads, and better yet, Synchronous Threads, are in fact highly scalable when done right.
> 
> This has been one point of contention for me regarding the current crop of "mature" programming languages. Everything is being shoehorned into the Asynchronous model. 
> 
> The problem is that the Asynchronous model is staring to break down. With more and more processor cores being added, the need for more and more locks and mutexes and semaphores is growing. Not only does this kill performance, it makes problems like deadlock and race conditions much more difficult to prevent. 
> 
> It used to be that user threads, cooperative threads, and Synchronous threads were seen as bottlenecks. That might have been the case back when we were dealing maybe four processors max. But now were looking, in some cases, at machines with four 4 core processors on a MB; and that number is expected to keep growing. Now Cooperative threads and Synchronous threads are outscaling Asynchronous threads, particularly in multimedia applications.
> 
> The thing that is really needed now is language support and kernel support for the Synchronous model.
> 
> Here are some reference links, for those who are curious...
> 
> The Kusp project, which has support for Synchronous threads in the Linux Kernel.
> http://www.ittc.ku.edu/kurt/
> 
> A Wikipedia link on the Esterel programming language.
> http://en.wikipedia.org/wiki/Esterel 
> 
> Project COSA, which explores the issue a little more in depth.
> http://www.rebelscience.org/Cosas/COSA.htm
> 
> The Timber compiler, which is all about Synchronous Programming. For those who care to experiment.
> http://timber-lang.org/
> 
> I realize the OP is about "user threads", but I think it might be good to open up a discussion about "user threads" and the subtopics therein. Modula might benefit from a formal definition of this stuff. IMHO.
> 
> Anyone else share my interest?
> 
> -- 
> Chris <Highjinks at gmx.com>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100329/551abb46/attachment-0002.html>