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,c4cb2c432feebd9d
X-Google-Thread: 1094ba,c4cb2c432feebd9d
X-Google-Attributes: gid103376,gid1094ba,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!news3.google.com!news.glorb.com!cycny01.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc03.POSTED!87bf9b22!not-for-mail
From: Dan Nagle <dannagle@verizon.net>
Reply-To: dnagle@erols.com
Organization: Purple Sage Computing Solutions, Inc.
User-Agent: Thunderbird 1.5.0.2 (X11/20060420)
MIME-Version: 1.0
Newsgroups: comp.lang.ada,comp.lang.fortran
Subject: Re: Ada vs Fortran for scientific applications
References: <mubcg.13522$fb2.853@newssvr27.news.prodigy.net>
 <epcs4e.qb8.ln@hunter.axlog.fr> <tHkcg.6937$kR6.484@trnddc05>
 <0ugu4e.4i7.ln@hunter.axlog.fr> <LwCcg.5894$p13.115@trnddc07>
 <pan.2006.05.23.13.14.04.190594@linuxchip.demon.co.uk.uk.uk>
 <_iHcg.5599$oa3.1506@trnddc08>
 <pan.2006.05.23.22.20.11.863186@linuxchip.demon.co.uk.uk.uk>
 <ikMcg.7532$ix2.639@trnddc03>
 <pan.2006.05.23.23.20.10.869090@linuxchip.demon.co.uk.uk.uk>
In-Reply-To: <pan.2006.05.23.23.20.10.869090@linuxchip.demon.co.uk.uk.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <U4Ocg.7543$ix2.6912@trnddc03>
Date: Wed, 24 May 2006 00:49:56 GMT
NNTP-Posting-Host: 70.108.4.182
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc03 1148431796 70.108.4.182 (Tue, 23 May 2006 20:49:56 EDT)
NNTP-Posting-Date: Tue, 23 May 2006 20:49:56 EDT
Xref: g2news2.google.com comp.lang.ada:4397 comp.lang.fortran:10160
Date: 2006-05-24T00:49:56+00:00
List-Id: <comp.lang.ada>

Hello,

Dr. Adrian Wrigley wrote:

<snip>

> As regards interprocessor communications vs. memory buses, it depends
> at what levels you make the comparisons.  On chip memory arrays
> may be 1000's of bits wide at GHz speeds.  Communications between
> processor chips are a small fraction of that.

Yes.  The mix of what's to be on-chip is always changing.
Some folks (with applications programmer perspectives) were
a little unsure co-arrays are a long-term solution (remember
what happened to HPF).  I expect co-arrays to work well
on any architecture from SMP to DMP, at least as well
as the competing spellings of parallelism.

> The challenge for co-array and SIMD computing is to work out
> simple hardware that can utilize inter- and intra-chip
> communications and memories efficiently.  This needs to have
> a sensible programming model (eg assembly language, instruction
> set architecture).  Only then is it worth considering what language
> features (if any) are necessary to compile for it.
> Sadly, what passed for SIMD computing in the '70s and '80s
> was way too restrictive and often inefficient for its capabilities
> to be worth providing for in general-purpose languages.

We usually call co-arrays SPMD (single program multiple data)
because it's not really "single instruction", but check
the synchronization rules.

> Progress is glacial :(

Yes.  :-(

> I wish the Fortran committee the best of luck with their co-arrays!

Thanks.  Best of luck with Ada.

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.