comp.lang.ada
 help / color / mirror / Atom feed
From: Warren <ve3wwg@gmail.com>
Subject: Re: Threadpool with priority version 1.1 ...
Date: Wed, 24 Mar 2010 16:40:46 +0000 (UTC)
Date: 2010-03-24T16:40:46+00:00	[thread overview]
Message-ID: <Xns9D4580FB5667EWarrensBlatherings@188.40.43.245> (raw)
In-Reply-To: 4baa27f2$0$6770$9b4e6d93@newsspool3.arcor-online.net

Georg Bauhaus expounded in news:4baa27f2$0$6770$9b4e6d93
@newsspool3.arcor-online.net:

> Dmitry A. Kazakov schrieb:
>>  how the proposed algorithms map onto the
>> Ada tasking model, especially taking into account that Ada tasking
>> primitives are higher level, than ones known in other languages.
> 
> As a side note: it seems anything but easy to explain
> the idea of a concurrent language, not a library, and
> not CAS things either, as the means to support the programmer
> who wishes to express concurrency.
> Concurrency is not seen as one of the modes of expression
> in language X. Rather, concurrency is seen as an effect
> of interweaving concurrency primitives and some algorithm.
> 
> What can one do about this?

I thought the Cilk project was rather interesting in
their attempt to make C (and C++) more parallel
to take advantage of multi-core cpus. But the language 
still requires that the programmer program the parallel 
aspects of the code with some simple language enhancements.

As cores eventually move to 128+-way cores, this needs
to change to take full advantage of shortened elapsed
times, obviously.  I think this might require a radical
new high-level language to do it.  

Another barrier I see to this is the high cost of 
starting a new thread and stack space allocation.

I was disappointed to learn that the Cilk compiler uses
multiple stacks in the same way that any pthread 
implementation would. If a single threaded version of
the program needs S bytes of stack, a P-cpu threaded
version would require P * S bytes of stack.  They do get
tricky with stack frames when they perform "work stealing"
on a different cpu. But that is as close as they get
to a cactus stack.

Somehow you gotta make thread startup and shutdown
cheaper. The only other thing to do is to create a
pool of re-usable threads. But in my mind, the
optimizing compiler is probably in the best place
to make parallel code optimizations that consist of
short runs of code.

Warren



  reply	other threads:[~2010-03-24 16:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <21e6697e-fd7c-4c5e-93dc-8d894449b5e6@f8g2000yqn.googlegroups.com>
     [not found] ` <ff3671a8-cf19-4cee-8b71-305bb6b1e9c1@l25g2000yqd.googlegroups.com>
     [not found]   ` <4ba9e189$0$6886$9b4e6d93@newsspool2.arcor-online.net>
     [not found]     ` <1id5xnuz0x892$.1odbic5ppiv07.dlg@40tude.net>
2010-03-24 14:55       ` Threadpool with priority version 1.1 Georg Bauhaus
2010-03-24 16:40         ` Warren [this message]
2010-03-24 18:27           ` Ada parallelism (was: Re: Threadpool with priority version 1.1 ...) Georg Bauhaus
2010-03-24 20:04             ` Warren
2010-03-25  8:24               ` Ada parallelism Dmitry A. Kazakov
2010-03-25 13:44                 ` Robert A Duff
2010-03-25 14:09                   ` Dmitry A. Kazakov
2010-03-24 21:46           ` Threadpool with priority version 1.1 Maciej Sobczak
2010-03-25 17:21             ` Warren
2010-03-25 17:30             ` Warren
2010-03-26  8:19               ` Dmitry A. Kazakov
2010-03-26  9:30                 ` Maciej Sobczak
2010-03-26 19:35                   ` Warren
2010-03-25  8:39         ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox