6 ms·

I'm not at all familiar with Fortran. I was under impression that its old language living in legacy. I believe there are other good alternatives, why still use

I'm not at all familiar with Fortran. I was under impression that its old language living in legacy. I believe there are other good alternatives, why still use Fortran for new code?

tjl 11y ago
It's still faster than the alternatives. Things like Scipy/Numpy are more alternatives to Matlab as is R. Julia isn't fast enough yet. C/C++ doesn't have the built-in matrix/vector support. The latter is what I ran into when I was coding for my Master's thesis, so I just gave up and went with Fortran. For my PhD, I used Matlab as the speed wasn't an issue. There's also issues with wanting to use the old Fortran code in new projects and if the new alternatives don't have a good interface for Fortran, it's a bit of a pain to integrate.
- fafner 11y ago
  In C++ - unlike C - you can actually implement quite good matrix/vector support. E.g., Eigen3 http://eigen.tuxfamily.org/index.php?title=Main_Page http://eigen.tuxfamily.org/index.php?title=Main_Page or Blaze https://bitbucket.org/blaze-lib/blaze https://bitbucket.org/blaze-lib/blaze or if you have a specific BLAS library tuned to your cluster then maybe FLENS http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/index.html http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/index.html
  - tjl 11y ago
    True, but the problem I had (which I will admit was back in '99) is that there's no standard one. So, if you need to solve a system of ODEs and a linear system, you're invariably needing to convert between the two.
    - RogerL 11y ago
      This is still true. This library uses Eigen, that one uses Boost, the other one uses a home grown one. And then you want to use another library, it uses Eigen (yay!), but an old version of Eigen and it won't compile against the current version. C++ really crippled itself in this regard by never making a standard. I never bought Stroustrup's claims of "but you can write your own" for these reasons.
- malmaud 11y ago
  Do you have an example of Julia not being fast enough?
  - tjl 11y ago
    Last I checked, some things that can be vectorized, but aren't in LAPACK/BLAS weren't particularly fast. There's even one example from a few years ago on Stack Overflow where it was at least an order of magnitude slower than Octave.
- Xcelerate 11y ago
  At least for me, Julia's fast enough in most cases. I switched from C/C++ to Julia for all of my scientific work, and it runs fine, even on a supercomputer like Titan (barring something that requires thousands of nodes at once — MPI is not yet integrated into Julia). You just have to be careful in the tight inner loops and check the assembly that it outputs using code_native(). Granted, there's plenty of fast libraries written in C/Fortran that don't have a Julia equivalent yet, and depending on the overhead of ccall(), you may wish to stick with writing the rest of your code in the language of the library.
  - tjl 11y ago
    Good to know. I've been looking at it, but not seriously. It's been more keeping an eye on it. I was hoping that Fortress would go somewhere, but it died. My other problem is code generation. I can't generate Julia code yet.
    - ihnorton 11y ago
      > My other problem is code generation. I can't generate Julia code yet. Perhaps I am misunderstanding your meaning here, but Julia has a range of metaprogramming functionality including both Lisp-like macros, as well as "generated functions" that allow custom code specialization based on input type signatures (https://medium.com/@acidflask/smoothing-data-with-julia-s-generated-functions-c80e240e05f3 https://medium.com/@acidflask/smoothing-data-with-julia-s-ge...). These capabilities have been used for DSLs (e.g. https://github.com/JuliaOpt/JuMP.jl https://github.com/JuliaOpt/JuMP.jl) and parser generation (e.g. https://github.com/abeschneider/PEGParser.jl https://github.com/abeschneider/PEGParser.jl).
      - tjl 11y ago
        No, I'm talking about generating Julia code from elsewhere. I'll derive some math in another program (e.g., Maple, Mathematica, SymPy) and output code that represents that math. I can't do that with Julia right now.
        11y ago
- bssrdf 11y ago
  At least from one report I read sometime ago, scientists in Los Alamos National Lab were looking at alternatives to Fortran for their future generations of climate models. C/C++ is under their radar. One reason for the switch is to better deal with unstructured grids. They are moving away from the traditional rectilinear grids. This is more in line with many FEM applications where C++ dominates.
msandford 11y ago
> I believe there are other good alternatives, why still use Fortran for new code? Just because they're good alternatives doesn't mean they merit rewriting software that cost millions upon millions to write the first time. Plus when you're talking about code that runs on 5000 machines, even just a 5% difference is meaningful.
jcranmer 11y ago
FORTRAN doesn't share the mess that is aliasing in C/C++, which makes it much easier to optimize for numerical-heavy code, so your linear algebra libraries are typically all written in FORTRAN. That said, I believe most of the post-MPI HPC frameworks are based on C/C++ with little support for FORTRAN.

I'm not at all familiar with Fortran. I was under impression that its old language living in legacy. I believe there are other good alternatives, why still use Fortran for new code?

tjl 11y ago

It's still faster than the alternatives. Things like Scipy/Numpy are more alternatives to Matlab as is R. Julia isn't fast enough yet. C/C++ doesn't have the built-in matrix/vector support. The latter is what I ran into when I was coding for my Master's thesis, so I just gave up and went with Fortran. For my PhD, I used Matlab as the speed wasn't an issue. There's also issues with wanting to use the old Fortran code in new projects and if the new alternatives don't have a good interface for Fortran, it's a bit of a pain to integrate.

fafner 11y ago
In C++ - unlike C - you can actually implement quite good matrix/vector support. E.g., Eigen3 http://eigen.tuxfamily.org/index.php?title=Main_Page http://eigen.tuxfamily.org/index.php?title=Main_Page or Blaze https://bitbucket.org/blaze-lib/blaze https://bitbucket.org/blaze-lib/blaze or if you have a specific BLAS library tuned to your cluster then maybe FLENS http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/index.html http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/index.html
- tjl 11y ago
  True, but the problem I had (which I will admit was back in '99) is that there's no standard one. So, if you need to solve a system of ODEs and a linear system, you're invariably needing to convert between the two.
  - RogerL 11y ago
    This is still true. This library uses Eigen, that one uses Boost, the other one uses a home grown one. And then you want to use another library, it uses Eigen (yay!), but an old version of Eigen and it won't compile against the current version. C++ really crippled itself in this regard by never making a standard. I never bought Stroustrup's claims of "but you can write your own" for these reasons.
malmaud 11y ago
Do you have an example of Julia not being fast enough?
- tjl 11y ago
  Last I checked, some things that can be vectorized, but aren't in LAPACK/BLAS weren't particularly fast. There's even one example from a few years ago on Stack Overflow where it was at least an order of magnitude slower than Octave.
Xcelerate 11y ago
At least for me, Julia's fast enough in most cases. I switched from C/C++ to Julia for all of my scientific work, and it runs fine, even on a supercomputer like Titan (barring something that requires thousands of nodes at once — MPI is not yet integrated into Julia). You just have to be careful in the tight inner loops and check the assembly that it outputs using code_native(). Granted, there's plenty of fast libraries written in C/Fortran that don't have a Julia equivalent yet, and depending on the overhead of ccall(), you may wish to stick with writing the rest of your code in the language of the library.
- tjl 11y ago
  Good to know. I've been looking at it, but not seriously. It's been more keeping an eye on it. I was hoping that Fortress would go somewhere, but it died. My other problem is code generation. I can't generate Julia code yet.
  - ihnorton 11y ago
    > My other problem is code generation. I can't generate Julia code yet. Perhaps I am misunderstanding your meaning here, but Julia has a range of metaprogramming functionality including both Lisp-like macros, as well as "generated functions" that allow custom code specialization based on input type signatures (https://medium.com/@acidflask/smoothing-data-with-julia-s-generated-functions-c80e240e05f3 https://medium.com/@acidflask/smoothing-data-with-julia-s-ge...). These capabilities have been used for DSLs (e.g. https://github.com/JuliaOpt/JuMP.jl https://github.com/JuliaOpt/JuMP.jl) and parser generation (e.g. https://github.com/abeschneider/PEGParser.jl https://github.com/abeschneider/PEGParser.jl).
    - tjl 11y ago
      No, I'm talking about generating Julia code from elsewhere. I'll derive some math in another program (e.g., Maple, Mathematica, SymPy) and output code that represents that math. I can't do that with Julia right now.
      - 11y ago
bssrdf 11y ago
At least from one report I read sometime ago, scientists in Los Alamos National Lab were looking at alternatives to Fortran for their future generations of climate models. C/C++ is under their radar. One reason for the switch is to better deal with unstructured grids. They are moving away from the traditional rectilinear grids. This is more in line with many FEM applications where C++ dominates.

msandford 11y ago

> I believe there are other good alternatives, why still use Fortran for new code? Just because they're good alternatives doesn't mean they merit rewriting software that cost millions upon millions to write the first time. Plus when you're talking about code that runs on 5000 machines, even just a 5% difference is meaningful.

jcranmer 11y ago

FORTRAN doesn't share the mess that is aliasing in C/C++, which makes it much easier to optimize for numerical-heavy code, so your linear algebra libraries are typically all written in FORTRAN. That said, I believe most of the post-MPI HPC frameworks are based on C/C++ with little support for FORTRAN.