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

181–190 of 300 posts

Re: Why physicists still use Fortran (2015)

#181

Post by dangerbird2 »

CardenB wrote: post #170
harigov wrote: post #165

Earlier quoted context omitted.

Just because python is slow doesn't necessarily mean that every library is also slow. With numpy/scipy, which are written in C with python bindings, scientific computation is pretty fast. Python is fast becoming standard language for data science with so many tools like notebooks that make it extremely easy to do many things. I am not sure how well it compares to Fortran but it is no brainer to use it over C++, espec…

Isn’t numpy written in Fortran?

The native code python extensions for numpy are written in C, but numpy often links to matrix libraries written in Fortran like BLAS and LAPACK

Re: Why physicists still use Fortran (2015)

#182

Post by privong »

ChuckMcM wrote: post #62
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…

Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting?

> Now you need to do a follow on study to see how much science the 'rival' group does with a more modern codebase than your 'legacy' group does. Would you know if there are enough examples of two groups who have diverged like this to get meaningful (as in statistically significant) results on the cost benefit of porting / not porting?

I don't know of any studies like this. But there are two aspects to consider. One is what you've pointed out, which is the long-term scientific gains and the productivity of the research group as an entity. But the other aspect is whether those students who rewrote the code into C++ were more or less successful than the students who weren't rewriting code.

Obviously, how you judge success in the latter will be tricky, since there may be differences in the interest of students who rewrote the code and their desired outcome after the PhD (e.g., stay in academia versus go into industry).

Re: Why physicists still use Fortran (2015)

#183

Post by ptero »

DannyBee wrote: post #175
ptero wrote: post #169

Earlier quoted context omitted.

A disclaimer -- I do not work in physics, however a couple of recent physics Ph.D. that I work with expressed similar views. Speed is not nearly as important now as it was 10-15 years ago. A typical scientist's worstation has 20 CPU cores. If I want to use 100 CPUs for a few days, it is trivial and 1000 is easy to get. Thus the fact that Python is slow(er) does not bother me unless I am setting up something major . W…

"Speed is not nearly as important now as it was 10-15 years ago." Please try telling that to other users sometime. They do not seem to agree.

What users? I do work in research and this is what I see almost every time -- doubling the number of CPUs available for a simulation is trivial; getting someone to rewrite existing code to make it twice as fast on the same CPU is hard.

I am not talking about interactive programs -- a slow browser is annoying. I am talking about scientific computing. This is just my experience, can you provide some counterexamples?

Re: Why physicists still use Fortran (2015)

#184

Post by boznz »

Not sure I see the problem, Fortran compilers are quite efficient these days by the sound of the comments. If its not broke, don't fix it.

Just because it's not as "cool" as the language your currently using is not a reason to change and never will be.

Re: Why physicists still use Fortran (2015)

#185

Post by scottmmjackson »

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…

Dude.

https://developer.nvidia.com/cuda-fortran

And no, neural networks aren't suitable for discrete problems.

Re: Why physicists still use Fortran (2015)

#186

Post by robotresearcher »

pletnes wrote: post #59

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. Wra…

> [Fortran is] basically a domain specific language and should be used accordingly.

I read this whole discussion with interest, and I think this is the most compact and insightful statement here. Thinking about it this way makes the situation very clear.

Re: Why physicists still use Fortran (2015)

#187

Post by dguest »

foob wrote: post #100

One of the key points of the article is that there is a lot of legacy code written in Fortran. As a former high energy physicist, I have an anecdote here that some people might find interesting. There was a library written in Fortran called CERNLIB which included a broad variety of miscellaneous numerical algorithm implementations ( e.g. minimization, integration, special functions, random number generation) [1]. I c…

What collaborations are you talking about?

The bigger experiments at CERN use C++14 and python quite a lot. There's still a bit of wrapped FORTRAN code kicking around, and we definitely use rather old school distributions, but I haven't seen anything as bad your anecdote.

Re: Why physicists still use Fortran (2015)

#188

Post by derefr »

jacquesm wrote: post #108
scottlegrand2 wrote: post #74

Earlier quoted context omitted.

David Baker's Rosetta code, which made him a pile of money, is IMO a spectacular example of craptastic C++ written by people who really didn't understand C++ but didn't let that deter them from using every single feature of the language, badly. Some years back we tried to port it to CUDA but there were so many levels of indirection, dereferencing, and virtual functions that it was nearly impossible to make any progre…

That's the whole trick. Good code makes complex stuff look simple. Bad code makes simple stuff look complex.

I wonder if you can formalize this. Assume TDD, and then measure the compressed size of the codebase vs. the compressed size of the test suite. Code is "worse" when it requires more "stuff" (informational entropy) to do less "stuff" (pass test cases.)

The compression would presumably remove the redundancy of the language itself as a factor (including differences in idiomatic cyclomatic-complexity "depths" of various stdlibs), and also remove any redundancy in the way the test cases were specified. So it'd be down to a measure of how much circumlocution and over-engineering you did in the process of implementing the solution.

I'd worry slightly that code-golf solutions would be rewarded, though. Maybe pass everything through an obfuscator + linter before computing the metric, so that things like identifier lengths and spaces aren't considered.

Re: Why physicists still use Fortran (2015)

#189

Post by filereaper »

I've always wondered about the following approach for old apex predators like COBOL and FORTRAN, it follows what .NET does.

The idea is to take current COBOL and FORTRAN code and compile it down to IL similar to .NET's CIL, in the .NET world once code is brought down to CIL it can be read back in VB.NET, C#, C++.NET

Essentially bring it down to some sort of lossless IL to convert to another language. It should be possible to do this given we have the source code. In certain cases where source code doesn't match the binary (happens over years due to monkey patching the binaries etc...) then we'll have to take an approach a few folks at IBM are talking with recompilation and reoptimization of existing old binaries for COBOL. [1]

Don't throw away that debugged and battle-hardened code, change the IL and the final compile target, if possible re-interpret the IL into a newer language if its not lossy.

[1]http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&s...

Re: Why physicists still use Fortran (2015)

#190

Post by mschaef »

filereaper wrote: post #189

I've always wondered about the following approach for old apex predators like COBOL and FORTRAN, it follows what .NET does. The idea is to take current COBOL and FORTRAN code and compile it down to IL similar to .NET's CIL, in the .NET world once code is brought down to CIL it can be read back in VB.NET, C#, C++.NET Essentially bring it down to some sort of lossless IL to convert to another language. It should be pos…

MicroFocus has done COBOL for .Net for years...

https://www.microfocus.com/products/visual-cobol/

"Compile COBOL applications directly to Microsoft intermediate language for deployment within Microsoft .NET... Compile COBOL applications to Java byte code for deployment within the Java Virtual Machine"

I've actually seen this idea suggested, at least as part of a bake-off between design ideas. There's a certain amount of sense to it.

Post reply on HN