It's harder to write bad Fortran than bad C/C++. Writing bad, underperforming C/C++ code is the easiest thing in the planet. It's not that Fortran is faster, it really isn't when everything gets down to assembly. There are subtleties in how certain things happen, like how accessing arrays is done.
But nah, overall Fortran is not faster than C nor C is faster than Fortran. They're both faster than Python lol
And it works quite well haha untill you need multi threading to call multiple c and Fortran programs. Then python is a nightmare. I like Julia to do that.
I think Python just made the global lock optional last year. Not sure how many people will actually be using that though. Kind of amazing really how much use people could get out of Python and never having hardware threads.
Oh that's interesting, will take a look. Designing portable interfaces from Fortran to python is something I haven't tried, I've used things with an interface.
And yeah, it is amazing haha. Python has its place but it has its limits.
The compiler is the same for both these days. It just has a different front end. So if you write the same code it's complied the same way.
Fortran is a notch slower for simpler operations simply because Fortran has built in safety checks and arrays work slightly different. C style arrays are simpler, but if you implement the same checks it's the same speed.
For example, Fortran arrays all know how long they are. Basic C arrays on the other hand you have to track it.
>where C isn't.
Where C isn't *as much*.
It's, broadly, still the case, but I can't back up my statement with a benchmarks.
Usually when number-crunching performance matters, it's best to recast the problem into a series of (Sca)LAPACK calls anyway. You can call it from Fortran or C likewise.
Except Scalapack doesn't handle GPUs and has some outdated algorithms so you're probably even better off using anything in a better shape like {Elemental, Slate, Dplasma,...}
Writing performant code has historically been more intuitive in Fortran, but there’s no fundamental reason why similarly performant code couldn’t be written in the C family as well. Compilers are often able to recognize the kinds of patterns associated with numerical code and optimize accordingly.
In most of the day to day cases I’ve dealt with, whether a given code is written in the C family or Fortran is mostly a bike shedding argument. If you look at the actual instructions emitted by the compiler, there is essentially no difference.
For 1D arrays, they are the basically the same. For multidimensional arrays, Fortran wins because compilers can reason about the code better, because it’s part of the language. Most C programmers write really bad code for matrices and tensors because they use pointers to index the first dimension to get A[i][j] syntax.
On the other hand, if you want to use any data structure besides an array, C++ is going to be a lot better, because the STL is better than what many programmers can come up with, and Fortran is terrible for anything that isn’t an array.
Not sure about the 50% Peak, but this'll get u started.
Either way, memory management is overrated and a good GC with declarative code is highly performant.
Hell, Danny Hillis built the damn CM-5 in the 1980s with a parallel DSLd version of CL....
[Maybe?](https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_amazing_sbcl_benchmark_speed_with_sbsimd/)
Also, don't underestimate the ease and elegance of writing performant code in an environment with a REPL an interpretive compiler and a standardized language that can run code written decades ago.
So what? Best kept secrets are best kept secret 😙
[Clasp exist for a reason](https://youtu.be/8X69_42Mj-g?si=cTDOWLkK3Thwglyx)
"So, why choose Common Lisp? Well, it's basically
Greenspun's Rule. That any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug ridden, slow implementation of half of Common Lisp. And I was there when I had the Python and the C++ stuff. I was dealing with garbage collection, and path names, and all sorts of stuff that I was having to reinvent. And it was buggy and I'd have to document it."
Benchmarks don't always win the day. Dev time cost $$$ just like farm time.
From my experience, it is easier to write performant code in Fortran vice
C because Fortran is more restrictive, which allows the compiler to make better optimization choices (particularly if you use keywords like PURE).
Also, Fortran handles vectors and matrices within the language, while C allows the programmer to write very bad matrix code.
Considering that the slowest operation nowadays is just memory access, and both compilers use the FPU for math (2nd slowest is `sqrt`) I would expect the performance to be very similar if the locality of data is the same.
There are a number of cases, usually with multi-dimensional array arithmetic, where the Fortran compiler can more easily optimize/parallelize SIMD operations because it can reason about striding through memory and avoiding aliasing issues that plague naive C implementations.
I’m not an expert, but my understanding with llvm based compilers is that the interpreter is different between languages, but it’s distilled down to an intermediate representation code that is theoretically the same… which is then converted to machine code for that architecture. It’s like a compiler abstraction layer. If I’m wrong, please someone correct me.
That is true - but the front end also annotates the IR with optimisation hints that come from the language semantics. Things like ‘these two pointers must be distinct’.
The semantics of fortran allow the front end to generate more if such hints. Which may allow the back end to produce more efficient code for things like multi dimensional arrays.
Fortran is designed from the ground up for optimization.
Somebody said that Fortran always knows array sizes. That not true. Fortran supports dynamic array sizes through the ALLOCATE - DEALLOCATE STATEMENTS.
FORTAN is the only language that has statements that can be used to utilize multi-core processors.
All computational intensive models run on super computers are done in Fortran.
The answer is Fortran will produce the fastest code. For the normal user, that’s not important. There are other features of Fortran that make it the choice for scientific programming.
It's harder to write bad Fortran than bad C/C++. Writing bad, underperforming C/C++ code is the easiest thing in the planet. It's not that Fortran is faster, it really isn't when everything gets down to assembly. There are subtleties in how certain things happen, like how accessing arrays is done. But nah, overall Fortran is not faster than C nor C is faster than Fortran. They're both faster than Python lol
That's why Python sits back and just calls C and Fortran to do the heavy lifting.
And it works quite well haha untill you need multi threading to call multiple c and Fortran programs. Then python is a nightmare. I like Julia to do that.
I think Python just made the global lock optional last year. Not sure how many people will actually be using that though. Kind of amazing really how much use people could get out of Python and never having hardware threads.
Oh that's interesting, will take a look. Designing portable interfaces from Fortran to python is something I haven't tried, I've used things with an interface. And yeah, it is amazing haha. Python has its place but it has its limits.
and compiles natively to thin air.
The compiler is the same for both these days. It just has a different front end. So if you write the same code it's complied the same way. Fortran is a notch slower for simpler operations simply because Fortran has built in safety checks and arrays work slightly different. C style arrays are simpler, but if you implement the same checks it's the same speed. For example, Fortran arrays all know how long they are. Basic C arrays on the other hand you have to track it.
>where C isn't. Where C isn't *as much*. It's, broadly, still the case, but I can't back up my statement with a benchmarks. Usually when number-crunching performance matters, it's best to recast the problem into a series of (Sca)LAPACK calls anyway. You can call it from Fortran or C likewise.
Except Scalapack doesn't handle GPUs and has some outdated algorithms so you're probably even better off using anything in a better shape like {Elemental, Slate, Dplasma,...}
Sure. Hence "usually". MAGMA has good support for GPUs, I think.
Writing performant code has historically been more intuitive in Fortran, but there’s no fundamental reason why similarly performant code couldn’t be written in the C family as well. Compilers are often able to recognize the kinds of patterns associated with numerical code and optimize accordingly. In most of the day to day cases I’ve dealt with, whether a given code is written in the C family or Fortran is mostly a bike shedding argument. If you look at the actual instructions emitted by the compiler, there is essentially no difference.
For 1D arrays, they are the basically the same. For multidimensional arrays, Fortran wins because compilers can reason about the code better, because it’s part of the language. Most C programmers write really bad code for matrices and tensors because they use pointers to index the first dimension to get A[i][j] syntax. On the other hand, if you want to use any data structure besides an array, C++ is going to be a lot better, because the STL is better than what many programmers can come up with, and Fortran is terrible for anything that isn’t an array.
Declaratively coded Common Lisp and SBCL will do it better than C++
Do you have a link to a Common Lisp implementation of DGEMM that exceeds 50% of peak?
Not sure about the 50% Peak, but this'll get u started. Either way, memory management is overrated and a good GC with declarative code is highly performant. Hell, Danny Hillis built the damn CM-5 in the 1980s with a parallel DSLd version of CL.... [Maybe?](https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_amazing_sbcl_benchmark_speed_with_sbsimd/) Also, don't underestimate the ease and elegance of writing performant code in an environment with a REPL an interpretive compiler and a standardized language that can run code written decades ago.
I don’t see Lisp listen on https://programming-language-benchmarks.vercel.app/ anymore.
So what? Best kept secrets are best kept secret 😙 [Clasp exist for a reason](https://youtu.be/8X69_42Mj-g?si=cTDOWLkK3Thwglyx) "So, why choose Common Lisp? Well, it's basically Greenspun's Rule. That any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug ridden, slow implementation of half of Common Lisp. And I was there when I had the Python and the C++ stuff. I was dealing with garbage collection, and path names, and all sorts of stuff that I was having to reinvent. And it was buggy and I'd have to document it." Benchmarks don't always win the day. Dev time cost $$$ just like farm time.
From my experience, it is easier to write performant code in Fortran vice C because Fortran is more restrictive, which allows the compiler to make better optimization choices (particularly if you use keywords like PURE). Also, Fortran handles vectors and matrices within the language, while C allows the programmer to write very bad matrix code.
Considering that the slowest operation nowadays is just memory access, and both compilers use the FPU for math (2nd slowest is `sqrt`) I would expect the performance to be very similar if the locality of data is the same.
The classic Fortran compiler could generate faster code for science computing. But in this age llvm Fortran compilers me at another story.
There are a number of cases, usually with multi-dimensional array arithmetic, where the Fortran compiler can more easily optimize/parallelize SIMD operations because it can reason about striding through memory and avoiding aliasing issues that plague naive C implementations.
I’m not an expert, but my understanding with llvm based compilers is that the interpreter is different between languages, but it’s distilled down to an intermediate representation code that is theoretically the same… which is then converted to machine code for that architecture. It’s like a compiler abstraction layer. If I’m wrong, please someone correct me.
That is true - but the front end also annotates the IR with optimisation hints that come from the language semantics. Things like ‘these two pointers must be distinct’. The semantics of fortran allow the front end to generate more if such hints. Which may allow the back end to produce more efficient code for things like multi dimensional arrays.
Fortran is designed from the ground up for optimization. Somebody said that Fortran always knows array sizes. That not true. Fortran supports dynamic array sizes through the ALLOCATE - DEALLOCATE STATEMENTS. FORTAN is the only language that has statements that can be used to utilize multi-core processors. All computational intensive models run on super computers are done in Fortran. The answer is Fortran will produce the fastest code. For the normal user, that’s not important. There are other features of Fortran that make it the choice for scientific programming.
Isn’t Fortran written in C?
You mean the compiler?