This is an archive of the discontinued LLVM Phabricator instance.

Changed buffer API to receive policy instance.
Needs ReviewPublic

Authored by MikeDvorskiy on Mar 22 2019, 10:02 AM.

Details

Reviewers
rodgert
ldionne
Summary

Changed buffer API to receive policy instance. It may be necessary for the other back-ends, where dynamic memory is not available and custom memory allocator may be provided by a custom policy.

Diff Detail

Repository
rPSTL pstl

Event Timeline

MikeDvorskiy created this revision.Mar 22 2019, 10:02 AM
ldionne requested changes to this revision.Mar 22 2019, 10:46 AM

I don't see a big problem with this change per-se, but can you please expand on the bit where you say:

It may be necessary for the other back-ends, where dynamic memory is not available and custom memory allocator may be provided by a custom policy.

How would you somehow handle allocation through a custom policy?

This revision now requires changes to proceed.Mar 22 2019, 10:46 AM

I don't see a big problem with this change per-se, but can you please expand on the bit where you say:

It may be necessary for the other back-ends, where dynamic memory is not available and custom memory allocator may be provided by a custom policy.

How would you somehow handle allocation through a custom policy?

Assuming, at some point we figure out how to get p0443 executors and p1019 style execution policy types, which communicate executors to the algorithm, which allocator to use becomes a property query against the executor. The default executor and it's associated properties are a library implementation detail, but the way that the algorithms respond to the presence of those properties should be the same.

Similarly, the execution policy will ultimately need to be communicated to the basis functions of the backend as well, and I am planning on resurrecting my prototype of that change in the next week.

I'd like to be careful about making these sorts of changes until we have had a chance to have the next follow up coordination meeting that Alexey has proposed.

MikeDvorskiy added a comment.EditedMar 25 2019, 2:47 AM

How would you somehow handle allocation through a custom policy?

For example a custom policy has get_memory_pool method which provide an interface for memory allocation/access.
Of course, this "contract"(provided by a custom policy) must be known a custom corresponding parallel back-end as well. But Parallel STL core implementation have not to know about this "contract".

I agree with Thomas, in that case it is connected with the executors, because the custom policy specifies certain "backend"... and works like an "executor". And in the future, just an executor should specify back-end.
On the the other hand, "the executors" are not finalized yet.. and it may take many time (months mb). The change so minor.. and the change helps us to sync-up, and when an "executors solution" comes, we will change the code places quickly. That change may not be taken for libcstd integration.

My main problem with this change is that we don't seem to have a backend right now that requires this change. I'd defer doing this until we have a real reason to do so.

At least, it "extends" signature of functions of a back-end that helps (now) to support several back-ends in the same time (by overloading).

ldionne added a reviewer: Restricted Project.Nov 2 2020, 3:37 PM
ldionne removed reviewers: ldionne, Restricted Project.Aug 31 2023, 7:35 AM

[Github PR transition cleanup]

Libc++ doesn't use the code under /pstl/ anymore, so I am neutral on this.

This revision now requires review to proceed.Aug 31 2023, 7:35 AM
Herald added a project: Restricted Project. · View Herald Transcript
ldionne resigned from this revision.Aug 31 2023, 7:36 AM