Julia either very fast or very slow, with little in between?

Usage First steps
, ,
#1

I have the impression that Julia commands are often execute very fast (as advertised), but when they are not, it takes ages (up to the point where I’d have to kill it–and system monitor shows that a processor is at 100% indeed) with little in between?

I was solving a matrix equation just now in the QuantumOptics-toolbox, and changing one parameter a bit changed the situation from the one extreme to the other. But I seem to remember similar findings before (outside this toolbox).

In matlab on the other hand for example, it seems to me that execution time is in general more consistent and predictable?

#2

And it’s not just due to JIT? Don’t think there’s any Julia-specific reason for this to happen.

#3

Not sure there’s much to say here without a concrete example, my experience is that Julia code if properly benchmarked scales as expected with problem size.

If you’ve found an example where Julia performs similarly to Matlab for a certain parametrization of your code, but performance drops off unacceptably with another parametrization while Matlab performance remains the same, that sounds like a bug. If you post such an example I’m sure people would be happy to help you figure out what’s going on.

5 Likes
#4

Not for me.
In most cases I have (bioinformatics, statistics) first attempts with very good (=sufficient) performance (compared to R mostly, seldom python). After optimizing I can enforce some more performance, sometimes it sums up to be significant (=worth), often it just doesn’t matter a lot.
I nearly never have the slow case.
If it takes ages, it was always a programming error (=would have took ages in every language).

#5

I think that, for new users, the behavior of tuples and StaticArrays does not scale as they would expect, XD.

#6

You can completely change the numerical qualities of the simulation, making it take more or less steps, by doing a parameter change. Did you change the solver? Likely you may have made it stiff if it’s extreme, in which case you might need to solve it differently.

3 Likes
#7

hmmm… not sure this has anything to do with the specific package. Which versions of Julia and editor are you using?

I recall that untill relatively recently (Julia 1.3 or 1.4), on Juno, I did had problems of Julia getting “randomly” stuck on otherwise banal commands.

If you are not already in, try Julia1.6 (rc1 for now). It is way more reactive!

#8

Thank you for your answers. I was concerned that the Julia installation would be interacting badly with the hardware somehow. At least when in debugging mode for example, everything seems to freeze sometimes. But no, I have never performed systematic benchmarks while comparing to matlab.

#9

Thank you for your comment. In this particular case, I was using the function API · QuantumOptics.jl indeed, which seems like a wrapper around DifferentialEquations. With the default tolerance of 1e-3, a simulation took maybe a minute and decreasing it to 1e-4 at least half an hour so I killed it because I was suspicious of the code still going anywhere.
Thinking about it a bit further, it could indeed be that the equation just had to be evolved further now, and the lower tolerance case would have stopped at a metastability or so…

#10

Now 1.5.3 . But possibly, I don’t have enough statistics to say if the problems are really there; and I was recalling other experiences I had with older versions in the past.

Is Juno still recommended? Or is it deprecated in favor of VSCode?

#11

This is a known issue because debuggers by default don’t make any assumptions about which modules you want to step through and which can be safely run optimized (whereas in Python/Matlab the optimized bits are written in C/C++ and can’t be stepped into period). There are ways to configure this (e.g. GitHub - JuliaDebug/Debugger.jl: Julia debugger, GitHub - JuliaDebug/Infiltrator.jl) and more ergonomic tooling is on the horizon.

Is Juno still recommended? Or is it deprecated in favor of VSCode?

AFAIK Juno isn’t getting active feature development, so I would recommend VSCode. Many of the old Juno maintainers work on that extension now.