Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why physicists still use Fortran (2015)

moreisdifferent.com

Post reply on HN
Print view View original

51–60 of 300 posts

Re: Why physicists still use Fortran (2015)

#51

Post by tmyklebu »

gravypod wrote: post #28

A lot of the arguments in this post can simply be rebutted with basic abstractions. Things like "Dynamically allocating and deallocating ... 2D array" is easy in C++. You could easily have someone define a MathArray class and turn this messy fortran code: real, dimension(:,:), allocatable :: name_of_array allocate(name_of_array(xdim, ydim)) Into something that looks like auto *my_matrix = new MathArray (); The code t…

You're making a pretty big deal about trivial syntactic issues.

> Into something that looks like > > auto *my_matrix = new MathArray();

The dimensions here are a template parameter. They must be known at compile time. Also, if you go this route and you want to write a function that, say, adds two matrices, you get one copy of that function in your binary for every matrix size that occurs in your program. You also can't naturally interoperate with someone else's matrix code unless that someone else specifically wrote against your MathArray template class.

> And if you'd really like you can hide the sizeof via a macro... > > #define MATRIX_MAKE(r, c, type) matrix_make(r, c, sizeof(type)) > > For me "real, dimension(:,:), allocatable :: " is much more complicated than "matrix_make"

It looks uglier, but it's language syntax rather than custom code. Whoever is reading your code doesn't have to unpack a macro and then look into a function to figure out what you're doing. (And as a bonus, the Fortran user can index the matrix without mentioning that it's a 'double' matrix when he's indexing.)

> Many of the issues people see in the speed difference between Fortran and C code will likely be based on their misunderstanding of how Fortran actually does their data layout and a misunderstanding of how the computer hardware (and what you're describing to C) to do. This "Double array" that was defined would never be allowed in production code. The amount you'd be hitting the OS for even small allocations is crazy.

Which many issues are you thinking about? Idiomatic Fortran has an inherent advantage over idiomatic C in that better aliasing information is available to the compiler.

Re: Why physicists still use Fortran (2015)

#52

Post by diminish »

serf wrote: post #39
thicknavyrain wrote: post #24

"Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students. This saves their students time, and also takes uncertainty out of the debugging process." This is so true. I'm a PhD student in physics using Fortran for pretty much that reason. At the start of my PhD, in response to my supervisor telling me I should learn Fortran to modify our cu…

His response was "You could do that and it would probably be enough to earn your PhD, since it'll take you at least three years. But I suspect you'll want to work on something else during that time". as someone who had contact with that codebase, do you have any insights as to why that is? Was it the sheer size of the thing? Was it some nuance that Fortran had as an advantage over other languages? was the math just d…

I have reimplemented all Fortran code of my professor at CERN in C during several undergrad classes during my Physics major. Then I have quited physics and became a developer.

Re: Why physicists still use Fortran (2015)

#54

Post by pletnes »

ryl00 wrote: post #21
cratermoon wrote: post #17

Earlier quoted context omitted.

Is MS Fortran still a supported product? I'm not sure I'd call software that depends on unsupported and unmaintained other software properly maintained.

I may be mistaken but I believe the Intel Fortran compiler supports the MS Fortran extensions

There are some caveats AFAIK. Intel changed some default behaviors. I believe you can change them with a command line switch though. Of note is the SAVE property on all local variables being the default on MS. Now that’s an insane default if there ever was any!

Re: Why physicists still use Fortran (2015)

#55

Post by pletnes »

quadruplebond wrote: post #14
dahart wrote: post #5

> Interestingly, C/C++ beats Fortran on all but two of the benchmarks, although they are fairly close on most. I think this is fairly recent that C/C++ wins. I don’t know how recent exactly, but I remember a colloquium not too long ago by a compiler researcher who said that cross-compiling to Fortran and then optimizing almost always produced faster code than the C/C++ compiler could. Fortran is apparently easier to…

For science codes, where Fortran is still used, the most expensive pieces (think DGEMM Kernel) are largely written in architecture dependent ASM anyways so programming language doesn't have that much of an effect on the most time critical pieces of large HPC programs. If a specific function is important enough it will be hand optimized in a way that the language doesn't really matter. Sometimes that means calling MKL…

DGEMM doesn’t necessarily win over MATMUL for small matrices. Useful in e.g rotation matrices in finite element codes, and lots of other areas. Since matmul can be done with inlined loops, you also avoid the function call overhead, but it looks like a function call which is good for readability.

Re: Why physicists still use Fortran (2015)

#56

Post by pletnes »

quadruplebond wrote: post #15
nine_k wrote: post #12

Earlier quoted context omitted.

Some of the Numpy code is coming from 1970s: it uses BLAS that originates from 1979. https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra... Immense amount of effort was put in performance, correctness, feature set, and numerical stability of such widely used libraries. Replacing the without a very good reason is hardly feasible.

Blas is an interface, All performant blas libraries need to written to specifically take advantage of modern hardware. Things like NetLib exists as reference implementations, they are not high performance. The point I am trying to make is that Numpy is unlikely to still be using the exact same code that was written in the 1970's unless its performance isn't critical. It is making the same function calls but the actua…

Numpy can use optimised BLAS but I believe it ships with an f2c transpiled reference BLAS so it can run (although slower) without Fortran where necessary.

Re: Why physicists still use Fortran (2015)

#57

Post by pletnes »

gravypod wrote: post #18
grahameb wrote: post #9

On array convenience: Fortran also supports optional runtime bounds checking of array indexes. I've worked writing signal processing code in Fortran, and it's really quite nice to have that when doing dev, even if you turn it off in prod for performance reasons.

GCC/G++ will remove bounds checking on O3 I think.

It’s a separate flag, independent of optimization, on all Fortran compilers I’ve used AFAIR (nag, intel, pgi, gfortran).

Re: Why physicists still use Fortran (2015)

#58

Post by eesmith »

nine_k wrote: post #12
rcarmo wrote: post #10

A slight gap in knowledge in the piece: Most Python libraries for numerical computation are written in C/C++ or... Fortran. Last time I had to compile scipy from scratch I had to install gfortran.

Some of the Numpy code is coming from 1970s: it uses BLAS that originates from 1979. https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra... Immense amount of effort was put in performance, correctness, feature set, and numerical stability of such widely used libraries. Replacing the without a very good reason is hardly feasible.

Some from the 1960s. Quoting numpy/lib/function_base.py:

    We use the algorithm published by Clenshaw [1]_ and referenced by
    Abramowitz and Stegun [2]_, for which the function domain is ...
    .. [1] C. W. Clenshaw, "Chebyshev series for mathematical functions", in
           *National Physical Laboratory Mathematical Tables*, vol. 5, London:
           Her Majesty's Stationery Office, 1962.
    .. [2] M. Abramowitz and I. A. Stegun, *Handbook of Mathematical
           Functions*, 10th printing, New York: Dover, 1964, pp. 379.
           http://www.math.sfu.ca/~cbm/aands/page_379.htm
Quoting numpy/core/src/npymath/npy_math_complex.c.src:

    /* Algorithm 312, CACM vol 10, Oct 1967. */
    if (a >= 0) {
        t = npy_sqrt@c@((a + npy_hypot@c@(a, b)) * 0.5@c@);
        result = npy_cpack@c@(t, b / (2 * t));
    }

Re: Why physicists still use Fortran (2015)

#59

Post by pletnes »

Fortran is much easier to use than its direct competitors if you are writing array-based number crunching. For all other used, it’s hopelessly outdated. If I were to explain its purpose to a non-fortran programmer, I’d say that Fortran is useful for number crunching kinda like regular expressions are great for certain text processing tasks. It’s basically a domain specific language and should be used accordingly. Wrap in C++ or f2py and call the routines from python/C++, where you do the «software parts»: IO, GUI, ...

That being said, I usually just use python and surf on other people’s hard work!

Oh, and the author is wrong on many of the specific details. For instance, MPI is available to many languages, including python.

Re: Why physicists still use Fortran (2015)

#60

Post by ryl00 »

cm2187 wrote: post #35
nine_k wrote: post #12

Earlier quoted context omitted.

Some of the Numpy code is coming from 1970s: it uses BLAS that originates from 1979. https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra... Immense amount of effort was put in performance, correctness, feature set, and numerical stability of such widely used libraries. Replacing the without a very good reason is hardly feasible.

I needed a .net math library. My IT department insisted on my trying a wrapper around a Fortran library (I believe purely because they had a license already). All the classes and variables names are short hexadecimals strings. None of the interface is idiomatic to .net (the library only has void returning methods which pass error codes as byref arguments instead of using exceptions, requesting a parameter for the len…

Sounds like your IT department botched the wrapper. Wouldn't a more successful candidate likely just have used an abstraction layer between the .net conventions you were expecting and whatever the native code was doing?
Post reply on HN