-
Notifications
You must be signed in to change notification settings - Fork 152
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
double buffering #32
Comments
CUDA contexts are transferable between threads, so this is weird, unless the thread runs in a different process? (which afaik isn't the case for python threads). However, I'm a bit unsure about what double buffering is exactly meant to do? Why not just copy the data in a different stream? |
Streams might be helpful, but I'm not sure we can get around the threading with streams here, since we need to also run next on the iterator while the forward pass is running. Also we need to make sure that copying the data to the device doesn't overwrite the inputs, because they might still be needed (for the backward pass for example). So we need to manage a separate chunk of memory on the device to put the data in the background. |
Double buffering is currently broken, because it overwrites the input data while the forward/backward pass is running. This is clearly a problem, because we might still need the old values. Is anyone willing to do that within the next few days? Otherwise I think we should remove double buffering and tackle it properly after the release (in 10days!). |
We will need a couple of extra ops it seems,
I'm not sure that I will get to this in the next few days though. |
but kept a branch "feature/double_buffering" around
For double buffering to work properly, the new strategy of copying data to device in
provide_external_data
instead of the iterators requires some changes to how InputLayer works. This is a TODO, but it looks like there is another problem:The text was updated successfully, but these errors were encountered: