threading branch

[vtjnash]

this closes #10772 and superceeds the other threading branches

the goal of this is to have the threading support off by default (controlled by a flag in julia.h), but to have the code building and passing tests either way; and to get this merged into master sooner rather than later.

[kpamnany]

@hayd, @tkelman: Author's response is "Hi Kiran. MIT licence agreed. I'm sure this email is enough, but I'll update the page also when I get round to it. Cheers, Iain."

[ViralBShah]

Bump. Merge this soon?

[tkelman]

There's a conflict that needs resolving. I dislike merge commits since they can bury bad conflict resolutions along with thousands of lines of unreviewable diff of everything else that has happened on master, but this is too messy to rebase at this point. A comment about where conflicts were, or a manual commit that only touches the files where conflicts happened would help in tracking conflict resolutions.

[vtjnash]

I'm not sure why github doesn't present the merge commits better. git show gives me only the lines that were affected by the merge conflict. in the future, I may try to use git rebase --preserve-merges to reduce the number of merge commits.

[kpamnany]

Yay!

[ihnorton]

😹

[johnmyleswhite]

🎉

[tkelman]

@vtjnash that is a great tip, thanks for that - https://gist.github.com/7e083009a110666331ba

[vtjnash]

and even that is a massive over-approximation of the merge conflict (which was just resolving the order of the the assert vs JL_LOCK changes at the top of jl_trampoline_compile_linfo)

[KristofferC]

💯

[JeffBezanson]

🎆

[ViralBShah]

👍

[tkelman]

Here's a source build with all the deps in place for this: https://hub.docker.com/r/tkelman/julia64-part2/

sudo docker run -t -i tkelman/julia64-part2:threads /bin/bash
git pull
make -j4 # just julia src and sysimg, all deps are already built

[KristofferC]

@tkelman Hmm, I seem to get stuck on second round of inference.jl..

[tkelman]

odd, are you in a VM? maybe adding MARCH=x86-64 might help?

[KristofferC]

Yes, I used the "Kitematic"-thing for Docker on windows which seems to use VirtualBox. Seems to work now with MARCH

[tkelman]

Probably a virtualbox bug with avx.

[StefanKarpinski]

Getting this merge is so awesome.

[KristofferC]

Since I am eager to play with this, is there any documentation yet for the new thread-macros or is it best to just look at the examples and go from there?

[ViralBShah]

Best to look at the threads perf tests. The interface is very rudimentary. I don't think we should document until APIs stabilise.

[kpamnany]

There are a few small example programs in test/perf/threads/. The simplest use cases are in test/threads.jl which is kind of a tutorial.

The interface is, in fact, rudimentary and the syntax preliminary. However, I think the basic interface (jl_threading_run(threadfun, args)) is extremely powerful. Not only does it allow high performance parallel for loops (which might be the single most widely used (shared-memory) parallelism construct in technical computing applications designed for scale), but together with atomics, which are also here, it can easily be used to build other shared memory parallelism models, from transactional memory to work-stealing. So, while there are certainly many many things remaining to do, I'm hoping many people will use this and offer feedback to drive priorities, or even better, write some code and raise some PRs.

@ViralBShah, @StefanKarpinski: what's a good venue to discuss the threading interface and improvements to it? Here? In #1790?

[ViralBShah]

I think we should close #1790 and open specific issues to discuss various threading related issues and improvements.

[KristofferC]

Using this branch I could speed up my kd tree creation with a factor of about 2.25x (using 4 threads) encountering very little problem. Really nice job here! I look forward to when this is enabled by default.

[kpamnany]

@KristofferC: that kd-tree code would be a nice performance benchmark for test/perf/threads/ if you can share it. PRs for performance tests would be very welcome.