What is the advantage of Julia over Fortran?

General Usage
42

You named two things that are almost there, the latter though is still a bit in development but should have some form released by the end of the year. See:

Control engineers coming from Simulink seem to be the main people adopting right now, since at lot of them are getting a nice ridiculous speedup. structural_simplify bug (I think) · Issue #1178 · SciML/ModelingToolkit.jl · GitHub is today’s but there was a 2 hour to seconds in waste water management the other day, the NASA launch services one that I mentioned in the video, etc. So it’s still a little in progress but that’s probably one of our biggest near term growth areas. It’s the target market for the set of tools coming out over early 2022.

12 Likes
43

I may have missed a subtlety here, but are you talking about old fortran code running on a new fortran version (and equivalently old julia code running on a new julia version) or are you talking about the old code running on the same old language version, just in the future?

1 Like
44

Just read through this… the two languages are very different with one focusing on dynamism, multiple dispatch, homoiconicity/metaprogramming, and interactivity. The other is has a solid minimal syntax, OOP, and generates very optimized binaries. There are some similarities but they are rather different in workflows and complement each other well. I don’t get all the fuss, I like both and I don’t see how Fortran is a language for something like robust metaprogramming mixed with symbolic arithmetic, while Julia is a bit harder to perfect performance because Fortran just won’t work if it’s not performant. Just two different focuses.

16 Likes
45

That’s nearly always the last conclusion when comparing two languages (well, sometimes I only like one of them). :slight_smile:

1 Like
46

I would say that with Julia it is easier to get a lousy performance. When it comes to “perfecting” performance, it comes down to improving algorithms and implementation details, and with the current tooling and dynamism that is easier with Julia.

2 Likes
47

A major advantage of Julia, as reported here in Discourse many times by people with a scientific background but who are not computer scientists nor the best programmers: after reading a technical article describing some advanced algorithm, a few hours were enough for them to implement concise Julia code whose syntax was identical to the mathematical notation used in the original article.

7 Likes
48

Julia also makes it easier to go lower level than is possible in Fortran for really perfecting performance.
Writing optimized BLAS is a lot easier than Julia than it would be in Fortran IMO.

8 Likes
49

Is JuliaSim a closed-source proprietary commercial product or an open source tool?

50

Still proprietary, like Simulink and for similar reasons. Though we should probably keep this thread on topic.

51

A few points regarding compatibility, reproducibility and encodings:

  1. We take not making breaking changes in 1.x releases of Julia very seriously. We test every registered package in the entire open source ecosystem with every release to make sure we haven’t accidentally broken anything.

  2. We keep binaries for every Julia release. As noted, they’re easy to install and use alongside each other. This is notably not the case for most C, C++ or Fortran compilers, which like to assume they own the entire system — if you want to use more than one version of gfortran at the same time, you’re going to need containers. The upshot is that if you need an old Julia version for whatever reason, you can easily install and use an old version just for one specific project.

  3. While Julia 2.0 will by definition be somewhat breaking (or it would just be 1.x for some value of x), it seems like FUD to suppose that a release that hasn’t yet been made will change everything and break everyone’s code. Especially given that we’ve said the opposite many times: the way Julia code looks and feels is done. I’ll say it again: we are not interesting in making gratuitous annoying changes in Julia 2.0. I wrote more about the kinds of changes that are of interest here. In short, the vast majority of Julia 1 code will keep working in Julia 2.

  4. The way Julia’s package manager works, when you have a Julia project, it gets its own project environment and the manifest file records the exact Julia version (as of Julia 1.7) and the exact version — down to the last bit — of every package dependency (since Julia 1.0) and every binary dependency (since Julia 1.3). You don’t need containers for perfect reproducibility. On the other hand, you cannot achieve this level or reproducibility in C or Fortran without containers — if you code depends on any libraries at all, you are at the mercy of whatever versions of those libraries happen to be installed on your system, and while Fortran the language is very careful about breaking changes, many libraries are not. As a result, you may not be able to compile your project at all, let alone get it to work as it once did. This is not a problem in Julia thanks to manifest files and immutable, content-addressed packages and binary artifacts.

  5. Since Julia 1.5, packages and binaries are downloaded from package servers at pkg.julialang.org which are maintained by the Julia project and which are backed by a replicated system of storage servers that preserve copies of every package and artifact version that anyone ever installs through the package servers (both registered and unregistered versions of registered packages). That means that if you have a manifest that you instantiated via Julia’s package servers once, you will be able to install it forever. This is completely decoupled from GitHub and will continue to work even if GitHub disappears.

  6. ASCII is certainly a venerable standard, but at this point Unicode is no less respectable and is certainly standardized. We’re not just making this stuff up. Julia source is UTF-8, which is a brilliantly designed and carefully specified superset of the ASCII encoding and rapidly becoming the encoding that is used everywhere for everything.

49 Likes
52

I suspect the mention of ASCII may have been a typo and ANSI was intended (see ANSI Standard Fortran), the focus being on community standardization.

The concentration of Julia influence at one company may concern some people with a long-term community focus. PostgreSQL for example has a rule that not too many of the core contributors can be at the same company.

4 Likes
53

Could you perhaps give a little bit more small examples on perhaps why Julia might be easier to get a lousy performance, and how to improve it? Thanks!

54

  1. Use non-constant global variables. Solution: don’t use them. (In Fortran this is a non-issue because all variables have defined types, although not using them is a good practice anyway).

  2. Allocate arrays inside loops. Solution: preallocate and reuse, or use static arrays. (In Fortran, even if a code needs to allocate, it is almost certain that stack allocations will be used and you get the “static arrays” behavior for free).

9 Likes
55

unless heap allocation is explicitly requested by a compiler flag.

56

I have read this many times but I don’t know what that means, not being a software developer. Without derailing the conversation, can you quickly point me to anywhere I can learn about that?

57

This is simple enough there may not be a single page focused on this. An example of the reused allocation pattern is that instead of doing this:

using Statistics
means = zeros(10_000)
for s in 1:10_000
    x = rand(100)
    means[s] = mean(x)
end

You should do this:

using Statistics, Random
means = zeros(10_000)
x = zeros(100)
for s in 1:10_000
    rand!(x)
    means[s] = mean(x)
end

Here you go from allocating x inside the loop to pre-allocating it and reusing it.

8 Likes
58

can it be done “manually”, without using rand!? (sorry, off topic)

59

Since Julia is aiming at writing concise/elegant/beautiful code without sacrificing performance.
I would wish that Julia be perhaps a little bit more intelligent/powerful in automatically optimizing situations like this :grinning:

60

See https://github.com/JuliaLang/julia/pull/41777

7 Likes
61

If you’re coming from Fortran to Julia for heavy number crunching, one performance aspect you might notice is just caused by Julia using the LLVM compiler, which doesn’t generate fused multiply-add (FMA) instructions by default. Thus, you need to opt-in explicitly. Luckily, Julia’s code introspection and manipulation tools make it relatively easy to do, using for example @fastmath from Base or @muladd from MuladdMacro. I have described that in a blog post on optimizing our hyperbolic PDE framework Trixi.jl.
Nevertheless, I definitely like using Julia (since v0.3 many years ago…) in my daily work as scientist working in numerical analysis and applied mathematics. We describe some of the nice aspects in our JuliaCon talk on Trixi.jl. Our team has a strong background in C, C++, and Fortran. Most of us have used an HPC Fortran code before. In our talk, Michael describes why we started to work on a new Julia code (Trixi.jl) and what we like about it. We still have a lot to do, in particular on the HPC side, but we’re pretty happy at the moment. Having said this, the Fortran code is of course still in use and will probably stay alive for quite some time.

6 Likes