# Julia vs Fortran complaint

**URL:** <https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366>\
**Category:** General Usage\
**Tags:** fortran\
**Created:** [June 20, 2017, 1:09pm UTC](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366 "2017-06-20T13:09:48Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [June 21, 2017, 3:10pm UTC](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/21 "2017-06-21T15:10:25Z")

</div>

> [@stevengj](#):
>
> they need additional runtime information about which types are present in order to produce reasonable compiled code

I certainly see that this would be the case with Python and R since they were designed as interpreted languages and give a would-be compiler few clues as to what it’s actually expected to do. I guess my question is, aren’t most of the things that are being said about performance in this thread things that can equally apply to Java or Scala?

A year ago, when I would tell people I use Julia the first question they’d ask me is “Why not use Python?” and the second question they’d ask me is “Why not use Scala?” Of course I’m sold on Julia because I like the language design much better than Scala, but I’m wondering if the performance advantages are anything more than incidental. (Interestingly, Scala use seems to have fallen off a cliff and it seems to be kept alive mainly by Spark lately.)

---

<div class="post-metadata">

**Author:** ![ihnorton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ihnorton/32/26_2.png) [@ihnorton](https://discourse.julialang.org/u/ihnorton)\
**Post date:** [June 21, 2017, 3:13pm UTC](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/22 "2017-06-21T15:13:06Z")

</div>

> [@ExpandingMan](#):
>
> I’m curious, does any of this have to do with the fact that Julia’s compiler is basically a static compiler

Related:

> [@Notes on the Julia compiler (JIT vs static)](https://discourse.julialang.org/t/notes-on-the-julia-compiler-jit-vs-static/4275/2):
>
> in short, it’s a reasonably good static compilier but a terrible JIT (or bascially it’s not a JIT)… By saying that its a static compiler, what I mean is that it does not use any runtimme information to produce optimized code. (Here static information is basically anything in the type domain whereas runtime information being anything in the value domain). The advantage of this approach is that if the code is well writen, the performance will be predictably good, the compile time will also be ve…

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [June 21, 2017, 4:58pm UTC](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/23 "2017-06-21T16:58:19Z")

</div>

> [@ExpandingMan](#):
>
> aren’t most of the things that are being said about performance in this thread things that can equally apply to Java or Scala?

Like Go and Rust, those are also statically typed languages. Everyone knows that you can get good performance from any decent static language. But static languages aren’t well suited to interactive usage/exploration. That’s why the usual points of comparison for Julia are other dynamic languages like Matlab, Python, and R.

---

<div class="post-metadata">

**Author:** ![jeffhammond](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffhammond/32/1104_2.png) [@jeffhammond](https://discourse.julialang.org/u/jeffhammond)\
**Post date:** [June 27, 2017, 5:45am UTC](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/24 "2017-06-27T05:45:50Z")

</div>

For what it’s worth, [https://github.com/ParRes/Kernels](https://github.com/ParRes/Kernels) has ports of interesting HPC kernels to Julia, Python, Rust, Octave/Matlab, C++ (+many threading models), Fortran 2008 (+multiple parallel models), C89-ish (+many parallel models, both shared and distributed), and Chapel (in a branch at the moment).

I found that Julia was significantly better than Python for wavefront parallelism, because unlike independent data parallelism, Numpy has no intrinsic for this (that I know of). All other performance comparisons are left as an exercise for the reader.

Most of the shared-memory ports of the PRKs took me a few hours, so you should have no trouble implementing new languages that you want to compare to Julia (if you create these, please submit a pull request).

---

<div class="post-metadata">

**Author:** ![DIzer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dizer/32/3971_2.png) [@DIzer](https://discourse.julialang.org/u/DIzer)\
**Post date:** [June 27, 2017, 12:31pm UTC](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/25 "2017-06-27T12:31:09Z")

</div>

I believe - nowdays there is no reason to speak about the such tremendous speedups without taking in accounts software and hardware details. On the second hand… one of the Julia\s authors goals - to be only on 10-20% SLOWER then compile-time workhorses upon most common numerical calculations in practice - QUITE FEASIBLE.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [July 20, 2017, 3:21am UTC](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/26 "2017-07-20T03:21:59Z")

</div>

> [@PabloZubieta](#):
>
> Slightly OT too: NIntegration.jl (which I started writing recently, and is still a WIP) implements the same algorithm that cuba and cubature (Cuhre) in pure Julia and is 2x time faster than the cuba version (in 3D).

I implemented a pure-Julia arbitrary-dimensional version of the Genz-Malik algorithm at:

> **[GitHub - JuliaMath/HCubature.jl: pure-Julia multidimensional h-adaptive integration](https://github.com/JuliaMath/HCubature.jl)**
>
> pure-Julia multidimensional h-adaptive integration

It should be fully functional, and a big advantage of being pure Julia is that it is type-generic. (e.g. your integrand function can be `Float32`, `Complex{BigFloat}`, `Matrix{Float64}`, etcetera and it will all work.)

[Previous page](https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366.md?page=1)