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

Learning Fortran (2024)

uncenter.dev

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Learning Fortran (2024)

#71

Post by thatjoeoverthr »

sampo wrote: post #66
thatjoeoverthr wrote: post #19

I actually had a fantastic experience with Fortran lately. I ported a compute kernel from python/numpy to Fortran 2018, partially due to the GIL and partly so I could use Intel's compiler. The performance improvement was tremendous. Several times faster per core, then multiplying further because I could take advantage of threading. In all, the 3 day project increased actual throughput 450x. (I considered JAX, but the…

> Suppose you pass a parameter, N, and you also would like to pass a tensor, and you would like to specify the tensor's shape (N, N). You can do that, and it might be cleaner and less lines of code that way. But you don't necessarily need to pass the array dimensions as a parameter, as you can call `size` or `shape` to query it inside your function. program main implicit none real :: a(2, 2) = reshape([1., 2., 3., 4.…

True! I just wanted to highlight it. (I had to do this at an interface because the ABI doesn’t pass the shape.)

Re: Learning Fortran (2024)

#72

Post by thatjoeoverthr »

drnick1 wrote: post #63
thatjoeoverthr wrote: post #19

I actually had a fantastic experience with Fortran lately. I ported a compute kernel from python/numpy to Fortran 2018, partially due to the GIL and partly so I could use Intel's compiler. The performance improvement was tremendous. Several times faster per core, then multiplying further because I could take advantage of threading. In all, the 3 day project increased actual throughput 450x. (I considered JAX, but the…

Any reason why you couldn't do this in C/C++? I use the Eigen matrix library as a replacement for Numpy when I need more performance and the code looks surprisingly very similar.

Of course I could in C.

Intel and Nvidia are both offering both C and Fortran compilers, so I was looking at both. I know C well but I decided to not look at it as a presumed default.

When I used C like this in the past, the intrinsics were very low-level, e.g. wrapping specific Altivec or SSE instructions or whatever. I see see it has OpenMP intrinsics, though, which I’m sure I’ll try later.

If I use a library, I’m breaking up the operations and don’t give the optimizing compiler an opportunity to take operations into account together.

With Fortran, I can give the operations directly to the compiler, tell it the exact chip I’m working with and it deals with it.

It would be fun, when I have some time, to go rewrite it in C and see how it compares.

Re: Learning Fortran (2024)

#73

Post by Joker_vD »

PaulHoule wrote: post #50
foxglacier wrote: post #43

Earlier quoted context omitted.

Yea, Fortran is nice to use for so-called "scientific" computing. It has high performance as well as some handy intrinsic functions like DOT_PRODUCT and TRANSPOSE but the best features to me are colon array slicing syntax like Python/Numpy and arrays being indexed from 1 which makes converting math equations into code more natural without constantly worrying about off-by-one errors. I wouldn't call multi-dimensional…

e.g. "tensors" are like "vectors" in they transform in a specific way when the coordinate system changes; what felt so magic about vectors as an undergrad was that they embody "the shape of space" and thus simplify calculations. If you didn't have vectors, Maxwell's equations would spill all over the place. Tensors on the other hand are used in places like continuum mechanics and general relativity where something mo…

> If you didn't have vectors, Maxwell's equations would spill all over the place.

What do you mean, "would": they did! :) The original equations had 20 separate equations, although Maxwell himself tried to reformulate them in quaternions. But if you look e.g. at works of Lorentz, or Einstein's famous 1905 paper, you'll see the fully-expanded version of them. The vector form really didn't fully catch until about the middle of the XX century.

Re: Learning Fortran (2024)

#74

Post by lioeters »

Joker_vD wrote: post #73
PaulHoule wrote: post #50

Earlier quoted context omitted.

e.g. "tensors" are like "vectors" in they transform in a specific way when the coordinate system changes; what felt so magic about vectors as an undergrad was that they embody "the shape of space" and thus simplify calculations. If you didn't have vectors, Maxwell's equations would spill all over the place. Tensors on the other hand are used in places like continuum mechanics and general relativity where something mo…

> If you didn't have vectors, Maxwell's equations would spill all over the place. What do you mean, "would": they did! :) The original equations had 20 separate equations, although Maxwell himself tried to reformulate them in quaternions. But if you look e.g. at works of Lorentz, or Einstein's famous 1905 paper, you'll see the fully-expanded version of them. The vector form really didn't fully catch until about the m…

This sounds like an interesting thread to follow. From a cursory search, it seems vector calculus was being used by the early 1900's to reformulate Maxwell's equations, then later with notations like differential, integral, and matrix forms. I'll read more and see if I can understand the gist of each major step of the process over the years, how the notation affected the way mathematicians thought about the equations, and "made them easier to work with".

And how Fortran has unique properties that make converting math equations into code "more natural". Intriguing, I'll to dig deeper for intellectual curiosity.

Re: Learning Fortran (2024)

#75

Post by adrian_b »

Luminary099 wrote: post #54
atrettel wrote: post #8

The article did not discuss this, but to me, one of the bigger differences between Fortran and more modern languages is the difference between functions and subroutines. Yes, they are not synonyms in Fortran and serve different purposes. I think this would trip up more people initially than the clunky syntax. It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when…

Huh, I remember actually being taught this at school, but they never bothered to give (or I never bothered to remember) an example of a programming language that actually named void functions differently or indeed why it couldn't just be a void function. Looking at it now, it seems to be a difference inherited from mathematics, which would also explain why it's in Fortran too.

The main difference between functions and subroutines in Fortran and other ancient programming languages is not the fact that subroutines do not have a return value.

The functions of Fortran are what would be called pure functions in C (which can be marked as such with compilers that support C language extensions, like gcc).

The pure functions cannot modify any of their arguments or any global variable, and they must be idempotent, which is important in program optimization.

Re: Learning Fortran (2024)

#76

Post by adrian_b »

IAmBroom wrote: post #42
atrettel wrote: post #8

The article did not discuss this, but to me, one of the bigger differences between Fortran and more modern languages is the difference between functions and subroutines. Yes, they are not synonyms in Fortran and serve different purposes. I think this would trip up more people initially than the clunky syntax. It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when…

What practical difference ever existed, beyond the fact that a subroutine does not return a value? AFAIK variable scope was handled identically. Recursion was likewise identical (forbidden originally).

The very important difference is that what are called functions in Fortran are called pure functions in other languages, i.e. functions that do not modify their arguments or global variables and which are idempotent, helping program optimization.

This means that Fortran functions are functions in the mathematical sense. In most early programming languages "functions" were functions in the mathematical sense, while other kinds of subprograms were named procedures or subroutines. The use of the term "function" for any kind of procedure has been popularized mainly by the C language, even if there were earlier languages where all procedures could return a value and even where any program statement was an expression, starting with LISP.

Many C/C++ compilers, e.g. gcc, support language extensions allowing functions to be marked as pure. This is always recommended where applicable, for better program optimization.

This difference is much more important than the fact that subroutines do not return a value.

Many of the "functions" of C/C++ must be written as subroutines in Fortran, with an extra argument for the result, but because they modify some arguments or global variables, not because they were written as "void" functions in C/C++.

Re: Learning Fortran (2024)

#77

Post by adrian_b »

semi-extrinsic wrote: post #52
IAmBroom wrote: post #42

Earlier quoted context omitted.

What practical difference ever existed, beyond the fact that a subroutine does not return a value? AFAIK variable scope was handled identically. Recursion was likewise identical (forbidden originally).

Functions return a value, subroutines do not. So functions can, at the whim of the compiler, cause an extra copy. Style wise, many prefer to reserve functions for things that resemble mathematical functions (i.e. only intent(in) and pure). In some sense a little bit similar to how people tend to use lambdas in python.

In a well designed programming language, the compiler should always decide at its whim, whether input or output parameters need an extra copy or not, i.e. if they should be passed by value or by reference.

The programmer must only specify the behavior of the parameters, i.e. if they are input, output or input-output parameters, like in Ada.

The fact that a parameter is the result is just a matter of syntax, not of semantics. Any other output parameters should behave exactly like the result. This means that for any output parameter, like also for the result, the compiler must decide between receiving the output value in a register or passing an extra pointer on input that is the address of a memory area where the function must write the output value.

Re: Learning Fortran (2024)

#78

Post by auraham »

whynotmaybe wrote: post #24
atrettel wrote: post #8

The article did not discuss this, but to me, one of the bigger differences between Fortran and more modern languages is the difference between functions and subroutines. Yes, they are not synonyms in Fortran and serve different purposes. I think this would trip up more people initially than the clunky syntax. It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when…

> difference between functions and subroutines. Waitaminit, is that why we have "sub" in Visual Basic ?

I was about to mention that.

Re: Learning Fortran (2024)

#79

Post by adrian_b »

adastra22 wrote: post #64
atrettel wrote: post #55

Earlier quoted context omitted.

They are pretty similar, but they are definitely used differently. For one, you have to "call" a subroutine in one statement, but you can use multiple functions on the same statement (since they can return values). Functions (usually) do not change their arguments, but subroutines often do. In some sense, functions are closer to how mathematical functions work but subroutines are closer to labels for certain procedur…

So they are used differently, but there isn’t a language enforced difference (other than return value)?

There is a language enforced difference.

Fortran functions correspond to "pure" functions in C/C++ and other languages, i.e. idempotent functions that do not modify arguments or global variables.

If a C/C++ function is converted to Fortran, it must be rewritten as a subroutine, unless it is a pure function.

Not all C/C++ compilers support the language extension of marking functions as pure, and even with such compilers many programmers are lazy, so they forget to mark as pure the functions where this is applicable, even if this is recommended for improving program optimization and verification.

Fortran function were pure functions because this is the mathematical sense of the term "function". The extension of the meaning of the word "function" for any kind of procedure happened decades after the creation of Fortran.

The distinction between a "void" function and other functions has negligible importance. On the other hand the distinction between "functions" in the C language sense and "pure functions" is very important and programmers should better mark as "pure" all the functions for which this is true. This is at least as important for program optimization and for checking program correctness as declaring a variable with the correct type.

Re: Learning Fortran (2024)

#80

Post by pklausler »

adrian_b wrote: post #79
adastra22 wrote: post #64

Earlier quoted context omitted.

So they are used differently, but there isn’t a language enforced difference (other than return value)?

There is a language enforced difference. Fortran functions correspond to "pure" functions in C/C++ and other languages, i.e. idempotent functions that do not modify arguments or global variables. If a C/C++ function is converted to Fortran, it must be rewritten as a subroutine, unless it is a pure function. Not all C/C++ compilers support the language extension of marking functions as pure, and even with such compile…

> Fortran functions correspond to "pure" functions in C/C++ and other languages, i.e. idempotent functions that do not modify arguments or global variables.

This is nonsense. Fortran functions aren't pure. They can have side effects.

HPF/Fortran '95 added the PURE attribute for subprograms, but it's not the default.

Post reply on HN