From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,6f24e26ea2e03c4
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder2.cambriumusenet.nl!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!216.196.110.149.MISMATCH!border2.nntp.ams.giganews.com!nntp.giganews.com!news.mixmin.net!feeder.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Warren <ve3wwg@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Threadpool with priority version 1.1 ...
Date: Wed, 24 Mar 2010 16:40:46 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <Xns9D4580FB5667EWarrensBlatherings@188.40.43.245>
References: <21e6697e-fd7c-4c5e-93dc-8d894449b5e6@f8g2000yqn.googlegroups.com>
 <ff3671a8-cf19-4cee-8b71-305bb6b1e9c1@l25g2000yqd.googlegroups.com>
 <4ba9e189$0$6886$9b4e6d93@newsspool2.arcor-online.net>
 <1id5xnuz0x892$.1odbic5ppiv07.dlg@40tude.net>
 <4baa27f2$0$6770$9b4e6d93@newsspool3.arcor-online.net>
Injection-Date: Wed, 24 Mar 2010 16:40:46 +0000 (UTC)
Injection-Info: feeder.eternal-september.org;
	logging-data="9657"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/chbK2ZdXZZNb//PSNYAPf25D4lFhUaTM="
User-Agent: Xnews/5.04.25
X-Face: 
 &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j
Cancel-Lock: sha1:X2BE6O2rblsumfM16urSLuI4hAs=
Xref: g2news2.google.com comp.lang.ada:10712
Date: 2010-03-24T16:40:46+00:00
List-Id: <comp.lang.ada>

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