AccelerateHS / AccelerateHS/accelerate-llvm

Async Future status w/o retaining returned value

Offen
#109 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Haskell
Sterne
171
Forks
65
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

**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`.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.