[HN Gopher] Toward Modern Fortran Tooling and a Thriving Develop...
___________________________________________________________________
Toward Modern Fortran Tooling and a Thriving Developer Community
Author : milancurcic
Score : 45 points
Date : 2021-09-16 16:56 UTC (6 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| NikolaeVarius wrote:
| Long live Fortran. Learned it for some CFD applications. I don't
| understand all the devs who think Fortran is some dead language
| that nobody uses.
| leephillips wrote:
| Such "devs" are primarily familiar with computers as
| communications devices for serving advertising over the web.
| Fortran is not popular in this area.
| ogogmad wrote:
| "Fortran is the oldest high-level programming language that
| remains in use today"
|
| This is like the ship of Theseus, except where the ship has
| changed from a fishing vessel to a dreadnought.
| jhgb wrote:
| Battleship of Theseus it is, then.
| [deleted]
| glial wrote:
| I've used Fortran for scientific computing work, mainly because
| it's ultra-fast and my advisor still used it. If we are going to
| invest a high-performance computing ecosystem and community, why
| would Fortran make more sense than e.g. Rust?
|
| (I have never used Rust for anything but HN seems to love it)
| milancurcic wrote:
| Author here, so I'm biased toward Fortran, though I've been
| enjoying learning Rust as well. I think there are a few
| reasons.
|
| First, Rust's multidimensional arrays are either limited and/or
| difficult to use. Fast, flexible, and ergonomic
| multidimensional arrays and arithmetic are essential for HPC.
| They are _possible_ with Rust, but my two favorite Rust books
| not mentioning them suggests to me that they 're not the focus
| of the language. This may or may not change in the future.
|
| Second, Rust may be too complex to learn for scientists who
| aren't paid to write software but to do research. Fortran is
| opposite--multidimensional whole-array arithmetic looks like
| you would write it as math on a whiteboard. While scientists
| can sure learn to program Rust effectively, I think most
| scientists don't think like Rust, but they do think like
| Fortran. For somebody not familiar with Fortran but familiar
| with Python, I'd say Fortran very much feels like NumPy.
|
| Third, such ecosystem would be built in Rust from scratch. In
| Fortran, most of the value is already there, but needs to be
| made more accessible with better and more modern tooling. For
| example, Fortran's fpm (https://github.com/fortran-lang/fpm) is
| largely modeled after Rust's Cargo because we recognize the
| importance of good user experience when it comes to building
| and packaging software. With the recent Fortran-lang efforts,
| we study many programming language ecosystems and communities
| (e.g. Python, Julia, Rust, etc.) to find what could work best
| for modern Fortran tooling.
| zozbot234 wrote:
| > Third, such ecosystem would be built in Rust from scratch.
|
| Rust can actually interoperate quite seamlessly with external
| libraries, and make its own libraries available to other
| languages. You're quite right that the support for even
| simple numerics in Rust isn't quite stable just yet, so it's
| not ready for productive use. But it can get there, to a far
| greater extent than C/C++.
| bondant wrote:
| One reason would be that Fortran has proven itself in the HPC
| area. Another one would be that it is a much simpler and easy
| to learn language than Rust (so can quickly train students,
| PhDs and so on to improve your simulation code, even when they
| have no programming background).
|
| In most of the HPC codes I've worked with there are no
| complicated memory management, most of the things are arrays
| usually declared and allocated at launch time and that's it, no
| more memory management after that. So I'm not sure what rust
| would bring on the table, but maybe I'm just missing it.
| jandrewrogers wrote:
| Fortran makes sense to the extent there is a lot of battle-
| tested and highly optimized numerics code written in it. It was
| mostly replaced by C and (legacy) C++ for new code when I last
| worked in HPC many years ago. Fortran is not an ergonomic
| language for most types of software by modern standards and
| performance parity was achieved a long time ago. I used all
| three languages.
|
| Rust doesn't solve many problems for HPC, and HPC still often
| involves weird hardware targets compiling from some dialect of
| C or C++. A bit like embedded but without the market scale to
| justify tool investment. Fortran and Julia are more likely
| targets for a second language for the obvious reasons.
|
| Another issue is that some HPC silicon has unusual low-level
| concurrency and memory semantics with no analogues in ordinary
| CPU architectures. At least in some cases, I suspect it would
| be require non-trivial modification of Rust's safety checking
| to allow it to work correctly on that silicon.
| zozbot234 wrote:
| > Another issue is that some HPC silicon has unusual low-
| level concurrency and memory semantics with no analogues in
| ordinary CPU architectures
|
| As long as it's properly reflected in the LLVM IR, I don't
| think this would be an issue.
| leephillips wrote:
| The languages that have proven to be effective for high-
| performance computing are Fortran, Julia, C, and C++; but only
| the first two are convenient media for the scientific
| programmer. Recent activity in scientific computation is moving
| to Julia, but the vast amount of existing Fortran code makes
| this effort around tooling worthwhile.
| Bostonian wrote:
| "Recent activity in scientific computation is moving to
| Julia"
|
| I'm not saying you are wrong, but I wonder what metric you
| are using.
| pjmlp wrote:
| I guess this project list is a possible metric.
|
| https://juliacomputing.com/case-studies/
| leephillips wrote:
| That's a fair question. I can't claim to have anything that
| would merit being called a "metric". The number of papers
| and projects using Julia increases every year, but that in
| itself doesn't quite support my claim. What I mean is that
| there are regularly new large-scale computational projects
| adopting Julia, and they are the types of projects that, in
| most cases, I'm pretty sure would have used Fortran seven
| years ago.
| certik wrote:
| Co-author here. If you have any feedback on our work or any
| questions, please let us know. I'll be happy to answer.
___________________________________________________________________
(page generated 2021-09-16 23:01 UTC)