add umfMemspace[New|TargetRemove|TargetAdd] #694
Conversation
There was a problem hiding this comment.
Do we already have use cases for such API? Does OpenMP need it? I am just curious to understand how it is used in real life.
There was a problem hiding this comment.
There is restrict_storage//subnumspace one. In their example they want to allocate from every second target(a.k.a. every second memory). We can achieve this also with filters (which I'm going to implement next), but such basic API as create empty memspace and add or remove targets from it, is quite useful too in my opinion. i.e when you want to create pool which allocates from single specific numa node.
Currently we have "umfMemspaceCreateFromNumaArray" to cover this openMP case, but i will consider to remove it(or to not export it to be precise), when this and filtering patch is merged.
There was a problem hiding this comment.
but i will consider to remove it
that is what I am worried about. The first release of UMF is coming soon. And we should care about backward compatibility.
So we should be careful with introducing new API - it is not regarding this particular PR, but rather a general rule we should follow. Also, we need to consider an option to mark some API as experimental - it will give our users a notion that experimental API is not stable and might be removed/changed in the future.
There was a problem hiding this comment.
@vinser52 this would not be merged on v0.9.x branch (2025.0 oneAPI release)
There was a problem hiding this comment.
but i will consider to remove it
that is what I am worried about. The first release of UMF is coming soon. And we should care about backward compatibility.
So we should be careful with introducing new API - it is not regarding this particular PR, but rather a general rule we should follow. Also, we need to consider an option to mark some API as experimental - it will give our users a notion that experimental API is not stable and might be removed/changed in the future.
As far i know we are releasing 0.9 because we do not want to commit to stable API (semver specyfication) There is few minor issues with our API they i did not have time to fix. Like wrong variable size, const, signed vs unsigned
lplewa
force-pushed
the
add-remove-new
branch
from
33cc62b to
85eadc9
Compare
lplewa
force-pushed
the
add-remove-new
branch
2 times, most recently
from
b219cd2 to
5cf7c80
Compare
lplewa
force-pushed
the
add-remove-new
branch
from
5cf7c80 to
b9f5778
Compare
|
@lplewa - is this ready for merge? |
No description provided.