# Speed of Julia vs. Fortran and other languages

**URL:** <https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850>\
**Category:** Performance\
**Created:** [June 30, 2021, 5:52pm UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850 "2021-06-30T17:52:18Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://discourse.julialang.org/u/Beliavsky)\
**Post date:** [June 30, 2021, 5:52pm UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850/1 "2021-06-30T17:52:18Z")

</div>

The Benchmarks category of [Fortran code on GitHub](https://github.com/Beliavsky/Fortran-code-on-GitHub) lists many benchmarks where Julia is considered, listed below. I will not make any generalizations about the results.

[Assessment of Programming Languages for Computational Numerical Dynamics](https://github.com/arturofburgos/Assessment-of-Programming-Languages-for-Computational-Numerical-Dynamics): compares different programming languages performance in order to solve CFD and Heat Transfer problems, by arturofburgos

[Basic Comparison of Various Computing Languages: Python, Julia, Matlab, IDL, R, Java, Scala, C, Fortran](https://github.com/JulesKouatchou/basic_language_comparison) by Jules Kouatchou and Alexander Medema

[bench\_density\_gradient\_wfn](https://github.com/zyth0s/bench_density_gradient_wfn): analyze the performance of evaluating the density gradient with various language implementations (C++/Fortran/Rust/Julia), by zyth0s

[Comparison of Programming Languages in Economics](https://github.com/jesusfv/Comparison-Programming-Languages-Economics): code referenced in the paper “A Comparison of Programming Languages in Economics” by S. Borağan Aruoba and Jesús Fernández-Villaverde

[julia-numpy-fortran-test](https://github.com/mdmaas/julia-numpy-fortran-test): comparing Julia vs Numpy vs Fortran for performance and code simplicity, by mdmaas

[Microbenchmarks](https://github.com/JuliaLang/Microbenchmarks): micro benchmark comparison of Julia against other languages, including Fortran, from JuliaLang

[NetworkDynamicsBenchmarks](https://github.com/PIK-ICoNe/NetworkDynamicsBenchmarks): scripts for benchmarking dynamical systems on networks, from paper “NetworkDynamics.jl – Composing and simulating complex networks in Julia”, by Michael Lindner et al.

[Performance comparison R, Julia, Fortran for Bayesian binary probit](https://github.com/driesbenoit/benchmark_R_Julia_Fortran) by driesbenoit

[raytracer](https://github.com/edin/raytracer): raytracer benchmark in dozens of languages, by edin.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [June 30, 2021, 6:11pm UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850/2 "2021-06-30T18:11:52Z")

</div>

I have read the post on the Fortran discourse forum that deals with benchmarks in Julia and Fortran.  
Usually programmers who have a stake in Fortran object to any results that indicate  
that Julia might be as fast or faster than Fortran.

It is certainly possible to find programs in one language which can be sped up by programming  
in the other language. It can be usually traced to some flaw in the original program that was  
corrected in the new program. If the two programs approached the algorithm from the same  
view point, and if the compilers were equally good, the number crunching should be ultimately  
carried out at the same speed in either one.

I am convinced that this is a red herring when comparing the two languages. For me the question is:  
with which language can I reach the goal of programming an algorithm faster, with more legible and maintainable code, and such that for a given-size model I get the results at roughly the same wall-clock time?

Considering that Fortran lacks generics, multiple dispatch, and it’s not likely to get there in the foreseeable future, for me this is no contest.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [June 30, 2021, 7:17pm UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850/3 "2021-06-30T19:17:26Z")

</div>

Sometimes the benchmark code will just be written suboptimally, which can be ignored.

More usefully, in some cases Julia itself may be actually missing some real optimization opportunities in the language that can be revealed by looking at _why Fortran is faster_ in each particular case that it is. For example, this PR [Add UInt/Int to \_str\_sizehint for printing to strings by Seelengrab · Pull Request #40718 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/40718) on string performance came from a benchmark comparison.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [June 30, 2021, 7:33pm UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850/4 "2021-06-30T19:33:03Z")

</div>

I’m just waiting for Chris Elrod to make a PR to the Fortran-lang/benchmark with what he showed us yesterday on Slack 😉

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 30, 2021, 10:08pm UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850/5 "2021-06-30T22:08:01Z")

</div>

Fortran is missing from this one, but [GitHub - dyu/ffi-overhead: comparing the c ffi (foreign function interface) overhead on various programming languages](https://github.com/dyu/ffi-overhead) the ffi-overhead test shows how JIT compiled languages like Julia and Lua (i.e. it’s not just a one language outlier) are faster at C calls than compiled languages like C. That’s one data point or explanation for pieces of it.

The [https://github.com/SciML/SciMLBenchmarks.jl](https://github.com/SciML/SciMLBenchmarks.jl) showcase a lot of examples where Julia libraries are outperforming C and Fortran libraries. The reason is mostly algorithmic though (new methods which make use of autodiff, new heuristics, and other changes to perform less `f` evaluations) so it’s not quite a language comparison itself, but it’s one factor that can be involved in a lot of people’s real-world benchmarks. The fact that they switch to a new stiff ODE solver than takes half of the actual `f` calls and get a 2.5x-3x speedup from the language change + code cleanup should not be so surprising in that light. Real applications use real packages, and algorithms matter.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [July 1, 2021, 12:20am UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850/6 "2021-07-01T00:20:10Z")

</div>

> [@Beliavsky](#):
>
> [Assessment of Programming Languages for Computational Numerical Dynamics](https://github.com/arturofburgos/Assessment-of-Programming-Languages-for-Computational-Numerical-Dynamics): compares different programming languages performance in order to solve CFD and Heat Transfer problems, by arturofburgos

Some of the measurements are a bit suspect: I noticed some type instabilities and some of the algorithms may actually be incorrect.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [July 1, 2021, 12:54pm UTC](https://discourse.julialang.org/t/speed-of-julia-vs-fortran-and-other-languages/63850/7 "2021-07-01T12:54:37Z")

</div>

> [@Beliavsky](#):
>
> [raytracer](https://github.com/edin/raytracer): raytracer benchmark in dozens of languages, by edin.

This one has been discussed here: [Why is this raytracer slow?](https://discourse.julialang.org/t/why-is-this-raytracer-slow/59176)

The conclusion were:

1. The time reported for Julia there does not really make sense. The code that is there, as is, runs in about 2x the time of the Fortran code (including Julia startup and compilation). Thus one would expect that a time of ~320 ms would be reported in that table (not 900ms).

2. There are some algorithmic differences, particularly in the fact that for the Fortran code there is only "one type\* of “thing”, while in the Julia code there are different types of “things” in the scene. That introduces some type instabilities and run-time dispatch issues that make the Julia code slower.

3. The algorithms being equal, the final running time is dependent on the number of objects of the scene, and the Julia code becomes as fast as the Nim one (which has very low-level optimizations) and faster than the Fortran code for about 10 objects.