Julia vs. NumPy performance: Strategy for For-loop? | Hacker News Reader

Julia vs. NumPy performance: Strategy for For-loop?

Lately, read about Julia Langs' preference in some quantum research. In general, for single shot computations like matrix and vector operations including linear algebra, the performance between Julia and NumPy is comparable due to NumPy's underlying C/Fortran code base. But for Monte Carlo methods for-loops are hard to avoid. Is there any strategy for For-loops in NumPy avoiding python overhead? Or migrating to Julia is a better choice? I am trying to avoid Rust as I see it as more system level language.

View on HN

Julia isn't for everyone, but it certainly is for me. I find it to be a very flexible, interesting, and powerful language with a vibrant, developer community.

If you are just programming using pre-existing libraries, and using those libraries the way the author intended them to be used, then for most cases Python is probably fine, but if you are doing something relatively novel that some big framework doesn't cover for you, that's where I think Julia really stands out and makes a big difference relative to Python.

I really recommend giving it a try.

Thanks. Yes, we have novel use-cases which are not available out of box in NumPy.

I mostly work with arrays in numpy but sometimes I get stuck with a problem that needs a for loop - only two things I can think of are parallelize the for loop or use numba/jax JIT functions and GPU acceleration.

Both don’t just work out of the box like Julia or MATLAB’s “parfor” loop, but seem to work well enough for non trivial for loop cases.

Thanks. numba is a good trade-off before moving to Julia completely.

Sure. To be fair, having gone down the path of porting and testing a problem to numba, it might be easier to just jump to Julia if you want to focus on the problem more than the implementation.

Last year I had to multiply a nxn matrix by another nxn matrix that has only one row. I lost like a week to write the correct @guvectorize spell in numpy to make that multiplication faster than the usual multiplication.

Interesting. Maybe this was due to matrix-matrix, matrix-vector and vector-vector separation in BLAS/LAPACK routines.

We were using einsum from numpy. We have some 2 and 4 (and perhaps 6) dimensional arrays. I'm not sure what happens under the hood, but trying to replicate it explicitly to make some tweaks requires a lot of magic. It was like two year ago, I forgot the details.

Protip: "optimize=True" is equivalent to "optimize='greedy'", but you may prefer "optimize='optimal'" for big cases or use a list precalculated by einsum_path.

Have you tried Jax or Taichi? https://www.taichi-lang.org/

For Monte Carlo simulations, Pyro and tensorflow_probability have also nice abstractions.

Some chat: Pyro/tf.prob are all more of an operations/stat research oriented tools, I gather but if there are some MC abstractions it might be good choice.

Yes, tested and used Jax for some prototyping but it felt like still has "two language problem". But Taichi looks quite interesting, will check out.

Of course, forgot to mention, it has to be lightweight, torch and tf are now huge platforms. Not sure, probably Julia-lang is much small.

Reply on news.ycombinator.com