JuliaOptics performance discussion


I just happened to remember that this abandoned package came out in this forum during a discussion of performance benchmarks, and users’ expectations of performance in Julia vs other languages.

As I happened to be interested in both Physical Optics and running performance benchmarks, I went ahead and looked at the Python library and run a simple benchmark.

What I found is that the package in question typically spends about 99.9% of the time running 2D-FFTs, at least in the simple examples provided in the tutorials (where the data has a 2048x2048 size).

So there is no real Julia-vs-Numpy benchmark going on there, and there are no problems with vectorization being hard to use in Julia, etc. It’s just that porting such a lightweight API to an expensive FFT operation probably wasn’t worth it in the first place.

For this kind of algorithms (that do very meaningful but computationally inexpensive operations, and then call an external library) I believe the only possible edge of using Julia would be if working with GPUs, or in distributed-memory systems for large cases of this type of problem, is easier to do in Julia than in other languages. Or if plotting is faster, and so on.

I hoped this helps if anybody was wondering what the problem was, if it is true whether Julia isn’t always the fastest or what.

1 Like

That’s good to know. Nonetheless, from the readme, one of the points is

the allocator is much slower than numpy or even matlab

I haven’t seen this before but if true it seems worth looking into.

What’s the allocator? Doing things like meshgrid?

allocating memory (for things like arrays). julia is notably slower than numpy here, but it doesn’t usually matter since high performance code usually avoids allocation in the first place (and this is expected to improve over the next year or 2)

I usually just “reserve” memory by “initializing an undef array” which has zero cost. The filling the array is very fast. Maybe this “allocator” cost happens when someone initializes an array with zeros?

no. The allocation cost is the cost of initializing undef arrays.

1 Like

Oh, I’ve never measured that one, as it is usually negligible when compared to actually filling the array. It’s definitively a weak point if it hasn’t been fixed, but sounds like small potatoes to me.

Here is a benchmark demonstration