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

221–230 of 300 posts

Re: Why physicists still use Fortran (2015)

#221

Post by jxcole »

noobermin wrote: post #135
jxcole wrote: post #89

So the article basically says: 1) Some stuff is already written in Fortran so they don't want to rewrite that. I dig it. 2) It's fast (except C sometimes) but easier to write than c. Like 100x faster than python. I'm not sure about number two. With the gpu processing revolution wouldn't a python/TensorFlow stack be faster than Fortran? Am I missing something? I remember talking to someone who had worked heavily on at…

Dearest me. I hope you're not under the impression that the performant part of your ML code is written in python. Python is the interface to a C++ libary in tensorflow looking at its repo on github. I don't use tensorflow, but if it's anything like numpy and scipy, they are interfaces to C libraries which are extremely performant. If the question is why can't a CFD be in python...and the answer is well, I don't know…

I don't think you understand Tensorflow. Tensorflow compiles tensor mathematics into a shader that can be run on the gpu. This is usually faster than acpu computation.

Re: Why physicists still use Fortran (2015)

#222

Post by gravypod »

sampo wrote: post #99
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…

> auto *my_matrix = new MathArray (); In Fortran, one can choose the matrix size at runtime, though. But otherwise, great. Now if you just add slicing so that if we, say allocate(name_of_array(-1:5, 1:3)) and then say fill in the matrix by 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 then name_or_array(0:4:2,2:3) should return 9 11 13 16 18 20 and then we're talking. (Slicing should of course also work in hi…

If you want to do make an implementation that supports runtime-specified matrix sizes you change your implementation from...

    auto *my_matrix = new MathArray();
Into

    auto *my_matrix = new MathArray(10, 10);
Most programs don't need dynamically sized arrays (rows and columns) and as such it makes sense to also provide a template Row and Column width. By doing this you can likely implement matrix multiplication and addition as a constexpr (with some effort) and thus get....

   1. Compile time matrix evaluation
   2. Vectorized multiplication/addition of matrices
   3. Pipline-efficient code

Re: Why physicists still use Fortran (2015)

#223

Post by CalChris »

rxhernandez wrote: post #68
thicknavyrain wrote: post #47

Earlier quoted context omitted.

Pretty much just size! There was about 20,000 lines of it, it's legacy code that has been gradually added to since the 1980s, so it would have taken a while to rewrite all the parts to work with each other. Perhaps some day though.

20,000 lines of code really doesn't seem like that much. I probably output that much in about 2-3 months of biomedical research so there has to be more to it than that.

20,000 lines of your code is one thing. 20,000 lines of someone else's code is another thing entirely. 20,000 lines of many other people's code can be insane.

Re: Why physicists still use Fortran (2015)

#224

Post by spc476 »

robotresearcher wrote: post #179
bluedino wrote: post #115

Earlier quoted context omitted.

>> Professors usually have this legacy code on hand (often code they wrote themselves decades ago) and pass this code on to their students So cut-n-paste code. The students are running code that they don't really know what it does, it might not even be correct...it's like StackOverflow in academia.

Did you write your own libc and libm? Compiler? We are ALL using code we didn't write.

Daniel J. Bernstein did that for all of his projects (qmail, daemontools, etc) and I don't see him getting a ton of flack over doing that.

Re: Why physicists still use Fortran (2015)

#226

Post by noobermin »

jxcole wrote: post #221
noobermin wrote: post #135

Earlier quoted context omitted.

Dearest me. I hope you're not under the impression that the performant part of your ML code is written in python. Python is the interface to a C++ libary in tensorflow looking at its repo on github. I don't use tensorflow, but if it's anything like numpy and scipy, they are interfaces to C libraries which are extremely performant. If the question is why can't a CFD be in python...and the answer is well, I don't know…

I don't think you understand Tensorflow. Tensorflow compiles tensor mathematics into a shader that can be run on the gpu. This is usually faster than acpu computation.

Alright. I imagine the shader compiler too isn't written in python, is it?

Re: Why physicists still use Fortran (2015)

#227

Post by eesmith »

igouy wrote: post #211
eesmith wrote: post #63

Earlier quoted context omitted.

Moreover, the article mentions this point, references the benchmarks game, and says "However, the two benchmarks where Fortran wins (n-body simulation and calculation of spectra) are the most physics-y".

>> where Fortran wins spectral-norm 1.99s Fortran Intel 1.99s C++ g++ URL provided @quickben

And the full text in the article is:

"However, the two benchmarks where Fortran wins (n-body simulation and calculation of spectra) are the most physics-y. The results vary somewhat depending on whether one compares a single core or quad core machine with Fortran lagging a bit more behind C++ on the quad core."

Though I don't see how the single core version is measured. As far as I can tell, the spectra calculations are always using 4 CPUs while the n-body is always using 1 CPU.

Re: Why physicists still use Fortran (2015)

#228

Post by aswanson »

S4M wrote: post #194
aswanson wrote: post #119

Earlier quoted context omitted.

That quote should be the metric by which code/languages are judged.

How do you measure the complexity of the code, and most importantly, of the problem that the code is solving?

Complexity analysis.

Re: Why physicists still use Fortran (2015)

#229

Post by igouy »

eesmith wrote: post #227
igouy wrote: post #211

Earlier quoted context omitted.

>> where Fortran wins spectral-norm 1.99s Fortran Intel 1.99s C++ g++ URL provided @quickben

And the full text in the article is: "However, the two benchmarks where Fortran wins (n-body simulation and calculation of spectra) are the most physics-y. The results vary somewhat depending on whether one compares a single core or quad core machine with Fortran lagging a bit more behind C++ on the quad core." Though I don't see how the single core version is measured. As far as I can tell, the spectra calculations…

And the article was "Posted on July 16, 2015".

Back-then a second set of measurements were shown with the programs forced to run on one-core, using set-affinity.

Re: Why physicists still use Fortran (2015)

#230

Post by bluetwo »

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…

Why isn't Julia a good choice?
Post reply on HN