Portability | not portable |
---|---|
Stability | beta |
Maintainer | eden@mathematik.uni-marburg.de |
Safe Haskell | Safe-Infered |
This Haskell module defines map-like skeletons for the parallel functional language Eden.
Depends on GHC. Using standard GHC, you will get a threaded simulation of Eden. Use the forked GHC-Eden compiler from http://www.mathematik.uni-marburg.de/~eden for a parallel build.
Eden Group ( http://www.mathematik.uni-marburg.de/~eden )
- parMap :: (Trans a, Trans b) => (a -> b) -> [a] -> [b]
- ranch :: (Trans b, Trans c) => (a -> [b]) -> ([c] -> d) -> (b -> c) -> a -> d
- farm :: (Trans a, Trans b) => ([a] -> [[a]]) -> ([[b]] -> [b]) -> (a -> b) -> [a] -> [b]
- farmS :: (Trans a, Trans b) => Int -> (a -> b) -> [a] -> [b]
- farmB :: (Trans a, Trans b) => Int -> (a -> b) -> [a] -> [b]
- offlineFarm :: Trans b => Int -> ([a] -> [[a]]) -> ([[b]] -> [b]) -> (a -> b) -> [a] -> [b]
- offlineFarmS :: (Trans a, Trans b) => Int -> (a -> b) -> [a] -> [b]
- offlineFarmB :: (Trans a, Trans b) => Int -> (a -> b) -> [a] -> [b]
- parMapAt :: (Trans a, Trans b) => Places -> (a -> b) -> [a] -> [b]
- ranchAt :: (Trans b, Trans c) => Places -> (a -> [b]) -> ([c] -> d) -> (b -> c) -> a -> d
- farmAt :: (Trans a, Trans b) => Places -> ([a] -> [[a]]) -> ([[b]] -> [b]) -> (a -> b) -> [a] -> [b]
- offlineFarmAt :: Trans b => Places -> Int -> ([a] -> [[a]]) -> ([[b]] -> [b]) -> (a -> b) -> [a] -> [b]
- mapFarmS, mapOfflineFarmB, mapOfflineFarmS, mapFarmB :: (Trans a, Trans b) => (a -> b) -> [a] -> [b]
- farmClassic :: (Trans a, Trans b) => Int -> (Int -> [a] -> [[a]]) -> ([[b]] -> [b]) -> (a -> b) -> [a] -> [b]
- ssf :: forall a b. Trans b => Int -> (Int -> [a] -> [[a]]) -> ([[b]] -> [b]) -> (a -> b) -> [a] -> [b]
- offline_farm :: Trans b => Int -> ([a] -> [[a]]) -> ([[b]] -> [b]) -> (a -> b) -> [a] -> [b]
- map_par :: (Trans a, Trans b) => (a -> b) -> [a] -> [b]
- map_farm, map_ssf, map_offlineFarm :: (Trans a, Trans b) => (a -> b) -> [a] -> [b]
Custom map skeletons
These skeletons expose many parameters to the user and thus have varying types
Basic parMap Skeleton - one process for each list element
:: (Trans b, Trans c) | |
=> (a -> [b]) | input transformation function |
-> ([c] -> d) | result reduction function |
-> (b -> c) | worker function |
-> a | input |
-> d | output |
A process ranch is a generalized (or super-) farm. Arbitrary input is transformed into a list of inputs for the worker processes (one worker for each transformed value). The worker inputs are processed by the worker function. The results of the worker processes are then reduced using the reduction function.
:: (Trans a, Trans b) | |
=> ([a] -> [[a]]) | input distribution function |
-> ([[b]] -> [b]) | result combination function |
-> (a -> b) | mapped function |
-> [a] | input |
-> [b] | output |
A farm distributes its input to a number of worker processes. The distribution function divides the input list into sublists - each sublist is input to one worker process, the number of worker processes is determined by the number of sublists. The results of the worker processes are then combined using the combination function.
Like the farm
, but uses a fixed round-robin distribution of tasks.
Like the farm
, but uses a fixed block distribution of tasks.
:: Trans b | |
=> Int | number of processes |
-> ([a] -> [[a]]) | input distribution function |
-> ([[b]] -> [b]) | result combination function |
-> (a -> b) | mapped function |
-> [a] | input |
-> [b] | output |
Offline farm (alias direct mapping): Like the farm, but tasks are evaluated inside the workers (less communication overhead). Tasks are mapped inside each generated process abstraction avoiding evaluating and sending them. This often reduces the communication overhead because unevaluated data is usually much smaller than evaluated data.
Use map_offlineFarm
if you want a simpler interface.
Notice: The offline farm receives the number of processes to be created as its first parameter. The task lists structure has to be completely defined before process instantiation takes place.
Like the offlineFarm
, but with fixed round-robin distribution of tasks.
Like the offlineFarm
, but with fixed block distribution of tasks.
Custom map skeletons with explicit placement
Map skeleton versions with explicit placement
:: (Trans a, Trans b) | |
=> Places | places for instantiation |
-> (a -> b) | worker function |
-> [a] | task list |
-> [b] | result list |
Basic parMap Skeleton - one process for each list element. This version takes places for instantiation on particular PEs.
:: (Trans b, Trans c) | |
=> Places | places for instantiation |
-> (a -> [b]) | input transformation function |
-> ([c] -> d) | result reduction function |
-> (b -> c) | worker function |
-> a | input |
-> d | output |
A process ranch is a generalized (or super-) farm. This version takes places for instantiation. Arbitrary input is transformed into a list of inputs for the worker processes (one worker for each transformed value). The worker inputs are processed by the worker function. The results of the worker processes are then reduced using the reduction function.
:: (Trans a, Trans b) | |
=> Places | places for instantiation |
-> ([a] -> [[a]]) | input distribution function |
-> ([[b]] -> [b]) | result combination function |
-> (a -> b) | mapped function |
-> [a] | input |
-> [b] | output |
A farm distributes its input to a number of worker processes. This version takes places for instantiation. The distribution function divides the input list into sublists - each sublist is input to one worker process, the number of worker processes is determined by the number of sublists. The results of the worker processes are then combined using the combination function.
Use map_farm
if you want a simpler interface.
:: Trans b | |
=> Places | places for instantiation |
-> Int | number of processes |
-> ([a] -> [[a]]) | input distribution function |
-> ([[b]] -> [b]) | result combination function |
-> (a -> b) | mapped function |
-> [a] | input |
-> [b] | output |
Offline farm with explicit placement (alias self-service farm or direct mapping): Like the farm, but tasks are evaluated inside the workers (less communication overhead). Tasks are mapped inside each generated process abstraction, avoiding evaluating and sending them. This often reduces the communication overhead because unevaluated data is usually much smaller than evaluated data.
Use map_offlineFarm
if you want a simpler interface.
Notice: The task lists structure has to be completely defined before process instantiation takes place.
Simple map skeleton variants
The map skeletons farm
and offlineFarm
can be used to define
skeletons with the simpler sequential map interface :: (a -> b) -> [a] -> [b]
mapFarmS,mapOfflineFarmB,mapOfflineFarmS,mapFarmBSource
Parallel map variant with map interface using (max (noPe-1) 1) worker processes. Skeletons ending on S
use round-robin distribution, skeletons ending on B
use block distribution of tasks.
Deprecated map skeletons
These skeletons are included to keep old code alive. Use the skeletons above.
:: (Trans a, Trans b) | |
=> Int | number of child processes |
-> (Int -> [a] -> [[a]]) | input distribution function |
-> ([[b]] -> [b]) | result combination function |
-> (a -> b) | mapped function |
-> [a] | input |
-> [b] | output |
Deprecated, use the farm
;
farmClassic
distributes its input to a number of worker processes.
This is the Classic version as described in the Eden standard reference
Parallel Functional Programming in Eden.
The distribution function is expected to divide the input list into
the given number of sublists. In the new farm the number of sublists is
determined only by the distribution function.
Use map_farm
if you want a simpler interface.
:: forall a b . Trans b | |
=> Int | number of child processes |
-> (Int -> [a] -> [[a]]) | input distribution function |
-> ([[b]] -> [b]) | result combination function |
-> (a -> b) | mapped function |
-> [a] | input |
-> [b] | output |
Deprecated, use offlineFarm
;
Self service farm. Like the farm, but
tasks are evaluated in the workers (less communication overhead).
This is the classic version. The distribution function is expected
to divide the input list into the given number of sublists. In the
new self service farm the number of sublists is determined only by
the distribution function.
Use map_ssf
if you want a simpler interface.
Notice: The task lists structure has to be completely defined before process instantiation takes place.
:: Trans b | |
=> Int | number of processes |
-> ([a] -> [[a]]) | input distribution function |
-> ([[b]] -> [b]) | result combination function |
-> (a -> b) | mapped function |
-> [a] | input |
-> [b] | output |
Deprecated: Same as offlineFarm
.
Deprecated: Same as parMap
.