AccelerateHS / AccelerateHS/accelerate-llvm

Async Future status w/o retaining returned value

オープン
#109 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Haskell
スター
171
フォーク
65
PR マージ指標
30日以内にマージされた PR はありません

説明

**Is your feature request related to a problem? Please describe.**
Currently, a `Future` cannot simply have its status checked, you must block on a `Future` either synchronously or via an event barrier within the CUDA stream. Additionally, if one tried to introduce this capability, the first and most obvious way to implement this would involve simply checking the contents of the `IORef` within the `Future` however holding onto this `IORef` would retain the memory backing its `Full` contents which could potentially be a substantial amount of memory. It should be possible to effectively extract some kind of `Future` status handle which does not retain this information.

The reason I am requesting this feature is actually this issue I posted in `accelerate-fft`: https://github.com/AccelerateHS/accelerate-fft/issues/12

Essentially, the simplest solution to that issue would be to maintain a list of plan handles per shape and type of FFT operation and to then rapidly check that either there is no corresponding owner of this FFT plan handle, in which case it can be used without reservation, or it was previous used and contains some way to definitively check that such a necessity has expired and so can be used. If all existing handles are reserved, a new FFT plan handle can then be introduced. It is essential that such expiration tests do not necessitate retaining whole Accelerate `Array`'s since that would introduce prohibitive CUDA memory space leaks.

**Describe the solution you'd like**
Introduce the following functions to the `Async` typeclass:
```
statusHandle :: FutureR arch a -> Par arch (FutureR arch ())
poll :: FutureR arch a -> Par arch (Maybe a)
```

The `Future` type, such as that defined for `PTX` contexts should include a list of status handles which are other `Future`'s over `()`. Wherever a `Future` might be set to `Full`, the list of status handles should be traversed and each should be set to `Full ()`, thus delivering the completion state. `poll` can simply return `Just` when the `Future` is `Full` otherwise return `Nothing`.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。