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.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,e0e1d3b3f7c994b8
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!oleane.net!oleane!news.ecp.fr!club-internet.fr!feedme-small.clubint.net!feeder1-1.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 09 Mar 2008 10:39:06 +0100
From: Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>
Reply-To: rm.tsoh+bauhaus@maps.futureapps.de
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Robert Dewar's great article about the Strengths of Ada over
 other langauges in multiprocessing!
References: <13t4b2kkjem20f3@corp.supernews.com>
 <89af8399-94fb-42b3-909d-edf3c98d32e5@n75g2000hsh.googlegroups.com>
 <47D39DC8.20002@obry.net>
In-Reply-To: <47D39DC8.20002@obry.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <47d3b03d$0$21941$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 09 Mar 2008 10:39:09 CET
NNTP-Posting-Host: 2f21c2f2.newsspool2.arcor-online.net
X-Trace: 
 DXC=49mln`6[nbB[kmHKHnaEnMA9EHlD;3YcB4Fo<]lROoRAFl8W>\BH3YB_9CBl<o]HEAA:ho7QcPOVCh?Vo1<4;WUJR1bCBZl6<PJ
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:20249
Date: 2008-03-09T10:39:09+01:00
List-Id: <comp.lang.ada>

Pascal Obry wrote:
> Maciej Sobczak a �crit :
>> Ada will most likely miss the "multicore revolution", unless it will
>> *really* focus on performance - the point is that all this multicore
>> hoopla revolves around performance, *exclusively*.
> 
> Probably, that's why C++ code using threading, OpenMP or MPI are just a
> mess. Impossible to maintain because C++ hackers seems to prefer working
> hard 6 month for gaining 2% of performance instead of buying a new
> computer with more core or adding some node on a cluster. Sorry, but
> I've seen that, horrible mess just because hacking C++ code seems fun to
> many people.

Then again, the multicore things have atomic updates built in
which offer some opportunities that only happen to be
part of the Ada language. Now this language feature becomes
visible as part of the top selling CPUs...
There is research on employing these CPU mechanisms for Ada use,
but, IIUC, it is not *visible* on many sites that are visible to
those interested in how to use new multicore CPUs.
And Ada RTS/Library inclusion is not done yet, or is it?

Multicore algorithms can continue the great academic tradition of
efficient algorithms. Aren't lock-free ones really a natural
starting point? They also have their uses.
IIRC, ready-made Communicating Sequential Processes has a lower
visibility in CS than the basic critical section model.

Ada's tasking implementations are not currently known to be the
best choice when an algorithm is about how to efficiently use
the multicore CPU with word sized memory.  The tasking protocol as
implemented for x86 < Today turns out to be too heavy weight.
The cost is far beyond 10%.



> The cherry on top of the cake is that your application can be ported to
> a new architecture without much trouble.

Gidenstam has ported his Primitives (Ada packages hiding the
CPU's atomic updates) to at least Intel, Sparc, and MIPS.
Built on top of the Primitives, he has a lock-free bounded buffer
in queue mode...