What are the main advantages of Julia over modern Fortran from:
- Numeric/computation aspect?
- Non-numeric/non-computation aspect?
Thank you very much!
What are the main advantages of Julia over modern Fortran from:
Thank you very much!
First of all, let me make it clear that I don’t make extensive use of modern fortran so there is a chance I have made a few minor mistakes. If so, please correct me.
Julia Non-numeric advantages.
Plots+DifferentialEquations+IntervalArithmaticwhich can be used to solve differential equations with robust error bars.
do concurrentwhich requires you to use a different compiler to change how your program uses these types of hardware, and doesn’t currently have support for programs that use multiple types of parallelism. Also, I don’t believe there are modern Fortran compilers that work with AMD GPUs (correct me if I’m wrong)
Julia numeric advantages
cos), and do a worse job vectorizing them than Julia +
Rationaletc. This means that it is much easier to write libraries (since you duplicate much less code), and allows for advanced techniques such as autodiff (see below)
I’m sure there’s a lot of stuff I’m missing, but I think this gives a pretty good summary.
Thank you @oscardssmith ! I appreciate your elaboration.
The auto differentiation you mentioned in Julia looks particularly interesting.
I guess if I have the money I will invest in exploring auto diff in Fortran
If I remember correctly, some of the Fortran code written by @jacobwilliams can indeed call some Python stuff from Fortran in some way. E.g.,
I think similar techniques can be used in calling R and Julia from Fortran in some way.
Besides Intel, Nvidia, I think AMD have their version of C/C++/Fortran compiler too (but perhaps not for GPU),
I think Intel’s strong will in GPU market, plus the name and purpose of the free Intel OneAPI and their new IFX, perhaps have already making Fortran running on GPU available.
There is a thread here too about Fortran + GPU programming,
I can be wrong but it seems inevitable that each of the whales like Intel, AMD, Nvidia will keep developing their own distribution of Fortran compiler to particularly optimize for their own hardware. But anyway, for some reason they just do not give up Fortran I guess they have their reasons, perhaps Fortran is relatively easy to be optimized for hardware from compiler level.
Sure, I agree that someone could please split it to a new thread.
I don’t see any reason Python, R, or Julia code couldn’t be used in Fortran if stdin/stdout and pipes were used on *nix systems. There are certainly efficiency concerns regarding that, which is why it isn’t likely seen in practice, when a domain expert could implement the algorithm in Fortran directly, instead of calling out to a less efficient implementation.
Is there something I’m missing or mistaken about?
the big problem is that it will be about 1000x slower. Julia’s interop often shares memory, and when it doesn’t makes a simple memory copy of the data-structure. This isn’t necessarily a problem for 1 time use cases (like initial data-parsing), but will be cost-prohibitive for many use-cases.
So basically Julia embeds another programming language interpreter in its runtime in order to use the libraries. Is that accurate?
No, but the behavior the user sees is similar. What
PyCall (for example) is doing under the hood is making C-calls to Python’s C-api (you link an actual python executable when you build the package). Other language wrappers have some differences, but they mostly work in similar ways.
I believe LFortran has plans for similar features, but they don’t yet exist.
Do you have any idea on how linking to a Python, R, or Julia binary affects performance relative to linking a direct C/C++ implementation? I’d imagine it an order of magnitude slower, but don’t trust my intuition in this area.
The short answer is linking to Python/R gives you roughly the speed of the python/R code. This is typically between 2x slower (if the python/R calls out to C before doing a lot of work) and 100x (if it’s pure python). This is often completely acceptable for non performance-critical code.
Linking to Julia vs linking to C is totally implementation dependent. Julia is as fast as C for equivalent code, but code is rarely equivalent.
There seems to be some missing history here. The creators of Julia took FreeBSD libm source code and created OpenLibm. OpenLibm then provided math functions (eg,
cos) for Julia. Along the way, OpenLibm/Julia contributors were wiling to accept patches from someone, who worked on improvements to FreeBSD libm, but never seemed to reciprocate. At some point, it seems that Julia contributors took a Not-In-My-House approach and decided to re-implement the math functions.
It should also be noted that the likely most popular open-source Fortran processor runs on dozens of operating systems and CPU architectures. Instead of wasting the open-source Fortran-processor developers’ time, the open-source Fortran-processor developers decided to rely on the libm as specified in the C standard and provided by the operating system.
Can you define what you mean by relatively poor implementations? Where are the superior algorithms, used by Julia, documented?
The basic reason for the switch to special functions implemented in Julia is that they are (in my opinion at least) easier to write, and are easier for the compiler to vectorize. The downside of relying on OS provided LIBM is that (especially on windows) they are a buggy mess (for example, the windows
fma implementation produces incorrect results in hard to round cases, and is generally really slow). Also using OS provided LIBM means that different operating systems produce different results.
What I mean by “relatively poor implimentation” is that this thread revealed that idiomatic code in Fortran was slower due to worse implementations of trig functions. In general, algorithms Julia uses are not documented externally, but are tested a ton to make sure they have high accuracy, and the source is easy to read if you want to port them. The speedups generally come from very carefully chosen polynomial coefficients and reductions strategies.
Fpm is still a relatively young effort, so this specific comparison is somewhat of an underestimation. The amount of Fortran libraries is bigger once you factor in codes from Netlib, the Fortran-lang Package Index, vendor libraries like NAG and IMSL, and dozens of other codes scattered throughout the internet.
Julia’s fast growth is impressive by all means, so is the variety and sophistication of some of the flagship packages. We are already seeing Julia drive new trends in computing, so I expect the interaction between the two communities will increase.
However, I will note fast growth does have some cons. The amount of deprecated Julia packages seems to grow monthly. This fast growth and hence instability was a big deterrent when I tested Julia, 6 or 7 years ago. I read the situation has become better now.
I’m familiar with that thread. My conclusion was that micro-benchmarks typically find what the individual went looking for. I also concluded that generalizations are rampant in FD. The failure(s) of Microsoft’s libm is somehow extended to all other libm. Having contributed quite a bit to FreeBSD’s libm, minimax polynomial coefficients are carefully chosen as are computation strategies.
Then why not interface with another math library? For instance i work with the crlibm library as I want functions that consistently give the same results. But there is no reason you couldn’t link against a high-performance library instead (assuming on exists). Writing the interface to crlibm (which is in c) was tedious but straight forward and once done can be completely forgotten about.
There are multiple BLAS/LAPACK implementations out there optimized for different problems/architectures. No reason there shouldn’t be multiple libm’s optimized for different problems/architectures.
There are 2 reasons I often use Fortran instead of Julia
Linking against a high quality libm would have been a totally reasonable solution, but Julia’s approach has 2 advantages.
ais constant, Julia can (at least theoretically, I forget whether it currently does) see that this is implimented as
log(a)(technically it would be precomputing an extended precision version, but the point still stands). Similarly, the compiler can sometimes figure out ways of automatically vectorizing your code that includes special functions which can give a free 2-4x speed boost.
@code_nativethat allow users to look at implementations. Using pure Julia implementations where feasible increases the number of users who look at the code, and therefore lowers barriers for new users who want to learn about numeric methods. If you link statically compiled binaries, you create black boxes that cause knowledge to silo.
I don’t in any way mean to disparage the incredible work that has been put into GLIBC and FreeBSD’s Libm. Both are exceptional pieces of software. However Windows users are either a majority of Julia users, and to the extent possible, we like to give them nice things as well.
Invited FortranCon talk by Leandro Martinez (@lmiq) may be interesting to readers here:
I don’t have the technical knowledge of Oscar and of the other ones here. But from a user perspective I have the feeling that
Julia main advantages are:
packages manager and the API for using numerical algorithms (from linear algebra and optimization, where I know anything about). That is much easier in Julia, even when the underlying code is a Fortran library.
tooling for code analysis and benchmarking
the possibility of benchmarking tiny peaces of code realistically using the repl (this is quite unique to Julia, as it is a combination of the JIT compilation and the tooling). For me this was a game changer, because it allows improving the code in a modular way more safely both in terms of performance and code structure.
code distribution: it is easier to tell someone to install Julia and run a bunch of commands in the Julia repl than to install a compiler, etc. Particularly for non-CS windows users.
Easy to show all numerics and analysis (plots etc) in the same language
Vantages of Fortran:
code distribution: if you want to just distribute small binary, no comparison here. Also very important is the possibility of turning the code into a fast python library. I hope that will change, because I like Julia much more than python, but the user bases are not really comparable now. And while possible, providing a Julia code to be used from python is sort of a workaround, and carries over the Julia compilation overhead.
stability: having a package which is turning 20 and knowing that it will always compile and run with the same instructions is of course very nice. Julia has tools for reproducibility that are very nice, but I can’t expect a new user of my package to deal with these.
better compiler error messages, of course
For those interested in that idea, here are a few links for further study:
Julia’s OpenLibm: https://openlibm.org/
Github clone of crlibm: GitHub - taschini/crlibm: A mirror of the CRLibm project from INRIA Forge
Metalibm GitHub - metalibm/metalibm: Code generation tool to generate mathematical libraries
It is an apparent successor, if the Rust page can be believed.
Last link to metalibm site from archive.org (August 2021):
Old GCC discussion of including crlibm as part of the codebase: Uros Bizjak - Using crlibm as the default math library in GCC sources