Add a `unique_region_t` class or some equivalent mechanism #291

eyalroz · 2022-01-01T22:29:25Z

As we all know (or should know), the C++ standard's smart pointers class suck. Why? Because ownership should be of regions, not pointers, and it's inane to expect allocators or the operating system to keep track of your allocated region sizes based on their starting address. Allocators should return regions, not pointers. The same goes for a smart pointer. You can't make a copy of it, you can't cast it into a container, nothing - unless you also remember the size you allocated.

Now, for the non-ownership-tracking case, we have already solved this for our library, using memory_region_t. It's not perfect, but it's quite usable. I only wish I had the luxury of accepting only memory regions rather than raw-pointers-and-sizes as separate parameters.

Anyway, we have make_unique() variants for various memory spaces, to correspond to what the standard library offers with ownership tracking. But what I would really like people to use is uniquely-owned memory regions: unique_region_t. So, let's add these. I suppose we could have a unique_ptr-like-class under cuda::memory::detail_, with a custom allocator and deleter, which also has a size method and perhaps additional relevant methods. Then for every unique_ptr + make_unique we have now, we could have a unique_region_t + make_unique_region. And then we might consider getting rid of the unique_ptr's altogether.

Alternatively, we could have the allocate() functions always produce an appropriate unique_region_t. That would make use of the library safer in avoiding resource leakage, and would obviate special creation functions.

A third alternative is to make the region_t class have another boolean value, indicating ownership, like the properly-CUDA-ish wrappers (stream_t, event_t, context_t, program_t etc.). That would avoid "definition inflation" in the library - and maybe even reduce the amount of definitions if we get rid of the unique_ptr's. But it would make region_t a more "suspicious" class.

The text was updated successfully, but these errors were encountered:

eyalroz · 2022-01-01T22:31:04Z

@codecircuit : Ping...

* Added a `unique_region` class - non-templated * `unique_region`'s "decay" into `cuda::memory::region_t`'s - so there's no need to reimplement half the world for them * Added a missing variant of `cuda::memory::copy()` * Added an example program based on vectorAdd, which uses unique_regions (I would have replaced vectorAdd with it - had it not requirted to lines of source more than before...) * Removed some commented-out unique-pointer-related code

…an. It should provide the most flexibility in our example programs (and typical user programs) for direct use without explicit casting, re-specifying types and sizes, etc.

* Added a `unique_region` class - non-templated * `unique_region`'s "decay" into `cuda::memory::region_t`'s - so there's no need to reimplement half the world for them * Added a missing variant of `cuda::memory::copy()` * Added an example program based on vectorAdd, which uses unique_regions (I would have replaced vectorAdd with it - had it not requirted to lines of source more than before...) * Removed some commented-out unique-pointer-related code

* Added a `unique_region` class - non-templated * `unique_region`'s "decay" into `cuda::memory::region_t`'s - so there's no need to reimplement half the world for them * Added a missing variant of `cuda::memory::copy()` * Added an example program based on vectorAdd, which uses unique_regions (I would have replaced vectorAdd with it - had it not requirted to lines of source more than before...) * `region_t`'s now have an `as_span` method, as well as an `operator span()` * Removed some commented-out unique-pointer-related code

eyalroz · 2024-03-01T18:14:31Z

This will happen with v0.6.9

* Added a `unique_region` class - non-templated * `unique_region`'s "decay" into `cuda::memory::region_t`'s - so there's no need to reimplement half the world for them * Added a missing variant of `cuda::memory::copy()` * Added an example program based on vectorAdd, which uses unique_regions (I would have replaced vectorAdd with it - had it not requirted to lines of source more than before...) * `region_t`'s now have an `as_span` method, as well as an `operator span()` * Removed some commented-out unique-pointer-related code

…hould provide the most flexibility in our example programs (and typical user programs) for direct use without explicit casting, re-specifying types and sizes, etc.

* Added a `unique_region` class - non-templated * `unique_region`'s "decay" into `cuda::memory::region_t`'s - so there's no need to reimplement half the world for them * Added a missing variant of `cuda::memory::copy()` * Added an example program based on vectorAdd, which uses unique_regions (I would have replaced vectorAdd with it - had it not requirted to lines of source more than before...) * `region_t`'s now have an `as_span` method, as well as an `operator span()` * Removed some commented-out unique-pointer-related code

…hould provide the most flexibility in our example programs (and typical user programs) for direct use without explicit casting, re-specifying types and sizes, etc.

* Added a `unique_region` class - non-templated * `unique_region`'s "decay" into `cuda::memory::region_t`'s - so there's no need to reimplement half the world for them * Added a missing variant of `cuda::memory::copy()` * Added an example program based on vectorAdd, which uses unique_regions (I would have replaced vectorAdd with it - had it not requirted to lines of source more than before...) * `region_t`'s now have an `as_span` method, as well as an `operator span()` * Removed some commented-out unique-pointer-related code

…hould provide the most flexibility in our example programs (and typical user programs) for direct use without explicit casting, re-specifying types and sizes, etc.

* Added a `unique_region` class - non-templated * `unique_region`'s "decay" into `cuda::memory::region_t`'s - so there's no need to reimplement half the world for them * Added a missing variant of `cuda::memory::copy()` * Added an example program based on vectorAdd, which uses unique_regions (I would have replaced vectorAdd with it - had it not requirted to lines of source more than before...) * `region_t`'s now have an `as_span` method, as well as an `operator span()` * Removed some commented-out unique-pointer-related code

eyalroz added question task labels Jan 1, 2022

eyalroz changed the title ~~Add a unique_region_t class~~ Add a unique_region_t class or some equivalent mechanism Jan 1, 2022

eyalroz mentioned this issue Apr 27, 2022

Switch memory functions to only work with regions (and spans) #322

Open

eyalroz added the resolved-on-development label Mar 1, 2024

eyalroz closed this as completed in f4e440e Apr 29, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a `unique_region_t` class or some equivalent mechanism #291

Add a `unique_region_t` class or some equivalent mechanism #291

eyalroz commented Jan 1, 2022 •

edited

Loading

eyalroz commented Jan 1, 2022

eyalroz commented Mar 1, 2024

Add a unique_region_t class or some equivalent mechanism #291

Add a unique_region_t class or some equivalent mechanism #291

Comments

eyalroz commented Jan 1, 2022 • edited Loading

eyalroz commented Jan 1, 2022

eyalroz commented Mar 1, 2024

Add a `unique_region_t` class or some equivalent mechanism #291

Add a `unique_region_t` class or some equivalent mechanism #291

eyalroz commented Jan 1, 2022 •

edited

Loading