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!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc03.POSTED!87bf9b22!not-for-mail From: Dan Nagle 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: <0ugu4e.4i7.ln@hunter.axlog.fr> <_iHcg.5599$oa3.1506@trnddc08> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 23 May 2006 22:49:50 GMT NNTP-Posting-Host: 70.108.4.182 X-Complaints-To: abuse@verizon.net X-Trace: trnddc03 1148424590 70.108.4.182 (Tue, 23 May 2006 18:49:50 EDT) NNTP-Posting-Date: Tue, 23 May 2006 18:49:50 EDT Xref: g2news2.google.com comp.lang.ada:4394 comp.lang.fortran:10155 Date: 2006-05-23T22:49:50+00:00 List-Id: Hello, Dr. Adrian Wrigley wrote: > If Fortran had strong multitasking, real-time and distributed > capabilities, these goals would be reasonable and achievable > within the language. Absence of these features means such > systems would often (I guess) be multi-language setups, with things > like Java, C++, Tcl/Tk, shell scripts, cron jobs etc. playing a part. > Has anyone here worked on a big meteorological system? Am I right? I don't know, perhaps someone at a meteorological center can answer. There are several Fortran interfaces to pthreads, and there's always OpenMP. > Co-arrays fill a longstanding, unmet need in programming languages. > Fortran, in particular, should have had this feature long ago. > But the design/semantics are challenging to get something which > is truly general-purpose, useful and understandable. > Co-arrays would be great if they were widely available and performant. > But they're not :( Actually, they're a proven design from Cray. At the last meeting of the Fortran committee (May 06), my impression from the vendors present was that customers are demanding co-arrays so strongly that they will be implemented rather quickly, now that the design has stabilized. > Designing a co-array system involves bridging the semantic gap > between the software author, the compiler and the hardware > architecture. The Co-array Fortran proposals seem to fill an > existing need within the community, but I don't think make a > good model to adopt in other languages. See UPC (a/k/a "Unified Parallel C" IIRC) for a similar C feature. > I did briefly work > on more general ideas for language/hardware co-design using > co-arrays and similar. Initial results were encouraging, but > to make use of the technology, you really need a custom parallel > processor built. And rewriting your software :( But today, interprocessor communications are approaching the performance of memory buses. I believe co-arrays will deliver performance at or better than MPI on many architectures, and in many clusters. Any application re-write is minimal compared to inserting MPI calls. -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc.