3 ms·

It's for high-performance numerical work. The language of choice in scientific computing is still Fortran, and for good reason. Julia has become my go-to langua

It's for high-performance numerical work. The language of choice in scientific computing is still Fortran, and for good reason. Julia has become my go-to language for new codes, but Fortran still has its place. In particular, Julia is slow to be adopted by supercomputers.

kgwgk 8y ago
> Fortran > codes I think there is a large overlap between users of that language and users of that word.
dnautics 8y ago
You can very easily deploy Julia in supercomputing centers via singularity containers (assuming the SC center supports singularity).
tejtm 8y ago
We are in luck as Julia seamlessly integrates with FORTRAN(and C)[0]. That is, if set up properly, LLVM does not care what language it is being asked to JIT compile even when they are mixed together in the same file. I am hoping for a nice web assembly[1] emitted from Julia [0] https://docs.julialang.org/en/stable/manual/calling-c-and-fortran-code/ https://docs.julialang.org/en/stable/manual/calling-c-and-fo... [1] https://webassembly.org/ https://webassembly.org/
- ChrisRackauckas 8y ago
  This has some working prototypes: https://github.com/MikeInnes/WebAssembly.jl https://github.com/MikeInnes/WebAssembly.jl
StefanKarpinski 8y ago
Slow but not non-existent: https://juliacomputing.com/case-studies/celeste.html https://juliacomputing.com/case-studies/celeste.html It's tough to crack the old school high-performance computing world, which is very slow to change programming tools, but Julia is the first and only high-level dynamic programming language to do it. Now that it's been shown to be possible to exceed a petaflop/second in Julia without having to write any gnarly, low-level C++ code, I suspect we'll start to see it happening more in the future.
- hpccurious 8y ago
  Did Celeste rely on pure Julia code to achieve its petafloppiness or were there other libraries at play, say Intel MPI, OFED and IB drivers, RDMA functionality, any custom C++ at all, etc? How much in the way of low-level distributed bit twiddling was part of the development of that application? Would anyone not named Keno be able to write a similar application?
  - tavert 8y ago
    All of the MPI communication was happening in C code (the built-in distributed code in Julia exists, and sometimes works, but that's the nicest thing you can say about it - it has not been leaned on heavily at all, and is often awkward to use). Lots of low level bit twiddling was involved in Celeste. Without Keno that application would have been lucky to top 100-200 teraflops.
  - StefanKarpinski 8y ago
    Libraries like LAPACK and MPI were standard C/Fortran ones wrapped from Julia but all of the custom application code was written in Julia. No doubt the application would not have been so successful without the extremely talented team that worked on it—including Keno, who was described by the project PI as a “one man army”—but that’s true of any record-setting supercomputing project.
geoalchimista 8y ago
> "The language of choice in scientific computing is still Fortran, and for good reason." Except that this is not always true. R, Scala, and spark are heavily used in bioinformatics. Physicists and quantum chemists nowadays use C++ more often than Fortran when they build new models and libraries. Astronomers use Python. The only scientific fields that get stuck forever with Fortran seem to be climate modeling and weather forecasting (and they continue to use Fortran 90 and pretend the most recent Fortran 2008 standard does not exist). Edit: I'm not saying Fortran isn't good. It's the best for bit twiddling. Offloading the performance critical part from Python or other high-level languages to Fortran is great. The problem is, in an academic setting, a lot of scientists untrained in programming choose to write programs from scratch in Fortran, which is too taxing on the debugging, testing, and maintenance time.
- zem 8y ago
  when i was a high-energy-physics grad student back in 1997 we were already using c++ rather than fortran

kgwgk 8y ago

> Fortran > codes I think there is a large overlap between users of that language and users of that word.

dnautics 8y ago

You can very easily deploy Julia in supercomputing centers via singularity containers (assuming the SC center supports singularity).

tejtm 8y ago

We are in luck as Julia seamlessly integrates with FORTRAN(and C)[0]. That is, if set up properly, LLVM does not care what language it is being asked to JIT compile even when they are mixed together in the same file. I am hoping for a nice web assembly[1] emitted from Julia [0] https://docs.julialang.org/en/stable/manual/calling-c-and-fortran-code/ https://docs.julialang.org/en/stable/manual/calling-c-and-fo... [1] https://webassembly.org/ https://webassembly.org/

ChrisRackauckas 8y ago
This has some working prototypes: https://github.com/MikeInnes/WebAssembly.jl https://github.com/MikeInnes/WebAssembly.jl

StefanKarpinski 8y ago

Slow but not non-existent: https://juliacomputing.com/case-studies/celeste.html https://juliacomputing.com/case-studies/celeste.html It's tough to crack the old school high-performance computing world, which is very slow to change programming tools, but Julia is the first and only high-level dynamic programming language to do it. Now that it's been shown to be possible to exceed a petaflop/second in Julia without having to write any gnarly, low-level C++ code, I suspect we'll start to see it happening more in the future.

hpccurious 8y ago
Did Celeste rely on pure Julia code to achieve its petafloppiness or were there other libraries at play, say Intel MPI, OFED and IB drivers, RDMA functionality, any custom C++ at all, etc? How much in the way of low-level distributed bit twiddling was part of the development of that application? Would anyone not named Keno be able to write a similar application?
- tavert 8y ago
  All of the MPI communication was happening in C code (the built-in distributed code in Julia exists, and sometimes works, but that's the nicest thing you can say about it - it has not been leaned on heavily at all, and is often awkward to use). Lots of low level bit twiddling was involved in Celeste. Without Keno that application would have been lucky to top 100-200 teraflops.
- StefanKarpinski 8y ago
  Libraries like LAPACK and MPI were standard C/Fortran ones wrapped from Julia but all of the custom application code was written in Julia. No doubt the application would not have been so successful without the extremely talented team that worked on it—including Keno, who was described by the project PI as a “one man army”—but that’s true of any record-setting supercomputing project.

geoalchimista 8y ago

> "The language of choice in scientific computing is still Fortran, and for good reason." Except that this is not always true. R, Scala, and spark are heavily used in bioinformatics. Physicists and quantum chemists nowadays use C++ more often than Fortran when they build new models and libraries. Astronomers use Python. The only scientific fields that get stuck forever with Fortran seem to be climate modeling and weather forecasting (and they continue to use Fortran 90 and pretend the most recent Fortran 2008 standard does not exist). Edit: I'm not saying Fortran isn't good. It's the best for bit twiddling. Offloading the performance critical part from Python or other high-level languages to Fortran is great. The problem is, in an academic setting, a lot of scientists untrained in programming choose to write programs from scratch in Fortran, which is too taxing on the debugging, testing, and maintenance time.

zem 8y ago
when i was a high-energy-physics grad student back in 1997 we were already using c++ rather than fortran