Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance problems of Julia #29078

Closed
allphfa opened this issue Sep 7, 2018 · 9 comments
Closed

Performance problems of Julia #29078

allphfa opened this issue Sep 7, 2018 · 9 comments

Comments

@allphfa
Copy link

allphfa commented Sep 7, 2018

project: test
python: 6 sec
julia: 11 sec

Dynamic array performance is not as good as python, only using single core CPU. Does Julia also have a GIL lock?

Is there a performance analysis tool similar to Python cProfile?
Julia's performance analysis tool is either inaccessible or inhumanized.

@sairus7
Copy link
Contributor

sairus7 commented Sep 7, 2018

If you are using Juno IDE, then
@profile <your function here>
Juno.profiler()

@andreasnoack
Copy link
Member

Thanks for providing the benchmarks. However, this discussion is better suited for discourse.julialang.org

@allphfa
Copy link
Author

allphfa commented Sep 7, 2018

Wrong optimization
for (k,v) in xx

Correct optimization

for x in xx
   v=x[1]
   v=x[2]

@JeffBezanson
Copy link
Sponsor Member

No, julia does not have a GIL. There is experimental multi-threading support (https://docs.julialang.org/en/v1/base/multi-threading/); more is currently under development.

See https://docs.julialang.org/en/v1/manual/profile/ for information on the profiler.

It seems quite possible to me there are real performance issues here, and this should perhaps be reopened.

@timholy
Copy link
Sponsor Member

timholy commented Sep 7, 2018

The use of a non-const global dict seems a likely problem. But at least in earlier Julias I have also noticed that destructuring pairs isn't optimized. Likely related to #27434 and especially #27434 (comment)

@KristofferC
Copy link
Sponsor Member

For this to be reopened, I think the code should at least be written with some consideration to the performance guidelines we have.
Adding a few const to global variables and making the main data structure, not a Vector{Any} cuts the time down by a factor of 3.

@timholy
Copy link
Sponsor Member

timholy commented Sep 7, 2018

@AlphaFase, please see https://docs.julialang.org/en/v1/manual/performance-tips/ (hint: you're violating at least performance tip number 1 😄)

@JeffBezanson
Copy link
Sponsor Member

Destructuring does not use splatting. I'm also pretty sure for (a, b) in c is optimized well now.

@andreasnoack
Copy link
Member

Might also be worth mentioning that the first Python version shared had some parts commented out that made it much faster but not comparable to the Julia version. It has since been fixed but I first benchmarked the wrong version.

I'm not sure about the rules of the game here but using typed vector of tuples instead of an Any vector of Any vectors also gave about 2x for me.

Finally, it would really be nice to have #28648 fixed for situations like these since right now it's basically impossible to use Juno's flame graphs which, I think, is normally our best profiling tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants