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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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 Newsgroups: comp.lang.ada,comp.lang.fortran Path: g2news2.google.com!news2.google.com!news4.google.com!news.glorb.com!sws1!ornl!news.er.usgs.gov!news From: "J.F. Cornwall" Subject: Re: Ada vs Fortran for scientific applications In-Reply-To: X-Nntp-Posting-Host: nx58dnelnc.cr.usgs.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-ID: User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) Sender: news@igsrsparc2.er.usgs.gov (Janet Walz (GD) x6739) Content-Transfer-Encoding: 7bit Organization: U.S. Geological Survey, Reston VA References: <0ugu4e.4i7.ln@hunter.axlog.fr> <_iHcg.5599$oa3.1506@trnddc08> Mime-Version: 1.0 Date: Wed, 24 May 2006 12:56:29 GMT Xref: g2news2.google.com comp.lang.ada:4408 comp.lang.fortran:10193 Date: 2006-05-24T12:56:29+00:00 List-Id: Dr. Adrian Wrigley wrote: > On Tue, 23 May 2006 17:07:06 +0000, Dan Nagle wrote: > >> Hello, >> >> Dr. Adrian Wrigley wrote: >> >> >> >>> Isn't this a bit more like MPI? >> Well, it's like MPI minus the rubbish. >> >>> In Ada, these concurrency features are very robust and streamlined. >>> This is because tasking was a primary goal of the language design. >>> >>> For a typical Fortran application like weather forecasting, this >> ^^^^ >>> is exactly the architecture you might choose. It may be >>> hardcore numerical code. >> I'm not sure which antecedent "this" references, >> but the meteorological folks are one of the main >> forces behind co-arrays. > > In a weather forecasting program you want to have data > acquisition (real-time), prediction (computation) and display > (real-time GUIs) running on a continuous, high uptime basis > across a network of machines. > > 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? > In my US Air Force days, I worked at a large global weather-forecasting facility. We had multiple data input systems (a variety of comm links talking to several Univac mainframes), multiple number-crunching systems (a couple more Univacs and a Cray), and an cluster of 40 or so Vax 11/780s for interactive tweaking of the forecasts. The majority of the software for the comm was in assembler, just about all of the remainder was Fortran (IV and 77, this was back in the early 80's...). We also used Fortran mixed with assembly code for a new comm front-end machine that was implemented in '88. Fortran was used for comm, utility programs, forecasting models, database input/output/maintenance, and just about everything else in that system. Worked fine. Nowadays, I have no idea what they're running. Bet there's still a lot of Fortran though :-) Jim > 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 :( > > 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. 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 :( > -- > Adrian >