3 ms·

> Some of the code was very specifically marked as "not for C++", because modern Fortran (2003 at the time) was better for some specific number-based things. W

> Some of the code was very specifically marked as "not for C++", because modern Fortran (2003 at the time) was better for some specific number-based things. Was that a you-can't-do-that-in-c++ thing or slightly-faster-in-fortan thing? I'm always skeptical about the latter guiding major maintainability decisions on often-specious performance benefit claims.

sampo 7y ago
In the areas where you'd want to use modern Fortran (numerics, not TCP servers), it is easily also more maintainable than C++.
shakna 7y ago
Slightly-faster-in-Fortran. But it wasn't just a slight gain. The system I'm referring to is a multi-national system that processes somewhere in the order of 50-100 million transactions a second (depending on the time of day, and the day itself). A slight performance gain of 1% by using Fortran has a noticeable effect on long-term economic gains. (It was usually in the range of 5-8% performance improvement, but at the worst was 1%). Thankfully, the reason I can tell you this, is because they tested it in the real world, splitting all transaction across a large-scale A/B test. The real-world economic gains from the faster performance more than paid for the occasional development costs of a Fortran-familiar developer, hence why those systems persist in Fortran. They also scheduled re-assessment of this once every five years, knowing it might change one day.
m_mueller 7y ago
To expand a bit on other answers: There is a qualitative difference Fortran has by offering 1) built-in multidimensional arrays including Matlab-like array operations. That means every library supports the same format, it's standardized and convenient as opposed to the many formats in C++ Land. 2) performant defaults. When performance is more important than safety, Fortran programs are easier to write and maintain. Arguments are by default pass-by-reference, non-aliased (a major assumption Fortran compilers can usually make to optimize) and their intent as in/out/in out can simply be marked as such. Fortran: real(8), intent(in) :: foo C: restrict const * const double foo # if I remember correctly
- goerz 7y ago
  I’m not sure what you mean by “When performance is more important than safety, Fortran programs are easier to write and maintain.” The fact that arrays are not based on pointers makes Fortran a much safer language than C. It’s very hard to shoot yourself in the foot with Fortran. It’s fast and safe
  - pletnes 7y ago
    It’s very easy to shoot yourself in any body part - just disable array bounds checking, drop modules (which means no function call interface checks) and you’re practically back to C-land in terms of memory safety. Of course, the sensible thing to do is to check interfaces and bounds (at least in debug/test mode).
  - m_mueller 7y ago
    Fortran offers a better developer experience overall for Numerical applications yes. But it is still very foot shootable as I remember - point a pointer at allocatable and the fun can start. Or make everything inout for convenience and/or performance. But yes, compared to C the defaults are also safer, just don't expect Rust.

sampo 7y ago

In the areas where you'd want to use modern Fortran (numerics, not TCP servers), it is easily also more maintainable than C++.

shakna 7y ago

Slightly-faster-in-Fortran. But it wasn't just a slight gain. The system I'm referring to is a multi-national system that processes somewhere in the order of 50-100 million transactions a second (depending on the time of day, and the day itself). A slight performance gain of 1% by using Fortran has a noticeable effect on long-term economic gains. (It was usually in the range of 5-8% performance improvement, but at the worst was 1%). Thankfully, the reason I can tell you this, is because they tested it in the real world, splitting all transaction across a large-scale A/B test. The real-world economic gains from the faster performance more than paid for the occasional development costs of a Fortran-familiar developer, hence why those systems persist in Fortran. They also scheduled re-assessment of this once every five years, knowing it might change one day.

m_mueller 7y ago

To expand a bit on other answers: There is a qualitative difference Fortran has by offering 1) built-in multidimensional arrays including Matlab-like array operations. That means every library supports the same format, it's standardized and convenient as opposed to the many formats in C++ Land. 2) performant defaults. When performance is more important than safety, Fortran programs are easier to write and maintain. Arguments are by default pass-by-reference, non-aliased (a major assumption Fortran compilers can usually make to optimize) and their intent as in/out/in out can simply be marked as such. Fortran: real(8), intent(in) :: foo C: restrict const * const double foo # if I remember correctly

goerz 7y ago
I’m not sure what you mean by “When performance is more important than safety, Fortran programs are easier to write and maintain.” The fact that arrays are not based on pointers makes Fortran a much safer language than C. It’s very hard to shoot yourself in the foot with Fortran. It’s fast and safe
- pletnes 7y ago
  It’s very easy to shoot yourself in any body part - just disable array bounds checking, drop modules (which means no function call interface checks) and you’re practically back to C-land in terms of memory safety. Of course, the sensible thing to do is to check interfaces and bounds (at least in debug/test mode).
- m_mueller 7y ago
  Fortran offers a better developer experience overall for Numerical applications yes. But it is still very foot shootable as I remember - point a pointer at allocatable and the fun can start. Or make everything inout for convenience and/or performance. But yes, compared to C the defaults are also safer, just don't expect Rust.