3 ms·

Most people I know who use Fortran for long-running HPC jobs compile it with Intel's ifort. Are you using ifort (or another high-performance commercial compiler

Most people I know who use Fortran for long-running HPC jobs compile it with Intel's ifort. Are you using ifort (or another high-performance commercial compiler)? I ask because Intel's compilers can produce binaries with significantly better runtime performance than GNU or LLVM. AFAIK Rust relies exclusively on LLVM. I'm wondering if the slowdown is mostly about the very mature optimizing compilers available for Fortran or if it's intrinsic to Rust's language design. (I've never written any Rust myself.)

ihnorton 8y ago
Note that ifort defaults to a substantial equivalent of gfortran’s `-ffast-math`, which is not the default in gfortran. It looks like the equivalent option is still under discussion for rust: https://github.com/rust-lang/rust/issues/21690 https://github.com/rust-lang/rust/issues/21690
romwell 8y ago
> Are you using ifort (or another high-performance commercial compiler)? Yes, PGI Fortran. >I'm wondering if the slowdown is mostly about the very mature optimizing compilers available for Fortran or if it's intrinsic to Rust's language design. I wonder about that too. Time will tell!
- renox 8y ago
  I think that rust doesn't have (doesn't want to have) -ffast-math.
  - steveklabnik 8y ago
    We tend to shy away from flags like this that change behavior globally. I wonder if it could be done similar to Wrapping, where you opt into the semantics on a specific basis. I know there’s been some discussion about fast-math but I don’t remember the details.
obd 8y ago
It is true that ifort produces code that is sometimes 2-5× faster, but the compiler is also currently buggier than gfortran IMHO, even on basic stuff like sum(). And the produced code is harder to debug: the backtraces aren't that great and I couldn't get them to work on stop/error stop, unlike Gfortran. Gfortran can produce reasonably fast code with array bounds checking enabled, but ifort turns off optimizations if you enable that, which means that you can't debug your code because it takes forever to run. Gdb has trouble with both ifort and gfortran code and ends up panicking if you try to inspect variables a bit too closely. But then I rarely use a debugger. As far as language support goes, neither ifort nor gfortran properly supports parametrized derived types, which is a pretty sweet feature that allows you to define a small number of dynamic type parameters that define things such as dimensions and precisions. This saves a lot of boilerplate regarding allocation and deallocation and makes the code cleaner. However I got burned using that, as ifort ends up crashing as soon as the code making use of PDTs gets complex (for example, as soon as you've done implementing your module and are using it in some bigger piece of code) or produces incorrect code. Hopefully they'll fix that soon. Both ifort and gfortran do support the object-oriented and generic features, although wrapping your head around the Fortran memory management and allocation model is difficult if your background is C. Fortran lacks direct support for generic programming, but you can work your way out of that pretty decently with creative use of modules and the 'include' directive, without even needing to use CPP. If you're gonna use CPP, keep it simple, #ifdef's etc. are OK, for macros you need to define your own concatenation operator if you want your code to work both with gfortran and ifort. As for PGI Fortran, it doesn't even fully support object oriention, so it's more like Fortran late nineties; but it does do fancy automatic parallelization and can target GPUs. The reason people still use Fortran is because it supports arrays, is fast, readable and standardized. No, C and C++ do not support arrays. Proper array support would involve the compiler knowing array rank, dimensions and eventually stride, providing standard ways of representing and indexing them, and basic functions with clear performance and memory management properties, plus bounds checks (and the ability to optimize them away). Now let's pretend you have some C++ header library that provides some of that in the form overloaded indexing operators etc. Will that stuff compile in two years? No it won't, because the library will change, and because the compilers will change. It's not standard. Second, your C++ code is gonna be unreadable. Fortran code is readable to Joe random Engineer/Scientist, + means plus, and an array is an array is an array, and hasn't changed much in decades. However, general I/O in Fortran is horrible, although the edit descriptors allow you to produce nice fixed-column output easily as opposed to printf. Also, you can "print , any, value, you, want" which is very handy for debugging, but C++ streams generally cover that.

ihnorton 8y ago

Note that ifort defaults to a substantial equivalent of gfortran’s `-ffast-math`, which is not the default in gfortran. It looks like the equivalent option is still under discussion for rust: https://github.com/rust-lang/rust/issues/21690 https://github.com/rust-lang/rust/issues/21690

romwell 8y ago

> Are you using ifort (or another high-performance commercial compiler)? Yes, PGI Fortran. >I'm wondering if the slowdown is mostly about the very mature optimizing compilers available for Fortran or if it's intrinsic to Rust's language design. I wonder about that too. Time will tell!

renox 8y ago
I think that rust doesn't have (doesn't want to have) -ffast-math.
- steveklabnik 8y ago
  We tend to shy away from flags like this that change behavior globally. I wonder if it could be done similar to Wrapping, where you opt into the semantics on a specific basis. I know there’s been some discussion about fast-math but I don’t remember the details.

obd 8y ago

It is true that ifort produces code that is sometimes 2-5× faster, but the compiler is also currently buggier than gfortran IMHO, even on basic stuff like sum(). And the produced code is harder to debug: the backtraces aren't that great and I couldn't get them to work on stop/error stop, unlike Gfortran. Gfortran can produce reasonably fast code with array bounds checking enabled, but ifort turns off optimizations if you enable that, which means that you can't debug your code because it takes forever to run. Gdb has trouble with both ifort and gfortran code and ends up panicking if you try to inspect variables a bit too closely. But then I rarely use a debugger. As far as language support goes, neither ifort nor gfortran properly supports parametrized derived types, which is a pretty sweet feature that allows you to define a small number of dynamic type parameters that define things such as dimensions and precisions. This saves a lot of boilerplate regarding allocation and deallocation and makes the code cleaner. However I got burned using that, as ifort ends up crashing as soon as the code making use of PDTs gets complex (for example, as soon as you've done implementing your module and are using it in some bigger piece of code) or produces incorrect code. Hopefully they'll fix that soon. Both ifort and gfortran do support the object-oriented and generic features, although wrapping your head around the Fortran memory management and allocation model is difficult if your background is C. Fortran lacks direct support for generic programming, but you can work your way out of that pretty decently with creative use of modules and the 'include' directive, without even needing to use CPP. If you're gonna use CPP, keep it simple, #ifdef's etc. are OK, for macros you need to define your own concatenation operator if you want your code to work both with gfortran and ifort. As for PGI Fortran, it doesn't even fully support object oriention, so it's more like Fortran late nineties; but it does do fancy automatic parallelization and can target GPUs. The reason people still use Fortran is because it supports arrays, is fast, readable and standardized. No, C and C++ do not support arrays. Proper array support would involve the compiler knowing array rank, dimensions and eventually stride, providing standard ways of representing and indexing them, and basic functions with clear performance and memory management properties, plus bounds checks (and the ability to optimize them away). Now let's pretend you have some C++ header library that provides some of that in the form overloaded indexing operators etc. Will that stuff compile in two years? No it won't, because the library will change, and because the compilers will change. It's not standard. Second, your C++ code is gonna be unreadable. Fortran code is readable to Joe random Engineer/Scientist, + means plus, and an array is an array is an array, and hasn't changed much in decades. However, general I/O in Fortran is horrible, although the edit descriptors allow you to produce nice fixed-column output easily as opposed to printf. Also, you can "print , any, value, you, want" which is very handy for debugging, but C++ streams generally cover that.