Hacker News Reader

> These optimizations will only ever be made if Fortran has wide adoption.

I think you completely fail to realize that Fortran does have wide adoption, and that there is a big market for commercial and open-source Fortran compilers, and that these optimizations have already been made.

I also don't think you realize how much more productive a scientist is with a language that explicitly lacks all the bells and whistles of e.g. C++. Just like how many fiction authors prefer to use old and simple text editing software, hell even mechanical typewriters, while you would argue an iPad with keyboard cover has so much more functionality.

If you want some examples, go have a dig through the OpenFOAM C++ source code [1], and compare it to e.g. the Pencil Fortran code [2]. They're both CFD codes, though the specializations are different. The former can best be characterized as "templates all the way down", throwing you 800-line error messages when you miss a semicolon, while the latter is downright pleasant to install, use, understand and debug in comparison.

[1] https://github.com/OpenFOAM/OpenFOAM-dev

[2] https://github.com/pencil-code/pencil-code

> I think you completely fail to realize that Fortran does have wide adoption, and that there is a big market for commercial and open-source Fortran compilers, and that these optimizations have already been made.

100 times this. Few years ago I personally edited Makefiles in one HPC project to test GCC and clang as possible replacements for PGI. Lemme tell you this: they were joke. Like, 2x slower.

First of all, commercial Fortran compilers can do all the simple optimizations like inlining, loop unrolling etc. And then on top of that, they come with loads of HPC-specific optimizations like autovectorization, loop tiling, loop fusion and hell knows what else. GCC recently seems to be developing in this direction, maybe they'll become competitive at some point or maybe already are, clang was behind GCC last time checked.

In any case, state of the art Fortran compilers are good. And guess what, GCC has a Fortran frontend too. No need to speculate, you can go and test GCC on your codebase now.

In fact, most modern high performance compilers, open source or commercial, have multiple frontends for multiple languages, usually including C and Fortran.

Fortran is fast because there are US-Department-of-Defense-line-item scaled funds to pay for making it fast and there have been funds at that scale for more than half a century.

And it is arguably even more pervasive in the global HPC leader, the department of energy.

It studies nukes.

> I'm assuming these decisions are made because

You're assuming wrong. Feel free to join us in scientific computing and make your case. Many have, and yet we still use fortran alongside the newer stuff.

Perhaps people who disagree with you do so out of something other than ignorance. Just a thought.

If there are reasons that are beyond "I already know Fortran" then please share. As my comment has pointed out the reasons mentioned above are incorrect. Modern C++ compilers, Rust, and Julia all have the edge on Fortran in their use case.

Also, people are now moving away from Fortran. There's a huge push in my field to use python and many students (like me) are't using Fortran.

These are some pretty naive suggestions for how to uproot an entire domain of computing.

Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed. Also, it's pre-1.0 and breaks compatibility frequently. 40-year-old Fortran code runs fine; 2-year-old Julia code is a syntax error.

Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran.

C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran. I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable. The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have, but over the decades it hasn't proven to be a good motivation for redesigning software.

Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code. If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success.

I don't actually know Fortran, but I have huge respect for the people who do. They're the reason most of the things I do are possible and fast.

Julia is JITed, but not in the same sense that (say) JavaScript is. It's more like a very lazy AOT compiler – and it can certainly hold its own against Fortran. That's not to say it has every optimisation it could, but the JIT is not the bottleneck there.

1.0 will be out around midway through the year, so that will ease the growing pains.

> Julia is a JIT language. Whatever edge you get in pretty code is going to be paid for in speed.

That is incorrect. This nonsense that JIT is slow is an old belief that's hung around because it sounds nice. The fact is that the numbers don't line up [0].

> Rust is a nice language, but all of its numerical computing is experimental 0.x stuff. You'll probably end up wrapping another library to do your number crunching. It's probably written in Fortran

It's new and it's growing. It's also a single example for a single case.

But it even still have a comprehensive numeric library [1].

> C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran

I don't know how this could be the case (especially with the addition of shared pointer) but you shouldn't be writing code with huge shared memory dependencies. Use constexpr, use inline, and use functions. There's no need for 20 functions to have shared memory access to a piece of data (which I have seen scientists do).

> I have seen a couple of projects that tried to port Fortran libraries to C++. They came out slower, buggier, and less readable.

That is on the programmers who wrote it, not the language's fault. There's no magical reason that Fortran should be faster then other programming languages. That's like me saying "Some of my friends tried to design a new car engine. Their car came out slower and buggier then my Ford Model T which still runs perfectly". It's anecdotal evidence that doesn't say anything about C++.

> The only reason you'd want to do that is a specific hatred for Fortran -- which you are not the only one to have

I don't have a hatred for Fortran. I just don't see any job where I'd prefer using Fortran over a more-sane alternative. Fortran was great for 77 but isn't great for 17.

> over the decades it hasn't proven to be a good motivation for redesigning software.

Comparability with modern software, improved performance from modern language features, pool of developers, further abstraction of your implementation to remove cruft from the code base using modern language features, and easier deployment are the reasons why we shouldn't be using Fortran.

I mean... when people use Fortran they usually don't even make use of Fortran 90's abstraction features. It's insane.

> Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code.

You are mistaken. NumPy does not contain Fortran in it's code base. SciPy does but it only makes up 25% of the SciPy code base. I have no doubt that within the next 20-50 years that will slowly be removed bit by bit.

Wrapping a legacy library is the first step to replacing it. Once you remove the hard dependancy you will remove

> If you use Python for numerical computing, you are not "moving away from Fortran", you're embracing its success.

No you are definitely moving away from Fortran and towards better tools. The old cruft may still be there but as time moves it will slowly be replaced. You'd never need to use Fortran to get Fortran style speeds with modern software architecture using just python and C [2]. I've seen some crazy projects use this approach and outperform some native C applications.

[0] - https://julialang.org/benchmarks/ [1] - http://rust-num.github.io/num/num/index.html [2] - http://cython.org/

> Fortran was great for 77 but isn't great for 17.

Fortran is not the same in 17 as it was in 77. They are different languages.

> I don't have a hatred for Fortran. I just don't see any job where I'd prefer using Fortran over a more-sane alternative. Fortran was great for 77 but isn't great for 17.

Others do. Plenty of scientific programmers consider Fortran to be a perfectly sane language.

> I mean... when people use Fortran they usually don't even make use of Fortran 90's abstraction features. It's insane.

False. My group does.

> > Of course people like to use Python, but you don't get to use Python instead of Fortran. That would be incredibly slow. You use Python and Fortran. For example, you use NumPy and SciPy, which make Python a great high-level platform for numerical computing because they wrap large amounts of Fortran code.

> You are mistaken. NumPy does not contain Fortran in it's code base. SciPy does but it only makes up 25% of the SciPy code base. I have no doubt that within the next 20-50 years that will slowly be removed bit by bit. Wrapping a legacy library is the first step to replacing it. Once you remove the hard dependancy you will remove

GP never said numpy contained Fortran in its code base, that was a strawman you added. Of course, that is what it means for numpy to provide a high-level platform for numerical computing: it means wrapping current code.

Eh. It's not too much of a strawman. I was under the apparently incorrect impression that there's some Fortran in NumPy, as the NumPy codebase is where f2py comes from. But it could very well not be used in any NumPy operations.

It's still rather important in SciPy.

It was replaced specifically because people were complaining that they had to install gfortran. Not for any performance reasons.

> But it even still have a comprehensive numeric library [1].

I think, by number crunching, they may mean blas/lapack, which is nowhere near replaced by that numeric library...

>> C++ has pointer aliasing shenanigans, so it's hard to make it as efficient as Fortran

>I don't know how this could be the case (especially with the addition of shared pointer) but you shouldn't be writing code with huge shared memory dependencies. Use constexpr, use inline, and use functions. There's no need for 20 functions to have shared memory access to a piece of data (which I have seen scientists do).

Not sure you are understanding what is meant by pointer aliasing. Explicitly marking pointer arguments as 'restrict' in C can have a pretty dramatic speed benefit as the compiler can assume that the memory spaces do not overlap. C++ does not (strictly) have such a feature, unfortunately, and I don't see how shared_ptr/constexpr can fix this (although inline might in some cases)

restrict is pointer qualifier. Reference, even const reference doesn't have restrict-like promise. So potential for overlap still kills C++ speed.

>> Don't assume things are done purely by inertia -- for big projects there are real reasons for the choices made!

> I'm not. I'm assuming these decisions are made because people in physics/ME/chemistry are not programmers and don't know about the latest and greatest our field has to offer. It's our fault for not advertising our successes to these people.

And how many FORTRAN HPC programmers do you know?

So your suggesting that using C++ which has only just had features added that Fortran has had for decades is a good idea?

No that's a single example for a single use case. There are many languages better then Fortran for their use case.

Also, it's not correct to say that C++ only just got a feature fortran had. It only just got the feature in it's standard library. There have existed complex number libraries for C++ for years.

Things like the GSL have been around since 1996.

Not to sound snarky but only know having this as standard and relying on for third party libararies from 1996 doesn't exactly help your point

GSL is the Gnu Scientific Library. It's been around since 1996. Check this for more info: https://www.gnu.org/software/gsl/

It is also practically speaking kind of worthless for actual numerics compared to, say, LAPACK.

People who grouse about Fortran have almost never used it for its intended purpose. It solves a problem, and does so very well. People who mention Julia, Python or Rust as replacements for Fortran simply do not know what they're talking about. You can do equivalent things in C++ or C, but you really shouldn't most of the time. Just as you shouldn't try to code up fancy data structures in Fortran.

> I'm not. I'm assuming these decisions are made because people in physics/ME/chemistry are not programmers and don't know about the latest and greatest our field has to offer. It's our fault for not advertising our successes to these people.

I can understand having some of the other opinions you expressed, but this just seems egregious in the casual assumption that "the latest and greatest" is somehow universally applicable, or specifically applicable to scientific contexts.

Sometimes in some cases new isn't better.

I fully agree and if you look at my other comments in this thread you will see the things that I think are done better and the advantages that I feel modern languages have.

In this case age has something to do with it. There are far fewer people who know fortran, there are far fewer people working on good fortran libraries, and there are languages that can do the same thing that fortran can do.

My issue is that fortran can do the same things (we can argue about speed because that's not really the language's fault) but it has a detraction that other languages don't have. No one outside of very limited subsets of the software development community uses it.

I see that as a huge detraction. Maybe others don't, but I do.

The limited subset of the software dev community is the precise subset you are saying shouldn't use it...

People in my field don't use PHP, either. Doesn't make it a bad language for its purposes, but certainly limited subset.

All the 20-somethings (including myself) in my research group use Fortran.

> No one outside of very limited subsets of the software development community uses it.

Well, sure, but there's nothing wrong with that, it doesn't mean the language is bad, and it certainly doesn't mean that it's wrong to use it.

I'm not saying the language is bad. I'm saying that is a detraction to using the language.

Python has taken off in the scientific community because of the huge amount of code written by non-scientific programmers. Fortran will never benefit from this level of community support.

Scientists aren't interested in abstracting problems, improving libraries, or software organization but those things are important for having a productive, easy to use, and fast language.

Scientists are missing out on the benefits of community support for, in my opinion, no articulable or valid reason.

Some in this thread have said "It's because of number libraries" and others have said that "It's because of speed". I think I have shown, and that cursory research will show, that neither are the case.

Fortran offers nothing that C++, C, Rust, Julia, and Python have that can't be achieved using the respective language. What it does have is a small following who your work can only be appreciated by.

To me writing a program in Fortran is like an English major setting out to write a modern day English dictionary but choosing to write it in 17th century Celtic English.

You can definitely do it, it might be easier for an expert to do it this way, but it will never leave it's audience. Anyone who wants to use your work will need to rewrite it or painfully wrap it. You'll also have perpetual trouble finding people who can work on your project in the future.

C/C++: no convenient array support and ugly, noob-unfriendly syntax. People hate C/C++ type declaration. And don't even mention raw pointers, I have seen first hand how a bunch of clever C programmers can screw up trying to do arrays with these.

Rust: does it even have arbitrarily-indexed multidimensional arrays, again? Are there good compilers? What's the performance on loop-heavy and cache-heavy code? (C at least has this covered). What are the floating point semantics and how do they affect accuracy and optimization opportunities?

Julia: now that's just a Fortran of the 21st century. In few decades bikeshedders will bitch how it doesn't support the latest C++42 features, completely disregarding that understanding C++, especially code written by others, requires pretty much devoting one's life to understanding C++. Not to mention that Julia looks visually different from JavaScript and doesn't even run in the browser. What's this early 21st century Celtic relict even doing here? Don't they get that developers want to use the Web nowadays?

Python: by your own standards it's worse than C because it lacks explicit inlining. QED. Never mind that C doesn't have explicit inlining either :p (hint: read docs).

>Fortran offers nothing that C++, C, Rust, Julia, and Python have that can't be achieved using the respective language.

We are currently preparing to develop and program new classes of algorithms (statistics) for use with (upcomming) Intel MIC processors. I recently succeded with implementing a customized synchronisation procedure based on atomics using Fortran 2008 coarrays. (In my opinion, customized synchronisation procedures allow to enter a new level in parallel programming). To make efficient and safe use of atomics, it was required to make use of several Fortran specific programming techniques, and tricks, that are all together hardly available in any of the other programming languages, at least not easily. (To be honest, Intel ifort does currently not support all of them neither -possibly a bug, I did request on this recently-). Also, to achieve our goal: C++ is too much OOP (runtime polymorphism) whereas C has too less support for objects to allow for highly efficient parallel programming (that's just my personal opinion).

> to achieve our goal: C++ is too much OOP (runtime polymorphism)

That's not a correct statement anymore. There are a few examples of why this statment doesn't hold true but I think the biggest thing to point you to is this talk: https://www.youtube.com/watch?v=zBkNBP00wJE

With constexpr, const, and -O3 you're not going to beat C++ (or C) for any form of embeded-y systems development.

Also.... Phis are supported by OpenCL [0] [1] [2]. This lets you use a number of languages and libraries to better handle your computational tasks [3].

Why use Fortran, C++, or C when Haskell has Accelerate or when Python has ViennaCL [4].

Benifit from the computer science world's work. Don't write your own MPI code that you'll spend 4 months debugging when higher levels of abstraction exist for the problems you want to use. My best bet for you is: either use OpenCL's compute language which is very simple and allows you to do very complex operations completely in parallel on (cheap!) commodity hardware like GPUs for 4 years ago, or learn C++ just enough because the same things are doable using C++ and OpenCL libraries.

It's not too object oriented. Layers of abstraction don't slow code down if they are correctly developed. C++'s compilers and OpenCL have been correctly developed to give you frankly amazing performance for very high level features.

[0] - https://software.intel.com/en-us/iocl_tec_opg [1] - https://software.intel.com/en-us/blogs/2012/11/12/introducin... [2] - http://www.techenablement.com/portable-performance-opencl-in... [3] - http://www.iwocl.org/resources/opencl-libraries-and-toolkits... [4] - http://viennacl.sourceforge.net/

>Benifit from the computer science world's work. (...) Sorry, isn't this a copy and paste from elsewhere? I'd bet I've seen this paragraph some time ago elsewhere.

Nevertheless, our task is not just to write codes that can be executed on the MIC. We must efficiently handle the large number of MIC cores on upcoming HPC systems. What makes the MIC so special is: (a) an increasing number of cores in the near future and, more importantly, (b) we can execute all our existing, highly optimized (vectorized) library codes (C, Fortran 77, IMSL, NAG, or whatever) on the MIC cores. With that we may face two different main approaches for using such many-core hardware: Firstly, we may use massively increasing amounts of data to make better predictions (Big Data, weather forecasting, ...). And secondly, we may use the many cores to develop and program new algorithms to process small data in new ways: With an increasing number of MIC cores, evaluations based on ‘exact values’, as opposed to approximations, will become much more attractive. (Don't take the term ‘exact values’ to literally, in most cases these values are based on approximations as well). That is an important option in those situations where approximations are not available (which is the case with the more sophisticated statistical methods). With today's Fortran, or with PGAS in general, we make a development (away from threading) towards merely (remote) data transfer (through PGAS memory). This allows to write the most sophisticated parallel codes with simple sequential syntax style and brings the amount of required codes for parallel computing to a minimum. Sounds good so far? But the situation is not quite that simple: The (remote) data transfer must be synchronized, i.e. you can only consume the remotely transferred data after some synchronization point. The problem is, if the programmer wants to use the MIC cores efficiently, she/he will need to use some of the cores for distinct purposes and thus, execute distinct parallel codes with different synchronization points on them. This will almost certainly break with what is called ‘ordered execution segments’ (Fortran terminology). ‘Ordered execution segments’ are a very severe limitation for parallel code execution (more precisely: remote data transfer) that is not based on a restrictive programming language but due to some extreme limitation of upcoming HPC hardware. With unordered (user-defined) segment ordering the programer loses nearly all the remote communication channels among the involved cores. Then, the only way left to transmit values remotely are the atomic data types: (binary or integer) scalar values only. Until recently, I had not much hope to circumvent the limitations of such user-defined segment ordering using atomics and thus, not much hope to make efficient use of the MIC cores with current Fortran. Yet, we can not offer professional style programming techniques, but instead some simple, rudimentary Fortran techniques and ‘tricks’ to overcome the limitations of atomics: https://github.com/MichaelSiehl/Atomic_Subroutines--How_the_... Anyone who complains or doubts about Fortran: Try this with your favorite parallel programming language or tool. cheers.

GPUs already beat MICs in core count, performance, price per watt, and initial cost.

Why worry about writing specialized vectorized code? Just by using OpenCL your code will work like that. That's what OpenCL does. You give it chunks of data, you give it a kernel to run, then you run it on your data.

An extremely old AMD cards you can easily find 1280 "core" systems that can push GFLOPS of data through them.

OpenCL is the tool you should use for this. Not a hodge podge of messy fortran code that's been ""vectorized"".

Don't do the compiler's job.

I think we are talking about different things. PGAS is intended to develop more sophisticated parallel LOGIC codes more easily, which is a requirement to handle upcomming MIC hardware. The logic codes itself will play a major role to make efficient use of such hardware and to develop new algorithms for upcomming hardware. I am not against OpenCL or anything else, but consider these as low-level parallelism. The MIC is just starting by now and is very distinct from GPUs. At this time, we are only preparing for the near future.

I'd bet there's more people who know Fortran today than there are who knew Fortran in the 1970s. While scientific programming is no longer dominant in computing, remember that computing itself has grown and expanded into an enormous number of other fields.