4 ms·

I'm writing this comment while compiling OpenMP Fortran code that models photoresist behavior in chip lithography. Could've written the same in C++, but for th

I'm writing this comment while compiling OpenMP Fortran code that models photoresist behavior in chip lithography. Could've written the same in C++, but for things like that, Fortran is more natural (its math syntax is Matlab-ish, although, of course, it's more correct to say that Matlab's syntax is Fortran-ish). Anecdote: I'm starting to learn Rust, and just for fun, wrote a dumb single-loop Riemann sum to compute pi in Rust and Fortran (as the area of the circle) - and Fortran code ran 2x faster. When the computation time is measured in days, this kind of difference matters.

electricslpnsld 8y ago
> Anecdote: I'm starting to learn Rust, and just for fun, wrote a dumb single-loop Riemann sum to compute pi in Rust and Fortran (as the area of the circle) - and Fortran code ran 2x faster. When the computation time is measured in days, this kind of difference matters. I'd love to use Rust for numerical heavy code, like Fortran Rust is no-aliasing out of the box which is great for code gen, but Rust also has many of the niceties of C++. Still no integer generics in Rust though. :(
- romwell 8y ago
  Well, the standard is still developing. I have high hopes for when more numeric computing people jump on the bandwagon.
- steveklabnik 8y ago
  They should be in nightly later in the year, and stable early next year. We were only recently able to turn those no aliasing optimizations back on, so you were probably using a version of Rust that wasn’t even making use of them.
philipkglass 8y ago
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.

electricslpnsld 8y ago

> Anecdote: I'm starting to learn Rust, and just for fun, wrote a dumb single-loop Riemann sum to compute pi in Rust and Fortran (as the area of the circle) - and Fortran code ran 2x faster. When the computation time is measured in days, this kind of difference matters. I'd love to use Rust for numerical heavy code, like Fortran Rust is no-aliasing out of the box which is great for code gen, but Rust also has many of the niceties of C++. Still no integer generics in Rust though. :(

romwell 8y ago
Well, the standard is still developing. I have high hopes for when more numeric computing people jump on the bandwagon.
steveklabnik 8y ago
They should be in nightly later in the year, and stable early next year. We were only recently able to turn those no aliasing optimizations back on, so you were probably using a version of Rust that wasn’t even making use of them.

philipkglass 8y ago

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.