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

[WIP] All threads compiling parallelism scaling experiment #5

Open
NHDaly opened this issue Sep 13, 2019 · 1 comment
Open

[WIP] All threads compiling parallelism scaling experiment #5

NHDaly opened this issue Sep 13, 2019 · 1 comment

Comments

@NHDaly
Copy link
Member

NHDaly commented Sep 13, 2019

All tasks are compiling a new anonymous function lambda and then executing it (eval and invokelatest).

The goal is to measure scaling, to measure contention from compilation. The goal would be that compiling entirely independent code would have 0 contention.

In practice, it looks like currently it has 100% contention, due to a global mutex around compilation.

The code for this benchmark (added in 0f1c498) is here:
https://github.com/RelationalAI-oss/MultithreadingBenchmarks.jl/blob/0f1c498/src/bench/all_tasks_compiling.jl

@NHDaly
Copy link
Member Author

NHDaly commented Sep 13, 2019

Early Results: Roadblocks and future work

Currently, running this benchmark fails, because too many parallel tasks compiling seems to trigger a race-condition in julia, as detailed here:
JuliaLang/julia#33183

However, profiling shows that currently there is essentially 100% contention if all threads are compiling, because there is a global lock on compilation:
Screen Shot 2019-09-06 at 2 48 06 PM

Some related discussion on this from slack:

@NHDaly:
I don't think we would need to hold a global mutex during compilation, right? Is this on the to-do list for future work for multithreading?
@staticfloat:
Is LLVM itself properly multithreaded? I could envision the compilation pipeline itself being made asynchronous (e.g. parsing, Julia optimization, LLVM optimization, LLVM codegen; each stage of compilation running independently of the rest, but within each stage, running serially) but I'm not sure that LLVM itself runs in a multithreaded fashion. That being said, I'm pretty sure a huge chunk of our time is spent in type inference, so maybe there are still large speedups to be had
@NHDaly:
Thanks Elliot, yeah that makes sense. I know that this kind of "slow code" has explicitly not been a priority for the multithreading team so far, so I'm not complaining, just exploring the current status. 🙂
Ooh, yeah, i hadn't considered whether LLVM itself could be run simultaneously from multiple threads... 😢 I would not be surprised if it isn't properly multithreaded.
@vchuravy:
LLVM can be multithreaded
there has been a lot of work in that area recently

So there would need to be investigations on work done to both:

  • Allow parallel invocations of the julia compilation pipeline (parsing, lowering, type inference, julia optimization, etc)
  • Enable a multithreaded LLVM to allow parallel invocations of the LLVM part (LLVM optimization, LLVM codegen)

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

1 participant