What is the advantage of Julia over Fortran?

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?

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

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

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:

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

7 Likes

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

I don’t think automatically changing rand(100) into something like x = zeros(100) combined with a later rand!(x) will ever be done automatically. The reason is that while this transform may be “obvious” for people in this case, for the compiler it may not be and on top if that, the compiler has to be able to do this in the general case, which is going to be much more complicated than this little loop here.

I think even with the immutable array optimization PR, the API would be split into “give me readonly memory” and “give me writable memory”, in which case the compiler is free to transform the former into the rand! version because from the semantics of the original code, there’s no danger in overwriting it.

I also think that such an automatic transform would make it much harder to reason about the performance of some piece of code, because it then relies on an optimization that may not always be applied, and coming up with simple rules for when it is applied is potentially very hard.

1 Like

I agree that Julia takes compatibility and reproducibility very seriously, but I think that it is honest to say that Fortran also does it, and to a degree not seen before or after.

Without entering in a useless discussion, I want to clarify some things:

I agree. And Honestly, I will be more happy if Julia would never move to 2.X. This is basically what Fortran does.

¿What happens with your binaries if we move away from amd64? The statement of different compiler version is just wrong. I have several versions of gfortran installed (no containers). FreeBSD even allows you to get them from the package manager.

No intention to spread FUD. And good to know that these are the intentions. Sometimes I read long discusions like this (rename `angle` to `phase` (or something else) in 2.0 · Issue #35538 · JuliaLang/julia · GitHub) and I get really worried. These are the discussions that I do not really understand. If you do not like angle(z), or even if we all agree that is an unfortunate name, I would be very happy if it is just deprecated, but that it keeps working. I certainly would not understand making a sed -e "s/angle/arg/g" for trivialities.

It is very good to know that Julia will live with the decisions made in the past (even if they are suboptimal), and only produce breaking changes if they bring improvements impossible to obtain by just adding things to 1.X.

Fortran code does not depend on many external libraries (maybe BLAS/LAPACK). The rest you code it yourself with only the standard… Most of the timees if you use some library you have to compile it yourself, which has the advantage that you have the complete sources of your code.

It would be great if there were a way to dowload and tar the exact sources of a project and that julia progresses in the direction of making possible to generate an executable from these sources (I know that there are works in thiss directions). If even to Julia 2.X, you could pass a command line argument (-v1) to geneate the executable of Julia 1.X that would be a very big step in my opinion.

I have taken a 30 years old fortran 77 code written for a CDC Cyber out of a magnetic tape. Passed one of its functions to a minimization code using genetic algorithms in fortran 2003 and everything compiled (and worked correctly) without a single line change in a Linux 64bit machine. I think that one has to acknowledge how amazing and good for scientific work this is.

4 Likes

I don’t think that’s 100% correct. Fortran 77 (fixed) syntax is incompatible with Fortran 90+ (free) syntax. While most compilers are able to digest both, you need to tell them which format to use, for example by using the right file extension or an appropriate compiler flag. While the end effect is that with a recent compiler you can likely compile both Fortran 77 and 90+, that doesn’t mean they’re completely compatible. That’s kind of like if Julia 2.x had also the possibility to run Julia 1.x code with a switch.

1 Like

I think that this is not accurate. A compiler that supports the fortran 77/90/03/08 standards must allow you to produce a single executable with one file in fixed fortran that contains functions in fortran 77 and another file in free format that contains a fortran 90 module. (obviously you cannot mix fixed/free format in the same file, but these different formats can be part of the same code).

Note that this is very powerful… my routine for integration using Simpson rule was written many years ago. Today I can call this routine in a fortran 2008 program that uses paralellization with coarrays. I do not need to “port” my old codes.

To achieve this in Julia, it should be possible in Julia 2.X to write using MyModuleInV1, and that it works without changing anything. If this is achieved, that would certainly be great, and basically equivalent to what fortran does (adding new functionalities, without breaking compatibility with previous standards). I would be extremely happy if something similar to this approach is taken: my current code would be perfectly portable to v2, without a single change.

1 Like

What is not accurate in what I said? Compilers build intermediate object files, at which point the originating source code doesn’t matter anymore, and they then combine the object files into the final binary product.

Your observation is incorrect. Fixed-form vs. Free-form is not about syntax, it is about form or format. You can write Julia on a whiteboard or carve the letters into stone. In either case, it is the same code. Similarly, you can write Fortran 2018 via punch cards, in fixed-format or free-format, or write FORTRAN66 in modern free format. Remarkably, a language of the era of punch cards has remained backward-compatible for seven decades, while Julia, only ten years old, is already discussing mitigation strategies for the impending damages of a Julia 2.

1 Like

This is not accurate:

Fortran 77 is 100% compatible with Fortran 90. You can call your F77 functions inside a F90 program without changing a single line. As commented below free/fixed format is not about F77/F90.

I insist in this point: Full compatibility means that in your future Julia 2.X program you can using MyModV1 and that everything works. If the design of Julia 2.X takes this seriously as a priority I would be extremely happy. This is basically what fortran has achieved during the last 50 years (in _CRAY machines, clusters, personal computers, laptops, mac, linux, windows, etc…). It is absolutely amazing, and I think that it has a lot to do with why fortran has the place it has in scientific computing. It would be great if Julia (as I said, an amazing language that blew my mind when I saw it), takes this experience very seriously.

1 Like

I think there are some mixups here. Are you @shiroghost talking about

  • compiling Fortran 77 code with a Fortran 90 compiler

or are you talking about

  • calling into already compiled Fortran 77 code from code written with Fortran 90?

While subtle, there is a difference, because I don’t think you can use the exact same compiler (i.e., that’s what the flag mentioned by @giordano would do, switch to a different compiler internally in the compiler executable) to compile Fortran 77 and Fortran 90 to a binary artifact (which you could call from anything that understands ELF files on linux, irrespective of the original language the code was written in).

Syntax → form, fair enough, but then what I’m trying to say is that once something is compiled down to binary the originating source code doesn’t matter anymore. You can also call a Fortran 77/90+ or C functions compiled into a shared library inside a Julia program, does that mean that Julia is compatible with (in the sense it has the same syntax as) Fortran/C (which is what @Sukera just pointed out above)?

All fortran compilers that I know, can compile fortran77. For example:

gfortran file1.f77 file2.f90 main.f08 -o analysis.x

Works perfectly, with file1.f77 being a bunch of functions written in fortran 77 35 years ago (in fixed format), file2.f90 being a module in fortran 90 written 20 years ago, and main.f08 being a fortran 2008 main program that uses paralellization via coarrays.

The main point is not that this works for the special case of gfortran. The point is that it must work for any compiler that claims to support the F77/90/03/08 standards.

Not lfortran, according to its documentation which mentions only Fortran 2018 (but I never tried it myself)

1 Like

If that is the case, it would be a 1.X. Fortran is “1.X” and will will always be apparently. This has its virtues, but it does slow down improvements. There are discussions on the Fortran list also with opposite view: that keeping backwards compatibility is killing Fortran adoption. I don’t have a definite opinion on that, but in general I find that it is not realistic to expect anything in computing to last too long.

What Stephan said is that there will be a Julia 2.0 if the changes are worth the breaking cost.

That is work in progress.

4 Likes

Right, but again, these files are not catable and compiled as one unit (which is what we’re talking about when talking about syntax). What gfortran does (as far as I can tell) is determine based on the file extension which format/fortran version the source code is written in, compile that independently to machine code and then link it all together after the fact (at which point, it’s all machine code and there is no more fortran for the compiler to look at). In essence, gfortran contains several different fortran compilers, each for a different version of Fortran. This is a different kind of beast from compiling it all as one unit. It’d be akin to compiling fixed form F77 with gfortran -ffree-form file1.f77, which obviously won’t work.

Sure, julia could do something similar, but that again has nothing to do with whether or not julia introduces breaking or non-backwards compatible changes. It’d mean including the old julia compiler with the new version and doing some autodetection for which compiler to use internally.

4 Likes

You may be right, but I think this is a reasonable trade-off.

Supporting code from decades ago with the latest version of a language may have been important in the 1970s when most papers required less than a few hundred or thousand LOC which was mostly self-contained.

But when packages are used, things move on anyway so running some code with the original version of the language in a reproducible environment is an acceptable extra cost for most people. Running code from a project written for Julia 1.x will remain possible practically forever, even if it may be a minor hassle in a few decades.

In the meantime, breaking compatibility in minor ways when it matters allows a language to develop.

9 Likes