mirror of
https://github.com/openai/CLIP.git
synced 2026-11-05 01:37:26 +00:00
[GH-ISSUE #130] CLIP preprocess hangs when using multiprocessing #117
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
openai/CLIP#117
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @theahura on GitHub (Jul 22, 2021).
Original GitHub issue: https://github.com/openai/CLIP/issues/130
When running CLIP inside a multiprocessing.Process, the system hangs as soon as it reaches a preprocess step (in practice I assume this is actually any torch operation). A minimal example:
This example is the equivalent of the starter how-to-use example in the README, but wrapping the model inference in a Process.
The output of this code is:
after which it hangs. Any suggestions?
@theahura commented on GitHub (Jul 23, 2021):
Digging into this a bit more, I managed to get this down to the following, even more minimal, example of hanging using clip:
Interestingly, if you comment out the load() call or the clip.model.build_model() call, everything just works. Note that nothing in that the load() call returns is actually being used; what is the build_model() doing to the global scope that is causing these hangs?
@jongwook commented on GitHub (Jul 23, 2021):
It'll depend on the platform and the start method, but in general you shouldn't expect CUDA-related code to work across the process boundary. Initialize the model in the process that you'll be using the model. It's best to not call any CUDA-related code (e.g. anything that accesses
torch.cuda) from the parent process.@theahura commented on GitHub (Jul 23, 2021):
So as far as I can tell, in the second code block the child process is not referencing anything in the parent process. And I'm not using cuda, all of this is running on a CPU.
Loading the same model per process seems prohibitively expensive from an io perspective; surely there's a way to load the process once and share the model?
Is the clip load process using multithreading or locking or something? I'm confused why it would hang only if an unreferenced line is present.
@theahura commented on GitHub (Jul 23, 2021):
Got it down to an even simpler version than before:
It looks like it's actually blocking on the contiguous() call, but only if the clip model is initialized. Notice that I've removed all state management, and the process isn't using the underlying model 🤔
@godimarcovr commented on GitHub (Dec 24, 2021):
These issues can be solved by changing the
Processstart method. In your latest example you can make it work by creating the process like thisand everything should run fine.
Also, when PyTorch is involved it is better to use Pytorch drop-in replacement of Python
multiprocessingmodule:import torch.multiprocessing as mp@theahura commented on GitHub (Jan 5, 2022):
If I understand right, changing the context to
spawncauses the model to reload, which sorta defeats the point of loading the model in the parent. In that scenario I could just as easily load the model after the thread has started, and it would take about the same time?