Comment by npalli | Hacker News Reader

Comment by npalli | Hacker News Reader

Ok, so a not very representative tl;dr was provided so adding mine here.

1. Serial CPU performance of Julia-unoptimized was around 12 times that of Python/Numpy.

2. Serial CPU performance of Julia optimized gave another 10-12x improvement leading to total 140x improvement over Python/Numpy.

(good pointers on speeding up the Python code beyond Numpy listed but not tried or benchmarked)

3. Even though the GPU was rated for a listed performance of 9.7TFlops (A100) the code performed around the same as the optimized Serial CPU which has a listed performance of 2.5TFlops over 64 cores. Surprising result, there are some pointers to why that might be.

4. When comparing Julia-MPI with Fortran-MPI, at lower processor counts both match for total time, at middle processor counts (16-128) Fortran takes more time than Julia, at higher processor counts Julia becomes slower than Fortran. However the scaling down of Julia is driven more by a less efficient implementation of the communication time with the higher processor setup. Computation time scales well for both Julia and Fortran but the communication time takes over in the Julia case.

Some nice optimization tips are provided to speed up Julia code. No plans to use Julia yet but it is good for prototyping and Fortran is good enough for now.

Just to be clear, doing well compared to an establish fortran code is an achievement. An established code is THE reference point.

Yes, definitely very impressive results. Especially considering how much of an improvement over the Python/Numpy code they could achieve. If you are writing something from scratch, very good reason to work in Julia.

Uhm, the poor performance of the Python/Numpy code indicates that there's something amiss; perhaps an apple/orange comparison. Don't get me wrong, Python is slow as molasses, but for this kind of applications, almost all time spent is (ought to be) spent in the Numpy code, which is mostly C/C++. Other systems might perform better, but I don't expect more than a factor of two (which itself would be huge in the HPC domain).

Worth having a closer look methinks.

It looks like lots of quick calls to numpy. The python ffi is really slow and is eating all the gains. A large matmul works fine, but not thousands of small ones. Hpy numpy port might fix this.

Is the communication issue something intrinsic to Julia, or something in the way the author of the code implemented it? (I guess MPI must be expecting arrays stored in exactly the same format as Fortran has them, MPI grew up in Fortran-and-C land; does Julia have to do some extra marshaling or something?)

The authors seem to using the MPI package from Julia [1] so not something they did on their own. I didn't see any discussion on why MPI.jl is scales differently than Fortran-MPI. Something for the MPI.jl developers to investigate.

[1] https://github.com/robertstrauss/MPAS_Ocean_Julia/blob/main/...

> (good pointers on speeding up the Python code beyond Numpy listed but not tried or benchmarked)

Damn, it would have been a nice benchmark if they did do a comparison against numba/cython.

Reply on news.ycombinator.com