-
Notifications
You must be signed in to change notification settings - Fork 13
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
Excessive memory usage during compilation with pip #115
Comments
Thanks for the find, this is a very good point. I'll address this in a PR tomorrow. |
Thanks @nickjbrowning ! |
One thing I don't understand here is that we don't have that many files to compile, so |
It's a bit suspicious. My observation is: (a) compilation dies with |
Oh, right. I can see the compiler requiring a couple of GiB per file (there are a lot of torch header to parse and template to instantiate), so parallel compilation would fail with only 4GiB of available RAM. But then the changed by @nickjbrowning would not fix it here, since the compilation would also fail with only 8 jobs. |
I've added these two environment variables to the build process:
So you can now control the number of build jobs via:
|
--------- Co-authored-by: frostedoyster <[email protected]> Co-authored-by: Filippo Bigi <[email protected]> Co-authored-by: Guillaume Fraux <[email protected]>
Currently, attempting to build the
sphericart-torch
wheel withpip
requires a large amount of RAM if many CPU cores are present. I think this is due to this line, which invokescmake
without specifying the number of jobs, which presumably will default to the total number of cores. On a HPC system those can be 40 or 80, and so compilation tends to getkill
ed by the host OS.While this is not catastrophic, it is inconvenient, and a waste of resources in many cases (the compilation is not much faster in parallel mode). I would suggest defaulting to some reasonable default instead, or disabling parallel builds entirely. Alternatively, the installation docs should at least mention this fact (see #116).
The text was updated successfully, but these errors were encountered: