Why Fortran is easy to learn

1. Octavian.jl

   1 17 241 3.9 Julia

   Multi-threaded BLAS-like library that provides pure Julia matrix multiplication

   

   > But in the end, it's FORTRAN all the way down. Even in Julia.

   That's not true. None of the Julia differential equation solver stack is calling into Fortran anymore. We have our own BLAS tools that outperform OpenBLAS and MKL in the instances we use it for (mostly LU-factorization) and those are all written in pure Julia. See https://github.com/YingboMa/RecursiveFactorization.jl, https://github.com/JuliaSIMD/TriangularSolve.jl, and https://github.com/JuliaLinearAlgebra/Octavian.jl. And this is one part of the DiffEq performance story. The performance of this of course is all validated on https://github.com/SciML/SciMLBenchmarks.jl

2. CodeRabbit

   coderabbit.ai featured

   CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.

   

3. RecursiveFactorization.jl

   2 8 77 4.7 Julia

   

   Julia defaults to OpenBLAS but libblastrampoline makes it so that `using MKL` flips it to MKL on the fly. See the JuliaCon video for more details on that (https://www.youtube.com/watch?v=t6hptekOR7s). The recursive comparison is against OpenBLAS/LAPACK and MKL, see this PR for some (older) details: https://github.com/YingboMa/RecursiveFactorization.jl/pull/2... . What it really comes down to in the end is that OpenBLAS is rather bad, and MKL is optimized for Intel CPUs but not for AMD CPUs, so when the best CPUs are now all AMD CPUs, having a new set of BLAS tools and mixing that with recursive LAPACK tools is either as good or better on most modern systems. Then we see this in practice even when we build BLAS into Sundials for 1,000 ODE chemical reaction networks (https://benchmarks.sciml.ai/html/Bio/BCR.html).

4. julia

   3 366 46,635 10.0 Julia

   The Julia Programming Language

   

   Yeah no worries. You might want to join in the community at least because this kind of discussion is par for the course on the Slack. You might find a nice home here!

   > though its threading implementation may not be robust

   That's one of the main issues I have with it. Its poor threading behavior coupled with a bad default (https://github.com/JuliaLang/julia/issues/33409 one of my biggest pet peeve issues right now) really degrades real user performance.

5. quickjs

   4 73 8,958 6.8 C

   Public repository of the QuickJS Javascript Engine.

   

   Ancient LISP and BASIC variants also stand out in this regard of not requiring you to undergo years of training and theory to implement and fully understand.

   Fabrice Bellard's minimalist but complete quickjs.c Javascript interpreter is presently about 54,000 lines of C:

     https://github.com/bellard/quickjs/blob/master/quickjs.c

6. TriangularSolve.jl

   5 1 12 4.9 Julia

   rdiv!(::AbstractMatrix, ::UpperTriangular) and ldiv!(::LowerTriangular, ::AbstractMatrix)

   

   > But in the end, it's FORTRAN all the way down. Even in Julia.

   That's not true. None of the Julia differential equation solver stack is calling into Fortran anymore. We have our own BLAS tools that outperform OpenBLAS and MKL in the instances we use it for (mostly LU-factorization) and those are all written in pure Julia. See https://github.com/YingboMa/RecursiveFactorization.jl, https://github.com/JuliaSIMD/TriangularSolve.jl, and https://github.com/JuliaLinearAlgebra/Octavian.jl. And this is one part of the DiffEq performance story. The performance of this of course is all validated on https://github.com/SciML/SciMLBenchmarks.jl

7. SciMLBenchmarks.jl

   6 10 324 9.7 MATLAB

   Scientific machine learning (SciML) benchmarks, AI for science, and (differential) equation solvers. Covers Julia, Python (PyTorch, Jax), MATLAB, R

   

   > But in the end, it's FORTRAN all the way down. Even in Julia.

   That's not true. None of the Julia differential equation solver stack is calling into Fortran anymore. We have our own BLAS tools that outperform OpenBLAS and MKL in the instances we use it for (mostly LU-factorization) and those are all written in pure Julia. See https://github.com/YingboMa/RecursiveFactorization.jl, https://github.com/JuliaSIMD/TriangularSolve.jl, and https://github.com/JuliaLinearAlgebra/Octavian.jl. And this is one part of the DiffEq performance story. The performance of this of course is all validated on https://github.com/SciML/SciMLBenchmarks.jl

8. Fortran-code-on-GitHub

   7 9 336 9.8

   Directory of Fortran codes on GitHub, arranged by topic

   

   There's modern stuff being written in astro(nomy/physics) (I can attest to some of the codebases listed in https://github.com/Beliavsky/Fortran-code-on-GitHub#astrophy... being modern, at least in terms of development), but I'd say C++ likely does have the upper hand for newer codebases (unless things have changed dramatically last time I looked, algorithms that don't nicely align with nd-arrays are still painful in Fortran).

   I've also heard rumours of Julia and even Rust being used (the latter because of the ability to reuse libraries in the browser e.g. for visualisation), but the writers of these codebases (and the Fortran/C/C++/Java) are unusual—Python and R (and for some holdouts, IDL) are what are most people write in (even if those languages call something else).

9. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

10. 18337

    8 14 232 5.7 Jupyter Notebook

    18.337 - Parallel Computing and Scientific Machine Learning

    

11. 18335

    9 1 515 8.3 Jupyter Notebook

    18.335 - Introduction to Numerical Methods course

    

12. BLIS.jl

    10 1 25 1.3 Julia

    This repo plans to provide a low-level Julia wrapper for BLIS typed interface.

    

    It doesn't look like you're measuring factorization performance? OpenBLAS matrix-matrix multiplication is fine, it just falls apart when going to things like Cholesky and LU.

    > not the default, I've now checked

    Whatever the Julia default build is doing, so probably not the recursive LAPACK routines then if that's how it's being built. If there's a better default that's worth an issue.

    > That said, I don't understand why people avoid AMD's BLAS/LAPACK

    There just isn't a BLIS wrapper into Julia right now, and it's much easier to just write new BLAS tools than to build wrappers IMO. It makes it very easy to customize to nonstandard Julia number types too. But I do think that BLIS is a great project and I would like to see it replace OpenBLAS as the default. There's been some discussion to make it as easy as MKL (https://github.com/JuliaLinearAlgebra/BLIS.jl/issues/3).

13. MPI.jl

    11 3 390 7.3 Julia

    MPI wrappers for Julia

    

14. CUDA.jl

    12 15 1,266 9.5 Julia

    CUDA programming in Julia.

    

15. rr

    13 114 9,574 9.5 C++

    Record and Replay Framework

    

    It depends a bit on what you want, but https://rr-project.org/ works really well with julia

16. GPUCompiler.jl

    14 5 160 8.8 Julia

    Reusable compiler infrastructure for Julia GPU backends.

    

17. Pkg.jl

    15 5 629 9.0 Julia

    Pkg - Package manager for the Julia programming language

    

18. SuiteSparse.jl

    16 1 25 6.7 Julia

    Discontinued Development of SuiteSparse.jl, which ships as part of the Julia standard library.

    

19. SaaSHub

    www.saashub.com featured

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    

Suggest a related project