{tools}[foss/2024a] modin v0.32.0#21667
Conversation
| 'checksums': ['9f68557add5e92617d006eb98bfd93d298e7d4d9932a0cd48a5e38ee4f30a134'], | ||
| }), | ||
| ('unidist', '0.7.1', { | ||
| 'source_tmpl': '%(namelower)s-%(version)s-cp312-cp312-manylinux_2_17_%(arch)s.manylinux2014_%(arch)s.whl', |
There was a problem hiding this comment.
Any particular reason to prefer the wheel for this one? We usually go for the source.
I was also tempted to suggest breaking this out into it's own package, but i see so far modin is the only usecase, so maybe not..? Things might change though, so i wouldn't be against putting this into it's own thing, and just have modin depend on it instead of mpi+dask+ray
https://unidist.readthedocs.io/en/latest/using_unidist/index.html#libraries-powered-by-unidist
I'm also confused as to why we need the extras here specific to mpi? it supposed dask, ray, mpi, and we have all of those as dependencies, so presumably, this should be used here?
unidist automatically detects which execution backends are installed and uses that for scheduling computation.
wouldn't mpi4py be enough then?
There was a problem hiding this comment.
There was some error related to copying/finding files during Cython compilation when I tried to build from source. I have absolutely no idea how one would go about solving it, it was trying to do some "include source_file.cpp" thing and not finding source_file.cpp even though that's clearly in that directory...
About the pip install extras, I'm just following the requirements in the modin installation files which specify "unidist[mpi]". I guess that only amounts to a dependency check?
There was a problem hiding this comment.
Also, Modin basically supports all three frameworks, but unidist seems to be specifically for MPI, from their setup.py:
https://github.com/modin-project/modin/blob/main/setup.py
Their readme also says that you must set both MODIN_BACKEND and UNIDIST_BACKEND to MPI if you use unidist. So it's a bit of a special thing.
| sanity_check_commands = ['python -c "import modin"'] | ||
|
|
There was a problem hiding this comment.
this is already done by default for all extensions
|
For reference: issue with builds stem from modin-project/unidist#428 |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
OK, the failure now is from ray-project/ray#7724 when running the test suite. Long story short, ray relies on AF_UNIX sockets which have hard limits on path length, so it cannot handle complicated tempdir paths. It is a baffling design decision to build the software in this way, because the only way to fix this temporarily would be to overwrite |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
OK, so my conclusion is that Unidist does not work at the moment, I tried it in several contexts and it just gets stuck. Dask works fine, Ray works if you don't have a complicated tempdir path specified. |
|
Test report by @lcniel |
| use_pip = True | ||
|
|
||
| exts_list = [ | ||
| # modin has another backend, "unidist", for MPI, but it seems broken currently. |
There was a problem hiding this comment.
can you add a bit more info why it's broken?
what's the error message?
maybe open a github issue that you can link to?
There was a problem hiding this comment.
There is no error message, trying to build it and running tests with unidist as the backend, or even just importing it and trying to use anything, e.g. modin.pandas.DataFrame(), results in all your nodes running some kind of unidist init code and firing up all the nodes to 50%. I could not find any documentation of this behaviour.
I have tried the usual MPI remedies to attempt to debug it but I can't get it to work at all. Not sure if anyone else wants to dig into it, but I have no idea how one would go about debugging it.
There was a problem hiding this comment.
Updated to add a little more info, but there is really not much that I can say about it.
There was a problem hiding this comment.
I think I found a way to resolve it. Maybe!
…asyconfigs into 20241015192634_new_pr_modin0320
We just released unidist 0.7.2, which adds missing files in the PyPI tarball. Thanks for raising the issue. |
|
Test report by @lcniel |
|
Test report by @lcniel |
|
OK, I figured out a way to make Looks a little bit hackish to me (some implementation choices like using multiprocessing.cpu_count() to get the number of tasks are a bit questionable as well) but I guess they wrote it that way for a reason. I also had to change UCX_TLS: |
|
@boegelbot please test @ generoso |
|
@boegel: Request for testing this PR well received on login1 PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 2437725407 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
|
@boegelbot please test @ jsc-zen3 |
|
@boegel: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 2437760280 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
|
Going in, thanks @lcniel! |
(created using
eb --new-pr)Requires: