3 ms·

Should I Py or Should I Fortran?

4 points by milancurcic 7y ago

milancurcic 7y ago
Author here. I spoke about Python and Fortran to an association of chemical engineers a few nights ago. Some folks here may find the slides interesting.
- 6thaccount2 7y ago
  Your modern Fortran book looks pretty good. I'm always sad that the power systems industry has mostly moved from Fortran to C++ as the Fortran is much easier to read and doesn't make overzealous use of OO principles. I use a lot of Python for process automation and data analysis. If I had to put numerical code in production it would probably be in either Fortran or Julia. My problems with Fortran usually boil down to libraries for certain things like database access. I did a little googling and there is some ODBC support, but it doesn't seem to be very good.
  - milancurcic 7y ago
    Thanks! I agree -- many general purpose domains are lacking Fortran libraries. Regarding DB access, Arjen Markus has an interface to SQLite, but I'm not aware of anything else. As almost everything out there has a C API, getting it compatible with Fortran is a matter of doing the grunt work and writing the wrappers around the C functions. To me, the lack of such Fortran libraries just shows there hasn't been much need for it.
    - TheRealKing 7y ago
      Anything that can access C, can also access Fortran via iso_fortran_env module in Fortran (>2003).
ohiovr 7y ago
Maybe at one time fortran had the most mature libraries for simulations but is that still true?
ktpsns 7y ago
Single threaded, NumPy offers basically the same syntax and speed as Fortran when it comes to vector operations. Therefore, the slides boil down to "CoArrays being the Fortran killer application". I don't feel this is the whole truth. You can (and many people do) write a modern Fortran MPI-CoArray application for HPC and it can be slim, compile and run fast. No big ecosystem, like a small C application. The same is most likely not true if you include Python in your toolchain and then use some FFI to call C or Fortran in performance critical sections. As the author, you might be able to hide the ugliness (such as Numpy does it), but it can be a show stopper for maintainability and future generations working with the code. That's probably why still so many new HPC codes are pure Fortran/C codebases and Julia or Python remains the language for postprocessing data on workstations.

4 points by milancurcic 7y ago

Author here. I spoke about Python and Fortran to an association of chemical engineers a few nights ago. Some folks here may find the slides interesting.

6thaccount2 7y ago
Your modern Fortran book looks pretty good. I'm always sad that the power systems industry has mostly moved from Fortran to C++ as the Fortran is much easier to read and doesn't make overzealous use of OO principles. I use a lot of Python for process automation and data analysis. If I had to put numerical code in production it would probably be in either Fortran or Julia. My problems with Fortran usually boil down to libraries for certain things like database access. I did a little googling and there is some ODBC support, but it doesn't seem to be very good.
- milancurcic 7y ago
  Thanks! I agree -- many general purpose domains are lacking Fortran libraries. Regarding DB access, Arjen Markus has an interface to SQLite, but I'm not aware of anything else. As almost everything out there has a C API, getting it compatible with Fortran is a matter of doing the grunt work and writing the wrappers around the C functions. To me, the lack of such Fortran libraries just shows there hasn't been much need for it.
  - TheRealKing 7y ago
    Anything that can access C, can also access Fortran via iso_fortran_env module in Fortran (>2003).

ohiovr 7y ago

Maybe at one time fortran had the most mature libraries for simulations but is that still true?

ktpsns 7y ago

Single threaded, NumPy offers basically the same syntax and speed as Fortran when it comes to vector operations. Therefore, the slides boil down to "CoArrays being the Fortran killer application". I don't feel this is the whole truth. You can (and many people do) write a modern Fortran MPI-CoArray application for HPC and it can be slim, compile and run fast. No big ecosystem, like a small C application. The same is most likely not true if you include Python in your toolchain and then use some FFI to call C or Fortran in performance critical sections. As the author, you might be able to hide the ugliness (such as Numpy does it), but it can be a show stopper for maintainability and future generations working with the code. That's probably why still so many new HPC codes are pure Fortran/C codebases and Julia or Python remains the language for postprocessing data on workstations.