5 ms·

At the Fortran Wiki http://fortranwiki.org/fortran/show/Articles http://fortranwiki.org/fortran/show/Articles there are links to benchmarks comparing Fortran to

At the Fortran Wiki http://fortranwiki.org/fortran/show/Articles http://fortranwiki.org/fortran/show/Articles there are links to benchmarks comparing Fortran to Julia and other languages. Looking at https://github.com/arturofburgos/Assessment-of-Programming-Languages-for-Computational-Numerical-Dynamics https://github.com/arturofburgos/Assessment-of-Programming-L... https://www.matecdev.com/posts/numpy-julia-fortran.html https://www.matecdev.com/posts/numpy-julia-fortran.html https://github.com/zyth0s/bench_density_gradient_wfn https://github.com/zyth0s/bench_density_gradient_wfn https://github.com/PIK-ICoNe/NetworkDynamicsBenchmarks https://github.com/PIK-ICoNe/NetworkDynamicsBenchmarks people do find Julia to be faster than Python/Numpy, but it is not uniformly faster than Fortran. And Julia's start-up time should not be ignored. Quoting the last link, "In fact the whole Fortran benchmark (300 integrations) finishes roughly in the time it takes to startup a Julia session and import all required libraries (Julia 1.5.1)."

dnautics 5y ago
If youre actually doing HPC, say, on a cluster, the startup time will be amortized, or else, you're doing something wrong.
- clavigne 5y ago
  why? I commonly do things like screen 10,000 molecules for some property by calling a Fortran program 10k time. If each run takes 60s of compute, the 10s boot from Julia (over the nfs disk) would be pretty significant. Using Julia in this case basically means having to rewrite all of the other programs into it and getting rid of eg snakemake or gnu parallel or any number of other very common HPC workflows. In fact I'd venture that doing a sequence of things many times is just as common an HPC workload than single jobs running for very long times.
  - hansvm 5y ago
    Is there any particular reason you wouldn't want to wrap that workload in a function/module/... and call it in a loop? Is the problem that your commonly used tools are exposed only as command line interfaces and not as libraries?
    - clavigne 5y ago
      Yeah that's what I mean. This is the case for both commercial software (eg Q-Chem) and free software. This is not to say that the boot time is always a problem, there are plenty of applications in which it doesn't matter at all (as you point out). However that's not always the case (by a long shot) which is why tools like GNU Parallel and snakemake exist.
  - oscardssmith 5y ago
    One reason to consider Julia for workflows like this is that it's been designed to improve reproducibility. Julia makes it really easy to distribute package state (through manifest.toml files), that make it easy to get exact copies of the package versions that the original author used.
    - snicker7 5y ago
      Guix/Nix does this better across many programming languages. Unlike language-specific package managers, Guix is fully recursively reproducible ("bootstrappable"). And Nix isn't terribly far behind, either. Julia itself is not even reproducible: https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/34753 https://github.com/JuliaLang/julia/issues/34753
      - oscardssmith 5y ago
        Note that those issues are about deterministic performance, not results. Also guix and nix appear to be Unix only, which severely limit their use for Windows users. One of the places Julia really excels with reproducibility is inter OS, yes there are probably some bugs, but the ability to manage versions cross OS this easily is something I'm not aware of a good alternative for.
        snicker7 5y ago
        > Note that those issues are about deterministic performance, not results. Not at all. The issue is that the default sysimage distributed with Julia cannot be reproduced across machines, e.g. there is no proof that it hasn't been tampered with. This is an open issue in Guix and Nix, though it affects all platforms. > One of the places Julia really excels with reproducibility is inter OS There really is no such thing as reproducibility in Windows, at least not in the sense outlined in bootstrappable.org . If you care about reproducibility, you've chosen the wrong platform.
        oscardssmith 5y ago
  - shele 5y ago
    Just keep it running as a daemon? https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl
jvanderbot 5y ago
Thanks for this. Not sure why its dowdownvoted. Numbers are worth looking at.
fathead_glacier 5y ago
Comparing different metrics is not valid across all use cases. Counting startup time but excluding development time is disingenuous. Having used both Fortan and Julia the difference between development time is staggering. Different tools for different uses cases is the best way to put it.
leephillips 5y ago
I don’t think anyone is claiming that Julia is uniformly faster than well-written Fortran. But you can get comparable performance with code using a style that many people find easier to read, write, and reason about; and it’s interesting that sometimes this code does outperform optimized C or Fortran code. Startup time is much improved in recent Julia versions¹, but is certainly not negligible for short calculations. [1]https://lwn.net/Articles/856819/ https://lwn.net/Articles/856819/
- jvanderbot 5y ago
  Yes, also the mentioned example's speedup (from TFA) was likely at least partially from the accessibility of Julia, making some ancillary optimization easier or almost accidental. You don't need to beat Fortran "at fortran'ing" (the innermost column oriented processing) to be overall faster. I am imagining without evidence.
  - eigenspace 5y ago
    While it certainly won’t always win, there are many documented cases where Julia beats Fortran at Fortranning, e.g. https://fortran-lang.discourse.group/t/simple-summation-8x-slower-than-in-julia/1171 https://fortran-lang.discourse.group/t/simple-summation-8x-s... https://discourse.julialang.org/t/i-just-decided-to-migrate-from-python-fortran-to-julia-as-julia-was-faster-in-my-test/61188 https://discourse.julialang.org/t/i-just-decided-to-migrate-...
socialdemocrat 5y ago
Of course it will not always beat Fortran, but don't think think it is damn impressive that a high level dynamic language with much higher productivity frequently matches or beats Fortran? That is a crazy achievement if you ask me. Real world systems today are going to use a lot of computing resources, such as clusters, GPUs, tensor processing units, multiple cores etc. In such a world, anything that makes that easy to deal with is going to have the performance edge in practice. Doesn't matter how fast a Fortran program would be in theory, if the Julia program is delivered years ahead of it.

dnautics 5y ago

If youre actually doing HPC, say, on a cluster, the startup time will be amortized, or else, you're doing something wrong.

clavigne 5y ago
why? I commonly do things like screen 10,000 molecules for some property by calling a Fortran program 10k time. If each run takes 60s of compute, the 10s boot from Julia (over the nfs disk) would be pretty significant. Using Julia in this case basically means having to rewrite all of the other programs into it and getting rid of eg snakemake or gnu parallel or any number of other very common HPC workflows. In fact I'd venture that doing a sequence of things many times is just as common an HPC workload than single jobs running for very long times.
- hansvm 5y ago
  Is there any particular reason you wouldn't want to wrap that workload in a function/module/... and call it in a loop? Is the problem that your commonly used tools are exposed only as command line interfaces and not as libraries?
  - clavigne 5y ago
    Yeah that's what I mean. This is the case for both commercial software (eg Q-Chem) and free software. This is not to say that the boot time is always a problem, there are plenty of applications in which it doesn't matter at all (as you point out). However that's not always the case (by a long shot) which is why tools like GNU Parallel and snakemake exist.
- oscardssmith 5y ago
  One reason to consider Julia for workflows like this is that it's been designed to improve reproducibility. Julia makes it really easy to distribute package state (through manifest.toml files), that make it easy to get exact copies of the package versions that the original author used.
  - snicker7 5y ago
    Guix/Nix does this better across many programming languages. Unlike language-specific package managers, Guix is fully recursively reproducible ("bootstrappable"). And Nix isn't terribly far behind, either. Julia itself is not even reproducible: https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/34753 https://github.com/JuliaLang/julia/issues/34753
    - oscardssmith 5y ago
      Note that those issues are about deterministic performance, not results. Also guix and nix appear to be Unix only, which severely limit their use for Windows users. One of the places Julia really excels with reproducibility is inter OS, yes there are probably some bugs, but the ability to manage versions cross OS this easily is something I'm not aware of a good alternative for.
      - snicker7 5y ago
        > Note that those issues are about deterministic performance, not results. Not at all. The issue is that the default sysimage distributed with Julia cannot be reproduced across machines, e.g. there is no proof that it hasn't been tampered with. This is an open issue in Guix and Nix, though it affects all platforms. > One of the places Julia really excels with reproducibility is inter OS There really is no such thing as reproducibility in Windows, at least not in the sense outlined in bootstrappable.org . If you care about reproducibility, you've chosen the wrong platform.
        oscardssmith 5y ago
- shele 5y ago
  Just keep it running as a daemon? https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl

jvanderbot 5y ago

Thanks for this. Not sure why its dowdownvoted. Numbers are worth looking at.

fathead_glacier 5y ago

Comparing different metrics is not valid across all use cases. Counting startup time but excluding development time is disingenuous. Having used both Fortan and Julia the difference between development time is staggering. Different tools for different uses cases is the best way to put it.

leephillips 5y ago

I don’t think anyone is claiming that Julia is uniformly faster than well-written Fortran. But you can get comparable performance with code using a style that many people find easier to read, write, and reason about; and it’s interesting that sometimes this code does outperform optimized C or Fortran code. Startup time is much improved in recent Julia versions¹, but is certainly not negligible for short calculations. [1]https://lwn.net/Articles/856819/ https://lwn.net/Articles/856819/

jvanderbot 5y ago
Yes, also the mentioned example's speedup (from TFA) was likely at least partially from the accessibility of Julia, making some ancillary optimization easier or almost accidental. You don't need to beat Fortran "at fortran'ing" (the innermost column oriented processing) to be overall faster. I am imagining without evidence.
- eigenspace 5y ago
  While it certainly won’t always win, there are many documented cases where Julia beats Fortran at Fortranning, e.g. https://fortran-lang.discourse.group/t/simple-summation-8x-slower-than-in-julia/1171 https://fortran-lang.discourse.group/t/simple-summation-8x-s... https://discourse.julialang.org/t/i-just-decided-to-migrate-from-python-fortran-to-julia-as-julia-was-faster-in-my-test/61188 https://discourse.julialang.org/t/i-just-decided-to-migrate-...

socialdemocrat 5y ago

Of course it will not always beat Fortran, but don't think think it is damn impressive that a high level dynamic language with much higher productivity frequently matches or beats Fortran? That is a crazy achievement if you ask me. Real world systems today are going to use a lot of computing resources, such as clusters, GPUs, tensor processing units, multiple cores etc. In such a world, anything that makes that easy to deal with is going to have the performance edge in practice. Doesn't matter how fast a Fortran program would be in theory, if the Julia program is delivered years ahead of it.