Better unordered folds?
Nessuno ha ancora preso questa issue.
- Lingua principale
- Haskell
- Stelle
- 17
- Fork
- 12
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
I'm not a huge fan of the way we implement unordered folds. The compiler has no clue what they're up to, so optimization is garbage. I experimented with using an operation
viewU :: BinomHeap a -> Maybe (a, BinomHeap a)
which extracts the root of the first binomial tree, to implement foldlU'.
Unfortunately, the performance was worse than what we do now. But I wonder if things might change if we work in bigger chunks. For starters, something like
viewU2 :: BinomForest (Succ Zero) a -> Maybe (a, a, BinomForest (Succ Zero) a)
Working with two elements at once should reduce the churn in the low bits, and might give this technique some hope.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Direzione di ricerca
Inizia con l’implementazione esistente di unordered-fold e con i punti di ingresso denominati foldlU', viewU e viewU2. Confronta l’approccio attuale con l’elaborazione di due elementi alla volta; il lavoro è completato quando si determina se la tecnica proposta migliora le prestazioni e, in tal caso, la si applica all’unordered fold.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- haskell
- Ambito
- performance
- Tipo di issue
- Refactoring
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Ferma
- Chiarezza
- Da chiarire
- Idoneità per principianti
- 25/100