Efficient realloc: only copy data in touched spaces #24
Conversation
There was a problem hiding this comment.
I'm not sure that this is correct.
In this flavor of CHAI - what state do arrays end up in if they are read-only (valid on both GPU and Host)? In my flavor, neither space was marked as touched.
Also, what happens right after allocation?
Trickiest use case I can remember dealing with:
1: realloc immediately after alloc
2: realloc something after it's used as a const in another part of a program.
|
Thanks @robinson96, I'll write up some more test cases and check that this all works. |
| @@ -137,7 +137,9 @@ void* ArrayManager::reallocate(void* pointer, size_t elems) | |||
| pointer_record->m_user_callback(ACTION_ALLOC, ExecutionSpace(space), sizeof(T) * elems); | |||
| void* new_ptr = m_allocators[space]->allocate(sizeof(T)*elems); | |||
|
|
|||
| rm.copy(old_ptr, new_ptr); | |||
| if (pointer_record->m_touched[space]) { | |||
| rm.copy(old_ptr, new_ptr); | |||
There was a problem hiding this comment.
I assume the rm knows the lengths and this does a reasonable thing here?
|
One other concern - by choosing not to do a realloc on the CPU side of things, you're forcing a copy to always happen, while most realloc implementations will avoid a copy if the realloc ends up with the same address (which happens pretty often, in my experience). Does Umpire have a realloc API? Should it? |
|
It does, but that means we can't avoid the unnecessary copies on the CPU side - you call realloc and the semantics of realloc are what you will get. If you only want to avoid a device-side copy then that would be fine. |
No description provided.