back to article Open MPI hits milestone with FORTRAN-ready 1.7.4 release

The decade-old Open MPI project, beloved of the HPC community, has shipped code for a major feature release that brings it close to a complete MPI 3 implementation. Speaking to The Register, Cisco's Jeff Squyres (who along with Richard Graham, then of Los Alamos and now with Mellanox, was one of the instigators of the Open MPI …

COMMENTS

This topic is closed for new posts.
  1. Francis Vaughan

    MPICH?

    "The MPI standard first got turned into Open-MPI by Squyers and Graham in a project that began in 2004 and shipped its first code in 2005."

    Whilst Open MPI is are really good thing, it seems disingenuous to totally ignore MPICH, which is another open source MPI that first shipped code in 1992, and is still going.

  2. Michael H.F. Wilkinson Silver badge

    Just have to say

    In all my years of FORTRAN coding for HPC, I really, really, really got to loathe that language. OK, F90 and F95 were improvements, but my association with F77 did so much damage that I never really got over it. Implied do loops in read statements and common blocks really did me in.

    </rant>

    Breathe deep, relax, let blood pressure go down.

    ....

    There, I'm OK again

    On a serious note: thumbs up to that team. You may hate FORTRAN, but it is important, as is MPI. Giving more choice in free MPI implementations is always going to be good news (yes we have used MPICH as well as Cray's implementation of MPI). MPI is the de-facto standard for development of distributed memory algorithms.

    1. phil dude
      Pint

      Re: Just have to say

      spelling mistakes become variables...

      whitespace matters...

      HPF is kinda neat...just saying.....

      P.

      1. cpage

        Re: Just have to say

        "spelling mistakes become variables..."

        Not if you use implicit none, which all competent programmers do.

        "whitespace matters..."

        Not in anything since Fortran77, for example Fortran90, Fortran95, Fortran2003, Fortran2008.

        "HPF is kinda neat...just saying....."

        But Fortran2008 has co-arrays, which greatly simplifies parallel code, and makes HPF, MPI, and similar libraries obsolescent. Just saying...

    2. RobHib

      @ Michael H.F. Wilkinson -- Re: Just have to say

      In all my years of FORTRAN coding for HPC, I really, really, really got to loathe that language.

      Many would agree with you including Kemeny and Kurtz who transmogrified the original FORTRAN versions into BASIC thus saving the sanity of many a student. However, think yourself lucky. From a reading of your post it seems you only had to contend with F77 and later, reckon you'd have a bit of extra nail biting with FORTRAN IV/66 or earlier. (It would be interesting to know what type of programs you wrote in FORTRAN, for often I've seen it used where say PL/I would have been a better choice. In such circumstances, I've seen programmers curse and swear constantly and I don't blame them.)

      My baptism of fire was FORTRAN IV but even so that didn't stop me hogging the KP26 (026) / KP29 (029) punch card room of an evening until the univ's grey men threw me out. (Evenings were best as there was easier access to the much-fought-over IBM KP-29s, which were then the latest generation card punches and easier to use than the older 026s.)

      For me, the Achilles' heel of the early FORTRANs was their horrible I/O, those bloody format statements had me constantly swearing and ripping up punch cards.

      Nevertheless, I don't care what anybody says, if you're doing science/maths then wheel in FORTRAN as it's still the best tool for the job. Moreover, you can call on the many well-tested and well-authenticated subroutine libraries, ISML etc. (I have a few scientific and engineering programs that I still use which I originally wrote in FORTRAN IV and punched out on Hollerith cards decades ago. With a few I/O tweaks and such they still compile perfectly in modern environments. The reason why there's still much FORTRAN IV around is that it is so portable.)

      I'm not suggesting for a moment that FORTRAN is the be-all and end-all of programming, it isn't (so C programmers, don't have apoplexy, I'm not suggesting you write Windows or OS X in FORTRAN). Over the years I've had to use many different languages, COBOL, PL/I, LISP (a favorite of mine), C and its variants, etc., but I've always compared them with FORTRAN. FORTRAN—far from being dead—is a fine language and still the reference by which others are compared. However, like all others, it's best confined to environments in which it was deigned to work.

      ——

      BTW, whilst the original FORTRAN 0 (1954/56) has limitations, I reckon there's nothing like it for the ease of examining code, look at a printout and the algorithms almost have a clarity as if their equations were written on a blackboard.

      P.S.: I'd have to agree with Phil O'Sophical re Pascal, as I'd reckon most FORTRAN, C, PL/I, BASIC programmer probably would, it's irritating and restrictive. We programmers who've had the freedom and flexibility of say C don't like being constrained in the way Pascal does. Then again, perhaps Niklaus Wirth was trying to bring us programmers down to earth in the way other engineering professions are constrained by the real world and have to structure jobs accordingly—after all, a bridge designer has to set up his complete design, engineering environment etc. before he starts building whereas the C programmer can begin in the middle of the 'river' if he so desires. ...And, of course, that can have many undesirable consequences, bugs and such! ;-)

    3. Nigel 11

      Implied do loops

      Hmmm. Whats wrong with a clear syntax that avoids several extra lines of code, that lets you access data files that aren't in the natural order for the program in one concise line? e.g.

      READ( 10,*) (A(I), B(I), I=N, 1, -1)

      where you've got quantity N data pairs and you want them in two arrays in the opposite order to how some other program stored them?

      A similar concept, properly generalised, was fairly recently added to Python. ("List Comprehensions")

    4. Michael Wojcik Silver badge

      Re: Just have to say

      Like traditional COBOL, traditional FORTRAN (i.e. anything prior to Fortran90, which is when the official capitalization changed) is indeed fraught with infelicities and dangers. But that's because both languages were inevitably products of their time. Even LISP (about a decade after the first FORTRAN) had relatively luxurious resources at its disposal.

      Also like COBOL, modern Fortran is a vast improvement over the traditional dialects. While I wouldn't claim contemporary Fortran is the only "best" language for mathematics and scientific programming (Julia, R, Mathematica, and even Python all do very well), it's certainly a contender.

      (And on a tangent, I'll note that Python isn't the only language to get list comprehensions recently; it's one of the currently-hip features for programming languages, as lambda operators were a few years back. Next week maybe it'll be continuations. Or monads. Or combinators. Just think what you could do with more built-in combinators!)

  3. Ian Bush
    Headmaster

    Please, the capitalisation ... It's Fortran. It's been officially Fortran for almost 25 years now. And if you look at the original Fortran manual

    https://www.fortran.com/FortranForTheIBM704.pdf

    you'll see it was Fortran in 1956

    1. Michael H.F. Wilkinson Silver badge
      Happy

      Fortran, indeed

      it's just that I always start to shout. Cannot help myself. And of course, the old CDC 7600 HAD A 64-ENTRY CHARACTER SET WHICH SUPPORTED UPPER CASE ONLY, SO IT AUTOMATICALLY BECAME FORTRAN. Luckily, we had a PDP-11 front end to the monster machine, which did allow your code to have a more restrained appearance (that AND we used Pascal for our initial practicals)

      1. Phil O'Sophical Silver badge
        Happy

        Re: Fortran, indeed

        that AND we used Pascal for our initial practicals

        You poor man. Pascal has to be one of the worst langauges ever invented as far as actually doing anything practical was concerned. Great for showing the theoretical advantages of structured coding, but try any real-world problem and you ended up with so many hacks and system-specific functions that it rapidly became unmanageable. Worse than Java. I quite liked its successor, Modula-2, though.

        Fortran has it's limitations (although I actually like implied do loops and common blocks :) ) but Fortran IV is still probably the world's most portable language. With the exception of the Apple P-system implementation and its 5-byte REALs, they played merry hell with COMMON...

        I do remember at least one implementation of PDP11 Fortran that imposed the PDP linker's 6-character namelength limitation on Fortran progarms, that didn't help readability.

        Now I'm feeling all nostalgic, I wonder where my ADV.FOR source is?

        1. Chemist

          Re: Fortran, indeed

          "Fortran has it's limitations"

          Whilst I'd never write anything completely new in Fortran one of it's big advantages is that there are masses of very-well debugged programs/routines that are readily available to use & modify.

          1. Michael H.F. Wilkinson Silver badge

            Re: Fortran, indeed

            I used Fortran for scientific programming because of the libraries available (one from NAG in particular, got an "Impossible error message" from it by running multiple copies of the same routine in parallel in a shared-memory Cray: multiple copies were using the same named common block, instead of using private copies). This was at the end of the nineties beginning of the noughties. Currently there are many other libraries in many languages available. and anyway, I can always call Fortran routines from C if I REALLY want to. Besides, not all scientific programming needs the kind of numerical algorithms for which many Fortran libraries exist. I do most of my scientific work in C(++) now.

          2. Nigel 11

            Re: Fortran, indeed

            Whilst I'd never write anything completely new in Fortran one of it's big advantages is that there are masses of very-well debugged programs/routines that are readily available to use & modify.

            True

            What's less-well known is that the Fortran language gives a compiler greater scope for generating optimal number-crunching code, because arrays are fundamental entities in the language, not just pointers to data. This was true even with Fortran-77, but subsequent iterations of the language picked up that ball and really ran with it. (Whole-array arithmentic without any explicit loops, slicing, WHERE statements, .... )

            And the advantage grows, as computers can no longer have faster cores, but can have more and more of them, with SIMD instructions adding to the fun.

    2. RobHib
      Flame

      @Ian Bush -- Let's get the nomenclature correct. Eh?

      Please, the capitalisation ... It's Fortran. It's been officially Fortran for almost 25 years now. And if you look at the original Fortran manual

      Heaven forbid, what on earth are you talking about?

      Even your link proves the point that FORTRAN is an acronym and thus uppercase. The 1956 IBM manual to which you refer uses uppercase FORTRAN throughout! The cover is artistic/stylistic licence but dropped-capitals are used for FORTRAN throughout the manual in its body text and full capitals are used in titles.

      In case you're unaware, dropped capitals are UPPERCASE words where the first character is somewhat larger than the others—a practice used by good typographers for clarity since the renaissance—something that's been lost in this cretinous age of internet typography (where everyone* seems to think they're experts on typefaces and layouts). If you look at that manual carefully you may eventually appreciate (a) how well it is written, and (b) the clarity of its layout. Moreover, the careful use of different fonts for the examples etc. makes the manual particularly easy to read.

      It's a damn pity that writers of today don't copy this style—for until the rough-and-ready internet age, that's how most good technical manuals were written!

      BTW, I learned FORTRAN not Fortran—even as I write this, Firefox-26's speller is underlining the lower case word as a spelling error! All my FORTRAN text books use the word FORTRAN and the university's maths department forbade both 'Fortran' or 'fortran'.

      Make sure you get your nomenclature right, I initially learned FORTRAN, not 'Fortran-77'. For many of us, they're two separate languages. The rot set in with FORTRAN 77 when books like FORTRAN 77 Principles of PROGRAMMING by Jerrold L. Wagener (pub. 1980) used 'Fortran' in the text but not on the book's cover (the title of which I've just copied verbatim from my copy). [No, I'm not contradicting myself, Wagener's book is a text on FORTRAN 77, not FORTRAN.]

      ——

      * Chucking away time-tested practices because they've not been learned or understood is unfortunately commonplace nowadays. Even El Reg forcibly (and unnecessarily) removes double spaces between sentences on posts. Double-spaces are a longstanding typographical practice to increase reading clarity, especially where mono-spaced fonts are used.

      1. Phil O'Sophical Silver badge
        Headmaster

        Re: @Ian Bush -- Let's get the nomenclature correct. Eh?

        Nice rant, but no matter what you learned 25+ years ago, the official Fortran 90 standard redefined the name of the language to have only an initial capital, so FORTRAN as a name has been obsolete for 24 years.

        1. RobHib

          @ Phil O'Sophical -- Re: @Ian Bush -- Let's get the nomenclature correct. Eh?

          I'm not disagreeing with you, but it's pretty hard to say that Fortran 90 is the same language that Backus and team wrote in the early 1950s.

          (However, I was more affronted by the fact that the referrer, after only taking time to look at the cover, used that manual to prove his point. Sometimes it helps delve deeper. BTW, I've had a copy of that manual for ages.)

      2. Michael Wojcik Silver badge

        Re: @Ian Bush -- Let's get the nomenclature correct. Eh?

        FORTRAN is an acronym

        While we're being pedantic, it's a portmanteau, and arguably1 not an acronym.

        I personally am willing to allow a fair bit of attitude for "acronym", but regarding "FORTRAN" as one is a bit of a stretch, borrowing as it does seven letters from two words. It's not so much "across" as "through".

        1If you're a descriptivist, then of course "acronym", like any other words, means whatever its users want it to mean, and thus can include portmaneaux. In that case, whether it's an acronym is debatable. If you're a prescriptivist, you're wrong, so we can discard that possibility.

  4. Robert Grant

    Better response times than TCP?

    How do they do that?

    1. JLH

      Re: Better response times than TCP?

      Better latency than a TCP connection, by using Infiniband and RDMA.

      You're looking at 1 microsecond latencies.

      (Of course you can run RDMA over 10Gbps ethernet also)

      http://www.mellanox.com/page/performance_infiniband

      http://www.oracle.com/technetwork/server-storage/networking/documentation/o12-020-1653901.pdf

    2. Michael Wojcik Silver badge

      Re: Better response times than TCP?

      As a general-purpose protocol, TCP is not particularly high-performance.

      On the network, you have several bytes of IP and TCP overhead per packet; you have connection establishment overhead (which of course will be amortized for long-running connections); you have pacing (receive windows, congestion control, etc); you have Nagle/Delayed-ACK iteraction (if it's not disabled); and so forth.

      In the stack, you have several layers of I/O and protocol processing.

      It's not hard to beat TCP for a specific application. It's hard to do better in the general case, supporting the gamut of TCP applications.

  5. qwertyuiop

    Mmmm... Fortran...

    The first programming language I ever learned - back in the halcyon days of 1975. I bet more than 50% of El Reg's readers (and writers!) weren't even born then!

    1. lambda_beta

      Re: Mmmm... Fortran...

      My first FORTRAN was written around 1972. I haven't used it since the middle 80's, but it still was (is) a programming languge which has a great set of libraries. And for everyone who is cocrned about FORTRAN or Fortran .. GET A LIFE!! It started out as FORTRAN (like COBOL) and I don't see any reason to change it!

      1. This post has been deleted by its author

    2. Philip Lewis

      Re: Mmmm... Fortran...

      My university student number, still "tatooed on the ack of my neck" was 761 nnnn denoting my first year as 1976. So I was very definitely alive at that time, and have been "computing" since 1978 IIRC, RSTS/E on the PDP 11/70 IIRC.

      FORTRAN and I never got on. After a chance meeting with a very large and quite sohpisticated business accountig/payroll/project mangement ... system, completely written in FORTRAN (I am a caps guy too), though largely via generated code, I owed that I would avoid it. For this sin I was sent to the purgatory of PASCAL for quite some time, a pig of a language IMHO. Many things followed, but these days I avoid writing code alogether. The children in the office do that.

  6. Derek Thomas

    Hmmmm

    Gets out Fortran IV manual and a pile of punch cards for a trip down memory lane.

    1. keithpeter
      Windows

      Re: Hmmmm

      Very hazy memories of batch processing at University 40 years ago. A Fortran loop that printed 100 blank sheets of line print paper then the formatted output. Very handy for scrap paper. Loved the alternate green and white stripes and the size. I still use A3, Sharpies and a large drawing board for thinking. Punched cards came in handy for revision notes.

      Strangely satisfying that a direct descendant of the language is still around and doing important numerical work (what it was developed for).

    2. RobHib

      @ Derek Thomas -- Re: Hmmmm

      ...And we punch-carders were the first hackers too.

      I remember that for Computing 1.001 student batch runs were limited to 6 sec machine time (on an IBM 360). Progs would often time out if coding wasn't tight or a 'good' algorithm used. Soln: examine the fanfold printouts in the dumpsters outside the computing department then figure out the time limit could be overridden by adding a time switch to the $JOB card. Voilà, extra time!

      Of course, eventually the word got out and the plug pulled when some idiot—there's always one—added a few too many seconds. Those were the days when one could actually watch the card batches being processed, an operator noticed that a batch of cards had seemingly stopped 'flowing' for some reason. ;-)

  7. tojb

    F90 is great

    Back on topic, if OpenMPI can indeed sort out task affinity then that should bring it back in the running as something fit for actual production numerics. Currently, by managing this trick intel's MPI implementation (and perhaps others I haven't tested eg MPICH) leave poor old OMPI in the dust.

  8. Anonymous Coward
    Anonymous Coward

    Musical Interlude

    You write 'FORTRAN'

    I write 'Fortran'

    You write 'BASIC'

    I write 'Basic'

    FORTRAN!!

    Fortran!!

    BASIC!!

    Basic!!

    Let's call the whole thing off

    (with apologies to George & Ira)

  9. Derek Thomas

    The good old days

    1973, Merton Tech and, if I remember correctly, an IBM 1100, an inch high pile of punch cards colour coded by function (data, control and programme), many hours of testing with the result being a full set of times tables from 1 to 20. So much easier now but no where as satisfying.

  10. Paddy

    Fortran libraries resurrected.

    Although I did learn Fortran two decades ago, if I had to use Fortran libraries today I would much rather access them from a Python wrapper i.e. Scipy: http://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fast-if-it-is-written-in-an-interpreted-language-like-python

  11. Tom 7 Silver badge

    I nearly learned FORTRAN at uni

    and then went back after I'd learned a few other languages so I could play with come big mathsy matrix stuff and discovered it works pretty well.

    I've just found a humongous pile of astronomical software writed in it and now am of the opinion that every bit of everything has been written in every language from scratch at least twice.

    If only we had had the internet in the 60's!!!!

  12. Morten Bjoernsvik

    Fortran with openMP

    I've not written much fortran code, but I've benchmarked it and parallelized it using openMP.

    As long as you could identify the serial and parallell part and assured no variable dependencies outside of the parallel part it was just to use the openmp pragmas. worked like a dream.

    !some OMP pragmas I've forgotten:-)

    !$OMP parallel

    do your stuff

    !$OMP end parallel

    1. This post has been deleted by its author

  13. Anonymous Coward
    Anonymous Coward

    I had to learn it for my job :)

    Much as I never wanted to, in a previous incarnation of my current job I had to support a system on VMS called MANMAN. It was all Fortran, so I had to learn enough to understand and maintain the thing.

    I remember that I once deleted some data from the database, and in the process broke one of the monthend reports. Tech Support used to love me, because the usual error reports they got were mostly along the lines of 'program doesn't work, don't know why'. Instead, by the time I contacted Tech Support, the usual message was along the lines of 'Program such and such crashes with an error at program location 23. I have tracked this down to a database read at line such and such, which fails to retrieve the record because it no longer exists. By putting error checking in for the existence of the record when the FETCH is performed, this allows the progam to proceed as planned. Will this fix my problem?' :)

    My crowning glory was mangling the purchase order list utility to allow purchase orders to be output as HTML. Ropey HTML, but it worked... Web enabled purchase order lookup. People thought that ruled!

    1. Philip Lewis

      Re: I had to learn it for my job :)

      Oh dear, another one ...

  14. Herbert Fruchtl

    Long live Fortran!

    Does anybody remember the old "Long live Fortran" essay? "If you can't do it in Fortran, do it in assembly language. If you can't do it in assembly language, it isn't worth doing." "A real programmer can program Fortran in any language."

    But seriously, since about Fortran 95, it does what you need to do. In 2003 they succumbed to the OO nonsense, but that's easy to ignore. (I bet 95% of all C++is actually C, which is a slightly less readable version of Fortran IV with added system calls).

    Whenever I have to write an output parser, I ask myself "Do I spend two days learning Python or one hour writing it in Fortran". And what if I afterwards decide to add something numerical to it, which might actually take more than 20 seconds and involve a matrix?

    Anyway, in an industry that's notoriously youth-obsessed and overrun by one revolution after the other, this old fogey without any formal IT qualifications (in those days we learnt it on the side in physics and chemistry) isn't worried about his job prospects. I should have learnt COBOL, but I have my limits...

    1. RobHib

      @ Herbert Fruchtl -- Re: Long live Fortran!

      ...C, ... a slightly less readable version of Fortran IV with added system calls

      Attempting to deflate youth's superiority complex, eh? ;-)

    2. Michael Wojcik Silver badge

      Re: Long live Fortran!

      I bet 95% of all C++is actually C

      If only. Unfortunately 95% of all C++ is horrible, horrible C++.

      It's possible to write clean, robust, clear, maintainable C++. It's also possible to encounter such in the wild, I've heard, though I've never had the experience (except when running across some of my own code).

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019