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

Stop using @threads? #169

Closed
andreasnoack opened this issue Dec 13, 2016 · 12 comments
Closed

Stop using @threads? #169

andreasnoack opened this issue Dec 13, 2016 · 12 comments

Comments

@andreasnoack
Copy link
Member

In isolation @threads works okay but Julia doesn't handle nested threaded loops. I work on a project where I'd like to use threads on larger code chunks but I believe it is clashing with GLM's @threads right now. I'll suggest that we postpone using @threads here until Julia has a (more mature) threading model.

@nalimilan
Copy link
Member

It's too bad we need to lose an optimization for most users to support an advanced case, but if there's no other solution... I guess passing an argument to disable threading isn't possible?

@andreasnoack
Copy link
Member Author

The problem is that it can be really tricky to detect the issues with nested threaded loops. The feature is really experimental. We could provide a flag for turning it on and off but for the previous reason, I think it should be off by default. From my own experience, such a flag can also be extremely tricky, see JuliaLang/julia#14948.

@nalimilan
Copy link
Member

OK, just disable it if you want then.

@dmbates
Copy link
Contributor

dmbates commented Dec 14, 2016

Could you create a branch before disabling the threads in the master branch? I have been working with a company in Chicago that is fitting a lot of GLMMs to large data sets and they do see a noticeable difference with multiple threads. I would like to leave them the option of installing such a version of GLM (the MixedModels package uses functions types and methods from GLM).

@ararslan
Copy link
Member

@dmbates I realize it hasn't been updated in a while, but would your ParallelGLM package suit their needs?

@dmbates
Copy link
Contributor

dmbates commented Dec 14, 2016

In the end I found that the multiple threads was a better option than trying to work with DistributedArrays or SharedArrays. The parallelism is very simple, a lot of the execution time is spent in one loop to update several vectors. Doing this with threads avoids all the setup of exotic array types.

@andreasnoack
Copy link
Member Author

I'll try to make prepare a branch where threading can be enabled/disabled with some kind of flag.

@dmbates
Copy link
Contributor

dmbates commented Dec 14, 2016

@andreasnoack I didn't mean that you should need to make a lot of effort to control threads enabling with a flag. I would just prefer if you could create a branch with threading, preferably making the other changes in master first then creating a branch then turning threads off. However, if you think it would work best with a flag that would be great.

@andreasnoack
Copy link
Member Author

@yuyichao has fixed this so I'll close and celebrate.

@Balinus
Copy link

Balinus commented May 26, 2017

How was it fixed? I face the same potential problem with my package (using @threads for climate indices calculations) and having a flag (or information about the fix) would be awesome.

Thanks!
@andreasnoack

@yuyichao
Copy link
Contributor

JuliaLang/julia#21452

@Balinus
Copy link

Balinus commented May 26, 2017

Nice work! Looking at the test, it now looks like nested threaded loop are working. That is a major hurdle going away.

I need to test that on my 96 core server! :)

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