Hacker News Reader

Comment by vsskanth | Hacker News Reader

There's no mention of distribution, which is a huge advantage for rust since it compiles to a static binary.

There are many applications where the algorithms are written by a specialist which is then compiled into a static binary for use in another application or UI. This is why FORTRAN C and C++ are so popular in the scientific computing field for writing numerical algorithms. It's not just for speed, there is clear separation of concerns here.

Julia is still far behind here as you can't compile to a GC free static binary yet. There is PackageCompiler.jl but it appears it makes large binaries.

Scientific analysis and plotting is just one aspect, ultimately your algorithms would have to be distributed for use by others.

View on HN

Hardly irrelevant to a community used to R, Python, Mathematica and MatLab.

Fortran, C and C++ are popular due to the way they allow to explore HPC infrastructure, which Rust is still years away to support, and Julia is already ahead in that regard.

MPI, SIMD, OpenMP, NUMA algorithms across the computation cluster.

Is there something like OpenMP for rust? (there must be...) But I imagine MPI is probably not a great fit...

There's rayon, which in my opinion makes writing multi threaded code even simpler than openmp. It's also nice that it doesn't rely on any compiler feature. It's just a library.

Rayon doesn't do GPGPU offloading.

https://www.openmp.org/updates/openmp-accelerator-support-gp...

Plus vendor compilers often outperform GCC and LLVM… on Cray systems especially

Can Julia take advantage of that?

Cray is pushing their own language as well, Chapel.

https://chapel-lang.org/

As for Julia on Cray,

"Julia — The Newest Petaflop Family Language We Have Started to Love"

https://www.avenga.com/magazine/julia-programming-language

> Julia is one of the few languages that are in the so-called PetaFlop family; the other languages are C, C++ and Fortrant. It achieved 1.54 petaflops with 1.3 million threads on the Cray XC40 supercomputer.

But specifically because of the proprietary compiler? Or is it just calling Fortran / C / C++ libraries that were compiled with their compiler?

The program is Celeste: https://juliahub.com/case-studies/celeste/index.html

It seems to be pure Julia.

Julia uses the LLVM compiler; I’m pretty sure that’s the only platform, aside from experiments compiling to WASM.

The compiler is free and open source, not proprietary. It is built on LLVM, which is also FOSS.

And Julia code is not Fortran/C/C++, not sure what you are asking.

The comment I replied to said: "Plus vendor compilers often outperform GCC and LLVM… on Cray systems especially".

I said "Can Julia take advantage of that?". So the "that" in my question was "vendor compilers [which] often outperform GCC and LLVM... on Cray systems especially".

It seems like the answer is, no, Julia cannot be compiled with those vendor compilers that often outperform LLVM.

But it seems that Julia nonetheless has been shown to perform well, just not specifically by using those vendor compilers that I was asking about.

My understanding is that the Julia Petaflops run executed a Julia program per node, communicating via MPI. For some, that's probably obvious/expected for HPC; for others, it might not be considered "pure Julia".

That's how it works in any language on a supercomputer. MPI is pretty much the only game in town for inter-node communication.

@cbkeller: Though MPI is dominant in HPC by a very large margin, it's definitely not the only game in town. SHMEM is an MPI alternative with a smaller but very dedicated following. UPC, Fortran 2008, UPC++, and Chapel are all alternatives that support inter-node communication without relying on MPI or explicit library communication calls. Chapel has the additional advantage of not imposing the SPMD programming model on the user and supporting asynchronous dynamic tasking.

It's my understanding that Julia aspires to join this group of languages if it is able to do so, which is why the Petaflops announcement was originally enticing to me, and then became somewhat less so once I learned that it was relying on MPI.

In theory, but it’s usually specific optimisations that work well on HPC codes that they’d need to replicate at the LLVM level: https://www.umr-cnrm.fr/aladin/IMG/pdf/compilers_elsinore_re...

Awesome, thanks for the link!

> There's no mention of distribution, which is a huge advantage for rust since it compiles to a static binary.

Frustrating article. Not only does it levy unfair criticism against Julia, it misses on one obvious legitimate complaint.

Rust can be compiled today, no caveats.

Yes. I work on a project that calls into Julia from Python, and the dynamic packaging has been (IMO) a nightmare. It would be so excellent if I had a static library to link against instead!

C and fortran win here because of ABI... (and C++ sorta...)

Reply on news.ycombinator.com