[tests][dask] Add voting_parallel algorithm in tests (fixes #3834)

[jmoralez]

This includes the voting_parallel tree_learner for test_regressor, test_classifier and test_ranker in the tests for the dask module and removes the warning about experimental support that was previously triggered (because it wasn't tested).

[jameslamb]

Thanks for doing this! I'm glad it was as easy as just changing the tests. I have a few suggested changes for the tests.

[jmoralez]

Hi, James. Do you have any suggestions on what to work on next?

[jmoralez]

I noticed a failing test due to graphviz I believe. This time it failed in Linux_latest_gpu_source. Here are the errors:

Warning: Could not load "/home/AzDevOps_azpcontainer/miniconda/envs/test-env/lib/graphviz/libgvplugin_pango.so.6" - It was found, so perhaps one of its dependents was not.  Try ldd.
Warning: Could not load "/home/AzDevOps_azpcontainer/miniconda/envs/test-env/lib/graphviz/libgvplugin_gd.so.6" - It was found, so perhaps one of its dependents was not.  Try ldd.

I believe this test was also failing on some builds before I merged the latest master.

The other one is related to #4095 (comment).

[jameslamb]

Hi, James. Do you have any suggestions on what to work on next?

are you mostly interested in Dask? If so, this issue would be a good one to pick up next: #3896. If not, let me know and I can recommend something else.

[jameslamb]

Thanks for making that most recent round of changes. I don't have any other suggestions. Could you please update to the latest master?

[StrikerRUS]

Great to know that voting parallel is working without any modifications!
Please consider checking a few my minor comments below:

[jmoralez]

@jameslamb do you know what's the advantage of using the client fixture? (Apart from avoiding the client construction). I just tried running test_regressor by initializing the client at the top and the time goes from 137s down to 98s.
Here's the profile with the fixture:

And without:

So basically with the fixture 70% of the time is spent in setting up and tearing down the cluster. Without it only 60% of the time is spent there and seems to be faster.

Followup
I've been investigating more and found dask/distributed#3540, which led me to the implementation by seanlaw, here: https://github.com/TDAmeritrade/stumpy/blob/68092c931610db725f2c74b6a5155868666eb14f/tests/test_mstumped.py#L10-L14 and holy cow that's fast. Using that test_regressor runs in 18 seconds. Would you support a PR adding this? It'd basically be replacing the client fixture with the dask_cluster fixture and instantiating a client from it in every test. When the client gets closed it's memory gets released so I believe this is the same as what we have right now, every test gets a fresh client but it's significantly faster because we're not creating a cluster everytime.

[StrikerRUS]

@jmoralez

do you know what's the advantage of using the client fixture?

Awesome research! Could you please copy-paste your comment here: #3829 (comment). I believe that place is the best one to continue the discussion.

[StrikerRUS]

LGTM!

[jameslamb]

thanks for this!

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.