parrows / parrows Goto Github PK

View Code? Open in Web Editor NEW

18.0 6.0 2.0 49.31 MB

Using Arrows to model parallel processes/computations.

License: Other

Haskell 39.87% TeX 59.18% Frege 0.31% Shell 0.61% Makefile 0.03%

haskell arrows parallel computing arrow

parrows's Introduction

Parrows

This project aims to provide an interface for parallel computation using arrows.

For more information take a look at the paper:

https://github.com/s4ke/Parrows/blob/master/paper/content/main.pdf

The paper is currently submitted to JFP for review. The submission can be seen at:

https://arxiv.org/abs/1801.02216

Install

Currently, all Haskell modules in this repository are on hackage in version 0.1.1.0. They are named Parallel-Arrows-<NameOfSubmodule>.

Currently supported modes:

Multicore Haskell
Par Monad
Eden

Modes yet to be implemented:

HdpH (if possible)
...

parrows's People

Contributors

Stargazers

Watchers

Forkers

olegl hardentoo

parrows's Issues

tmp

texlive-base texlive-binaries texlive-fonts-extra texlive-fonts-recommended texlive-generic-recommended texlive-latex-base texlive-latex-extra texlive-latex-recommended texlive-luatex texlive-math-extra texlive-pictures texlive-science

pseq or seq are intrinsically useless for the ArrowLoop problem

Ideas for Java Version

https://github.com/KindedJ/KindedJ

check if MVar Future really needs forkIO

Further Ideas for the conf parameter

We already have the conf parameter. We can exploit the type parameter to handle stuff like defining where to spawn processes. This is already present in a way, but could be used even more.

A potential distributed implementation of our interface could probably bastardize the conf parameter to host information about what nodes are available, what state we are in etc.. This info could fit into a monadic type quite well (or a state-arrow for that matter) and would not break with our "monads-are-not-required" approach. We use Arrows/Profunctors to model the processes and use Monads to manage the application state instead of requiring them to model parallelism. Via the conf parameter we can make parEvalN work inside our current harness, while still being able to model a "global state". The default configuration () could be lost in such a backend, however.

More general Interface

The following would have been possible as well, but is stuff for the next paper.

class (Category p) => Parallelizable p where
  lift :: (a -> b) -> p a b
  firstP :: p a b -> p (a, c) (b, c)
  leftP :: p a b -> p (Either a d) (Either b d)
  loopP :: p (a, c) (b, c) -> p a b

instance (Category p, Choice p, Costrong p, Strong p) => Parallelizable p where
  lift f = dimap id f id
  firstP = first'
  leftP = left'
  loopP = unfirst

instance (ArrowChoice a, ArrowLoop a) => Parallelizable a where
  lift = arr
  firstP = first
  leftP = left
  loopP = loop

instance (Trans b, ArrowChoice arr) => ArrowParallel arr a b Conf where
  parEvalN _ fs = evalN fs >>> arr (spawnF (repeat id))

This has, however, to be checked performance wise.

Relwork

Some Relwork for the final version of the paper:

https://blog.jle.im/entry/a-dead-end-arrowized-dataflow-parallelism-interface-attempt.html

MVar is no good implementation for Future.

A Basic implementation like this would be better:

data BasicFuture a = BF a

instance (NFData a) => NFData (BasicFuture a) where
rnf (BF a) = rnf a

instance (NFData a) => Future BasicFuture a where
put = arr BF
get = arr $ (BF a) -> a

Use Type Families instead of Functional Dependencies for Future(s)

Things to fix in the paper

remove all ArrowApply variants from text
remove text explaining ArrowApply usage
update all Definitions to new ones regarding ArrowApply change
rename listApp to something better (it is more of a evalN or a sequence)
update Torus/Ring/Pipe chapter to reflect fixes with FutureEval that make it possible to use Multicore and ParMonad with them
Fix Arrow/arrow, Monad/monad, Profunctor/profunctor etc...