8000 [MRG+1] MacOS X testing improvements by kmike · Pull Request #2982 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]

Skip to content

[MRG+1] MacOS X testing improvements #2982

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

Merged
merged 5 commits into from
Mar 24, 2014

Conversation

kmike
Copy link
Contributor
@kmike kmike commented Mar 20, 2014

Hanging multiprocessing tests are skipped on Mac OS X 10.9 in this PR. See also: #636.

test_k_means_plus_plus_init_2_jobs doesn't fail for me on 10.9, but I've added skipping code anyways because it was intended to be skipped before, and failures could be non-deterministic.

Also, I'm not sure customization hooks in if_not_mac_os (versions and message arguments) worth keeping. But at least it is better than old _is_mac_os_version function which had incorrect docstring.

Not Mac specific: BaggingRegressor was untested with n_jobs=-1 (most likely because of a typo); this is also fixed.

@@ -338,7 +338,7 @@ def test_parallel():

for n_jobs in [-1, 3]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not test for n_jobs=-1. If you run the tests on a box with 64 cores you might disrupt the regular operation of the machine. +1 for setting the range to [1, 3] instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it apply to all cases where n_jobs=-1 is used in tests? I believe it occurs more than once in scikit-learn testing suite.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say so but AFAIK there is no official guideline. @GaelVaroquaux any opinion? No need to hunt them all in this PR though, this is not a big issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are occurances of n_jobs=-1 in the same function, in other functions in this testing module, in other testing modules from the same testing package, and in other tests. It looks like a bad idea to change just this line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correction: ther are no n_jobs=-1 in other functions from this testing module

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you wish.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we probably shouldn't have n_jobs=-1 in the test suite.

@ogrisel
Copy link
Member
ogrisel commented Mar 21, 2014

Once my comment is addressed, +1 for merge.

@ogrisel ogrisel changed the title [MRG] MacOS X testing improvements [MRG+1] MacOS X testing improvements Mar 21, 2014
@GaelVaroquaux
Copy link
Member

The 'n_jobs=-1' aspect needs to be address, and after that 👍 for merge.

That said, in the long run, we would need to address the fact that parallel computing hangs on mac. @ogrisel, any clues on what would be the right direction to fix that?

@kmike
Copy link
Contributor Author
kmike commented Mar 24, 2014

There are also n_jobs=-1 in sklearn.externals.joblib tests; I haven't touched them.

@ogrisel
Copy link
Member
ogrisel commented Mar 24, 2014

That said, in the long run, we would need to address the fact that parallel computing hangs on mac. @ogrisel, any clues on what would be the right direction to fix that?

Based on past discussions on the NumPy ML and github issues, it seems that NumPy devs will advocate that users should either use Atlas or OpenBLAS (built from master branch as of today) instead of using the OSX system BLAS.

Hopefully PyPI will have .whl binary packages for OSX for NumPy and SciPy with OpenBLAS included at some point in the future.

ogrisel added a commit that referenced this pull request Mar 24, 2014
[MRG+1] MacOS X testing improvements
@ogrisel ogrisel merged commit c49723d into scikit-learn:master Mar 24, 2014
@ogrisel
Copy link
Member
ogrisel commented Mar 24, 2014

Merged, thanks @kmike!

@GaelVaroquaux
Copy link
Member

Hopefully PyPI will have .whl binary packages for OSX for numpy and scipy with
OpenBLAS included at some point in the future.

That's what I was hoping for. In which case we can reenable these tests.

@kmike
Copy link
Contributor Author
kmike commented Mar 24, 2014

Didn't know OpenBLAS became fork-safe, great news - thanks @ogrisel!

@ogrisel
Copy link
Member
ogrisel commented Mar 24, 2014

Well it did not happen just by chance ;) OpenMathLib/OpenBLAS#343

@kmike
Copy link
Contributor Author
kmike commented Mar 24, 2014

Yep, my "thanks" was not just for the comment :) Great job!

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

Successfully merging this pull request may close these issues.

3 participants
0