5 ms·

I'm kind of on the fence with Julia, never used it in anger. But to me it seems much more of a Matlab or Python replacement than a Fortran replacement? Meaning

I'm kind of on the fence with Julia, never used it in anger. But to me it seems much more of a Matlab or Python replacement than a Fortran replacement? Meaning that (in my perhaps limited view) it's main usefulness is in making algorithm development much faster and smoother. However, once a new very fast algorithm has been discovered and tested and everyone agrees it is good, someone will probably implement it in Fortran or C or even assembly and optimize the shit out of it. One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia.

adgjlsfhk1 4y ago
For some examples of people porting existing C++ Fortran libraries to julia, you should check out https://github.com/JuliaLinearAlgebra/Octavian.jl https://github.com/JuliaLinearAlgebra/Octavian.jl, https://github.com/dgleich/GenericArpack.jl https://github.com/dgleich/GenericArpack.jl, https://github.com/apache/arrow-julia https://github.com/apache/arrow-julia (just off the top of my head). These are all ports of C++ or Fortran libraries that match (or exceed) performance of the original, and in the case of Arrow.jl is faster, more general, and 10x less code.
ssivark 4y ago
> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia. This is totally off-base :-) There’s even discussion of implementing a lot of linear algebra stuff in Julia, instead of just falling back to BLAS (for very good reasons), see eg https://youtu.be/KQ8nvlURX4M https://youtu.be/KQ8nvlURX4M Those wrappers are just to bootstrap the ecosystem for immediate usefulness. So, over time, I expect Julia to become better and better for everything from exploratory development to workhorse numerical computing infrastructure. Once compiled binaries are feasible, I wouldn’t be surprised if other languages start wrapping algorithms implemented in Julia.
eigenspace 4y ago
As with the others, I'll strongly disagree and chime in with a few examples off the top of my head: - ITensors.jl : They started moving from a C++ to Julia a couple years ago and now their webpage doesn't even mention their original C++ implementation on its homepage anymore https://itensor.org/ https://itensor.org/ - DifferentialEquations.jl : This has many state of the art differentiatial equation solving facilities in it, many of which are improvements over old Fortran libraries. - SpecialFunctions.jl, Julia's own libm, Bessels.jl, SLEEFPirates.jl : Many core math functions have ancient Fortran or C implementations from OpenLibm or whatever, and they're being progressively replaced with better, faster versions written in pure julia that outperform the old versions.
sundarurfriend 4y ago
> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries That's an understandable misconception. But the reason these packages use C/Fortran libraries is because they're already there, and writing a wrapper is much easier than rewriting the library in Julia. It's not a performance thing, it's a person-hours thing and wanting to use the libraries right now. On the one hand, this means you have binary dependencies and FFI you have to manage. On the other hand, it saves you a lot of niggly optimization work and dealing with edge cases, which the C/Fortran libraries have already gone through and done for you. Once the former starts to outweight the latter and/or more person-hours become available, the libraries start to get ported to be fully in Julia. And the tools available in the ecosystem and the compiler codegen are good enough that there's no artifical performance ceiling due to being in Julia i.e. you do get performance equivalent to being in C or Fortran.

adgjlsfhk1 4y ago

For some examples of people porting existing C++ Fortran libraries to julia, you should check out https://github.com/JuliaLinearAlgebra/Octavian.jl https://github.com/JuliaLinearAlgebra/Octavian.jl, https://github.com/dgleich/GenericArpack.jl https://github.com/dgleich/GenericArpack.jl, https://github.com/apache/arrow-julia https://github.com/apache/arrow-julia (just off the top of my head). These are all ports of C++ or Fortran libraries that match (or exceed) performance of the original, and in the case of Arrow.jl is faster, more general, and 10x less code.

ssivark 4y ago

> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia. This is totally off-base :-) There’s even discussion of implementing a lot of linear algebra stuff in Julia, instead of just falling back to BLAS (for very good reasons), see eg https://youtu.be/KQ8nvlURX4M https://youtu.be/KQ8nvlURX4M Those wrappers are just to bootstrap the ecosystem for immediate usefulness. So, over time, I expect Julia to become better and better for everything from exploratory development to workhorse numerical computing infrastructure. Once compiled binaries are feasible, I wouldn’t be surprised if other languages start wrapping algorithms implemented in Julia.

eigenspace 4y ago

As with the others, I'll strongly disagree and chime in with a few examples off the top of my head: - ITensors.jl : They started moving from a C++ to Julia a couple years ago and now their webpage doesn't even mention their original C++ implementation on its homepage anymore https://itensor.org/ https://itensor.org/ - DifferentialEquations.jl : This has many state of the art differentiatial equation solving facilities in it, many of which are improvements over old Fortran libraries. - SpecialFunctions.jl, Julia's own libm, Bessels.jl, SLEEFPirates.jl : Many core math functions have ancient Fortran or C implementations from OpenLibm or whatever, and they're being progressively replaced with better, faster versions written in pure julia that outperform the old versions.

sundarurfriend 4y ago

> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries That's an understandable misconception. But the reason these packages use C/Fortran libraries is because they're already there, and writing a wrapper is much easier than rewriting the library in Julia. It's not a performance thing, it's a person-hours thing and wanting to use the libraries right now. On the one hand, this means you have binary dependencies and FFI you have to manage. On the other hand, it saves you a lot of niggly optimization work and dealing with edge cases, which the C/Fortran libraries have already gone through and done for you. Once the former starts to outweight the latter and/or more person-hours become available, the libraries start to get ported to be fully in Julia. And the tools available in the ecosystem and the compiler codegen are good enough that there's no artifical performance ceiling due to being in Julia i.e. you do get performance equivalent to being in C or Fortran.