Airtel Parallel Ringing Activation
Copyright | (c) The University of Glasgow 2001-2010 |
---|---|
License | BSD-style (see the file libraries/base/LICENSE) |
Maintainer | libraries@haskell.org |
Stability | experimental |
Portability | portable |
Safe Haskell | None |
Language | Haskell2010 |
Control.Parallel.Strategies
Contents
- Strategies for lists
Description
Parallel Evaluation Strategies, or Strategies for short, provide ways to express parallel computations. Strategies have the following key features:
- Strategies express deterministic parallelism: the result of the program is unaffected by evaluating in parallel. The parallel tasks evaluated by a Strategy may have no side effects. For non-deterministic parallel programming, see Control.Concurrent.
- Strategies let you separate the description of the parallelism from the logic of your program, enabling modular parallelism. The basic idea is to build a lazy data structure representing the computation, and then write a Strategy that describes how to traverse the data structure and evaluate components of it sequentially or in parallel.
- Strategies are compositional: larger strategies can be built by gluing together smaller ones.
Monad
andApplicative
instances are provided, for quickly building strategies that involve traversing structures in a regular way.
For API history and changes in this release, see Control.Parallel.Strategies.
Synopsis
- typeStrategy a = a -> Eval a
- using :: a -> Strategy a -> a
- withStrategy :: Strategy a -> a -> a
- dot :: Strategy a -> Strategy a -> Strategy a
- r0 :: Strategy a
- rseq :: Strategy a
- rdeepseq :: NFData a => Strategy a
- rpar :: Strategy a
- rparWith :: Strategy a -> Strategy a
- evalSeq :: SeqStrategy a -> Strategy a
- typeSeqStrategy a = Strategy a
- evalTraversable :: Traversable t => Strategy a -> Strategy (t a)
- parTraversable :: Traversable t => Strategy a -> Strategy (t a)
- evalList :: Strategy a -> Strategy [a]
- parList :: Strategy a -> Strategy [a]
- evalListN :: Int -> Strategy a -> Strategy [a]
- parListN :: Int -> Strategy a -> Strategy [a]
- evalListNth :: Int -> Strategy a -> Strategy [a]
- parListNth :: Int -> Strategy a -> Strategy [a]
- evalListSplitAt :: Int -> Strategy [a] -> Strategy [a] -> Strategy [a]
- parListSplitAt :: Int -> Strategy [a] -> Strategy [a] -> Strategy [a]
- parListChunk :: Int -> Strategy a -> Strategy [a]
- parMap :: Strategy b -> (a -> b) -> [a] -> [b]
- evalBuffer :: Int -> Strategy a -> Strategy [a]
- parBuffer :: Int -> Strategy a -> Strategy [a]
- evalTuple2 :: Strategy a -> Strategy b -> Strategy (a, b)
- evalTuple3 :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c)
- evalTuple4 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy (a, b, c, d)
- evalTuple5 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy (a, b, c, d, e)
- evalTuple6 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy (a, b, c, d, e, f)
- evalTuple7 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy (a, b, c, d, e, f, g)
- evalTuple8 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy (a, b, c, d, e, f, g, h)
- evalTuple9 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy i -> Strategy (a, b, c, d, e, f, g, h, i)
- parTuple2 :: Strategy a -> Strategy b -> Strategy (a, b)
- parTuple3 :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c)
- parTuple4 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy (a, b, c, d)
- parTuple5 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy (a, b, c, d, e)
- parTuple6 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy (a, b, c, d, e, f)
- parTuple7 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy (a, b, c, d, e, f, g)
- parTuple8 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy (a, b, c, d, e, f, g, h)
- parTuple9 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy i -> Strategy (a, b, c, d, e, f, g, h, i)
- ($ ) :: (a -> b) -> Strategy a -> a -> b
- ($ ) :: (a -> b) -> Strategy a -> a -> b
- (. ) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c
- (. ) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c
- (- ) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c
- (- ) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c
- dataEval a
- runEval :: Eval a -> a
- typeDone = ()
- demanding :: a -> Done -> a
- sparking :: a -> Done -> a
- (> ) :: Done -> Done -> Done
- (> ) :: Done -> Done -> Done
- rwhnf :: Strategy a
- unEval :: Eval a -> a
- seqTraverse :: Traversable t => Strategy a -> Strategy (t a)
- parTraverse :: Traversable t => Strategy a -> Strategy (t a)
- seqList :: Strategy a -> Strategy [a]
- seqPair :: Strategy a -> Strategy b -> Strategy (a, b)
- parPair :: Strategy a -> Strategy b -> Strategy (a, b)
- seqTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c)
- parTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c)
- classNFData a
typeStrategy a = a -> Eval a Source#
A Strategy
is a function that embodies a parallel evaluation strategy. The function traverses (parts of) its argument, evaluating subexpressions in parallel or in sequence.
A Strategy
may do an arbitrary amount of evaluation of its argument, but should not return a value different from the one it was passed.
Parallel computations may be discarded by the runtime system if the program no longer requires their result, which is why a Strategy
function returns a new value equivalent to the old value. The intention is that the program applies the Strategy
to a structure, and then uses the returned value, discarding the old value. This idiom is expressed by the using
function.
using :: a -> Strategy a -> a infixl 0Source#
withStrategy :: Strategy a -> a -> a Source#
evaluate a value using the given Strategy
. This is simply using
with the arguments reversed.
dot :: Strategy a -> Strategy a -> Strategy a infixr 9Source#
Compose two strategies sequentially. This is the analogue to function composition on strategies.
r0 :: Strategy a Source#
rseq :: Strategy a Source#
rseq
evaluates its argument to weak head normal form.
rdeepseq :: NFData a => Strategy a Source#
rpar :: Strategy a Source#
rpar
sparks its argument (for evaluation in parallel).
rparWith :: Strategy a -> Strategy a Source#
instead of saying rpar
, you can say dot
stratrparWith strat
. Compared to rpar
, rparWith
- does not exit the
Eval
monad - does not have a built-in
rseq
, so for example `rparWith r0` behaves as you might expect (it is a strategy that creates a spark that does no evaluation).
evalSeq :: SeqStrategy a -> Strategy a Source#
Inject a sequential strategy (ie. coerce a sequential strategy to a general strategy).
Thanks to evalSeq
, the type Control.Seq.Strategy a
is a subtype of
.Strategy
a
typeSeqStrategy a = Strategy a Source#
A name for Control.Seq.Strategy
, for documentation only.
evalTraversable :: Traversable t => Strategy a -> Strategy (t a) Source#
Evaluate the elements of a traversable data structure according to the given strategy.
parTraversable :: Traversable t => Strategy a -> Strategy (t a) Source#
Like evalTraversable
but evaluates all elements in parallel.
evalList :: Strategy a -> Strategy [a] Source#
Evaluate each element of a list according to the given strategy. Equivalent to evalTraversable
at the list type.
parList :: Strategy a -> Strategy [a] Source#
Evaluate each element of a list in parallel according to given strategy. Equivalent to parTraversable
at the list type.
evalListN :: Int -> Strategy a -> Strategy [a] Source#
Evaluate the first n elements of a list according to the given strategy.
parListN :: Int -> Strategy a -> Strategy [a] Source#
Like evalListN
but evaluates the first n elements in parallel.
evalListNth :: Int -> Strategy a -> Strategy [a] Source#
Evaluate the nth element of a list (if there is such) according to the given strategy. This nth is 0-based. For example, [1, 2, 3, 4, 5]
will eval using
evalListNth 4 rseq5
, not 4
. The spine of the list up to the nth element is evaluated as a side effect.
parListNth :: Int -> Strategy a -> Strategy [a] Source#
Like evalListN
but evaluates the nth element in parallel.
evalListSplitAt :: Int -> Strategy [a] -> Strategy [a] -> Strategy [a] Source#
evaluates the prefix (of length evaListSplitAt
n stratPref stratSuffn
) of a list according to stratPref
and its the suffix according to stratSuff
.
parListSplitAt :: Int -> Strategy [a] -> Strategy [a] -> Strategy [a] Source#
Like evalListSplitAt
but evaluates both sublists in parallel.
parListChunk :: Int -> Strategy a -> Strategy [a] Source#
Divides a list into chunks, and applies the strategy
to each chunk in parallel.evalList
strat
It is expected that this function will be replaced by a more generic clustering infrastructure in the future.
If the chunk size is 1 or less, parListChunk
is equivalent to parList
parMap :: Strategy b -> (a -> b) -> [a] -> [b] Source#
A combination of parList
and map
, encapsulating a common pattern:
Strategies for lazy lists
evalBuffer :: Int -> Strategy a -> Strategy [a] Source#
evalBuffer
is a rolling buffer strategy combinator for (lazy) lists.
evalBuffer
is not as compositional as the type suggests. In fact, it evaluates list elements at least to weak head normal form, disregarding a strategy argument r0
.
parBuffer :: Int -> Strategy a -> Strategy [a] Source#
Like evalBuffer
but evaluates the list elements in parallel when pushing them into the buffer.
Evaluate the components of a tuple according to the given strategies.
evalTuple2 :: Strategy a -> Strategy b -> Strategy (a, b) Source#
evalTuple3 :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) Source#
evalTuple4 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy (a, b, c, d) Source#
evalTuple5 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy (a, b, c, d, e) Source#
evalTuple6 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy (a, b, c, d, e, f) Source#
evalTuple7 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy (a, b, c, d, e, f, g) Source#
evalTuple8 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy (a, b, c, d, e, f, g, h) Source#
evalTuple9 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy i -> Strategy (a, b, c, d, e, f, g, h, i) Source#
Evaluate the components of a tuple in parallel according to the given strategies.
parTuple2 :: Strategy a -> Strategy b -> Strategy (a, b) Source#
parTuple3 :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) Source#
parTuple4 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy (a, b, c, d) Source#
parTuple5 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy (a, b, c, d, e) Source#
parTuple6 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy (a, b, c, d, e, f) Source#
parTuple7 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy (a, b, c, d, e, f, g) Source#
parTuple8 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy (a, b, c, d, e, f, g, h) Source#
parTuple9 :: Strategy a -> Strategy b -> Strategy c -> Strategy d -> Strategy e -> Strategy f -> Strategy g -> Strategy h -> Strategy i -> Strategy (a, b, c, d, e, f, g, h, i) Source#
($ ) :: (a -> b) -> Strategy a -> a -> b Source#
Sequential function application. The argument is evaluated using the given strategy before it is given to the function.
($ ) :: (a -> b) -> Strategy a -> a -> b Source#
Parallel function application. The argument is evaluated using the given strategy, in parallel with the function application.
(. ) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c Source#
Sequential function composition. The result of the second function is evaluated using the given strategy, and then given to the first function.
(. ) :: (b -> c) -> Strategy b -> (a -> b) -> a -> c Source#
Parallel function composition. The result of the second function is evaluated using the given strategy, in parallel with the application of the first function.
(- ) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c Source#
Sequential inverse function composition, for those who read their programs from left to right. The result of the first function is evaluated using the given strategy, and then given to the second function.
(- ) :: (a -> b) -> Strategy b -> (b -> c) -> a -> c Source#
Parallel inverse function composition, for those who read their programs from left to right. The result of the first function is evaluated using the given strategy, in parallel with the application of the second function.
dataEval a Source#
Eval
is a Monad that makes it easier to define parallel strategies. It is a strict identity monad: that is, in
m
is evaluated before the result is passed to f
.
If you wanted to construct a Strategy
for a pair that sparked the first component in parallel and then evaluated the second component, you could write
Alternatively, you could write this more compactly using the Applicative style as
Instances
MonadEvalSource# | |
Methods (>>=) :: Eval a -> (a -> Eval b) -> Eval b # (>>) :: Eval a -> Eval b -> Eval b # return :: a -> Eval a # fail :: String -> Eval a # | |
FunctorEvalSource# | |
Methods fmap :: (a -> b) -> Eval a -> Eval b # (<$) :: a -> Eval b -> Eval a # | |
ApplicativeEvalSource# | |
Methods pure :: a -> Eval a # (<*>) :: Eval (a -> b) -> Eval a -> Eval b # (*>) :: Eval a -> Eval b -> Eval b # (<*) :: Eval a -> Eval b -> Eval a # |
runEval :: Eval a -> a Source#
The strategies library has a long history. What follows is asummary of how the current design evolved, and is mostly ofinterest to those who are familiar with an older version, or needto adapt old code to use the newer API.
Version 1.x
The original Strategies design is described in Algorithm + Strategy = Parallelismhttp://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html and the code was written by Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al.
Version 2.x
Later, during work on the shared-memory implementation ofparallelism in GHC, we discovered that the original formulation ofStrategies had some problems, in particular it lead to space leaksand difficulties expressing speculative parallelism. Details are inthe paper Runtime Support for Multicore Haskellhttp://community.haskell.org/~simonmar/papers/multicore-ghc.pdf.
This module has been rewritten in version 2. The main change is tothe 'Strategy a' type synonym, which was previously a -> Done
andis now a -> Eval a
. This change helps to fix the space leak describedin 'Runtime Support for Multicore Haskell'. The problem is thatthe runtime will currently retain the memory referenced by allsparks, until they are evaluated. Hence, we must arrange toevaluate all the sparks eventually, just in case they aren'tevaluated in parallel, so that they don't cause a space leak. Thisis why we must return a 'new' value after applying a Strategy
,so that the application can evaluate each spark created by theStrategy
.
The simple rule is this: you must use the result of applyinga Strategy
if the strategy creates parallel sparks, and youshould probably discard the the original value. If you don'tdo this, currently it may result in a space leak. In thefuture (GHC 6.14), it will probably result in lost parallelisminstead, as we plan to change GHC so that unreferenced sparksare discarded rather than retained (we can't make this changeuntil most code is switched over to this new version ofStrategies, because code using the old verison of Strategieswould be broken by the change in policy).
The other changes in version 2.x are:
- Strategies can now be defined using a convenient Monad/Applicative type,
Eval
. e.g.parList s = traverse (Par . (`
using
` s)) parList
has been generalised toparTraverse
, which works on anyTraversable
type, and similarlyseqList
has been generalised toseqTraverse
parList
andparBuffer
have versions specialised torwhnf
, and there are transformation rules that automatically translate e.g.parList rwnhf
into a call to the optimised version.NFData
has been moved toControl.DeepSeq
in thedeepseq
package. Note that since theStrategy
type changed,rnf
is no longer aStrategy
: userdeepseq
instead.
Version 2.1 moved NFData into a separate package, deepseq
.
Version 2.2 changed the type of Strategy to a -> Eval a
, andre-introduced the r0
strategy which was missing in version 2.1.
Version 2.3 simplified the Eval
type, so that Eval
is now justthe strict identity monad. This change and various otherimprovements and refactorings are thanks to Patrick Maier whonoticed that Eval
didn't satisfy the monad laws, and that asimpler version would fix that problem.
(version 2.3 was not released on Hackage).
Version 3 introduced a major overhaul of the API, to match what ispresented in the paper
Seq no More: Better Strategies for Parallel Haskellhttp://community.haskell.org/~simonmar/papers/strategies.pdf
The major differences in the API are:
- The addition of Sequential strategies (Control.Seq) as a composable means for specifying sequential evaluation.
- Changes to the naming scheme:
rwhnf
renamed torseq
,seqList
renamed toevalList
,seqPair
renamed toevalTuple2
,
The naming scheme is now as follows:
- Basic polymorphic strategies (of type
) are calledStrategy
ar..
. Examples:r0
,rseq
,rpar
,rdeepseq
. - A strategy combinator for a particular type constructor or constructor class
T
is calledevalT..
,parT..
orseqT..
. - The
seqT..
combinators (residing in module Control.Seq) yield sequential strategies. Thus,seqT..
combinators cannot spark, nor can the sequential strategies to which they may be applied. Examples:seqTuple2
,seqListN
,seqFoldable
. - The
evalT..
combinators do not spark themselves, yet they may be applied to strategies that do spark. (They may also be applied to non-sparking strategies; however, in that case the correspondingseqT..
combinator might be a better choice.) Examples:evalTuple2
,evalListN
,evalTraversable
. - The
parT..
combinators, which are derived from theirevalT..
counterparts, do spark. They may be applied to all strategies, whether sparking or not. Examples:parTuple2
,parListN
,parTraversable
. - An exception to the type driven naming scheme are
evalBuffer
andparBuffer
, which are not named after their type constructor (lists) but after their function (rolling buffer of fixed size).
These functions and types are all deprecated, and will be removed in a future release. In all cases they have been either renamed or replaced with equivalent functionality.
typeDone = () Source#
Deprecated: The Strategy type is now a -> Eval a, not a -> Done
DEPRECCATED: replaced by the Eval
monad
demanding :: a -> Done -> a Source#
DEPRECATED: Use pseq
or $
instead
sparking :: a -> Done -> a Source#
DEPRECATED: Use par
or $
instead
(> ) :: Done -> Done -> DoneSource#
DEPRECATED: Use pseq
or $
instead
(> ) :: Done -> Done -> DoneSource#
DEPRECATED: Use par
or $
instead
rwhnf :: Strategy a Source#
DEPRECATED: renamed to rseq
unEval :: Eval a -> a Source#
DEPRECATED: renamed to runEval
seqTraverse :: Traversable t => Strategy a -> Strategy (t a) Source#
DEPRECATED: renamed to evalTraversable
parTraverse :: Traversable t => Strategy a -> Strategy (t a) Source#
DEPRECATED: renamed to parTraversable
seqList :: Strategy a -> Strategy [a] Source#
DEPRECATED: renamed to evalList
seqPair :: Strategy a -> Strategy b -> Strategy (a, b) Source#
DEPRECATED: renamed to evalTuple2
parPair :: Strategy a -> Strategy b -> Strategy (a, b) Source#
DEPRECATED: renamed to parTuple2
seqTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) Source#
DEPRECATED: renamed to evalTuple3
parTriple :: Strategy a -> Strategy b -> Strategy c -> Strategy (a, b, c) Source#
DEPRECATED: renamed to parTuple3
so users of rdeepseq
aren't required to import Control.DeepSeq:
classNFData a #
A class of types that can be fully evaluated.
Since: 1.1.0.0
Instances
NFDataBool | |
NFDataChar | |
NFDataDouble | |
NFDataFloat | |
NFDataInt | |
NFDataInt8 | |
NFDataInt16 | |
NFDataInt32 | |
NFDataInt64 | |
NFDataInteger | |
NFDataWord | |
NFDataWord8 | |
NFDataWord16 | |
NFDataWord32 | |
NFDataWord64 | |
NFDataCallStack | Since: 1.4.2.0 |
NFDataTypeRep | NOTE: Only defined for Since: 1.4.0.0 |
NFData () | |
NFDataTyCon | NOTE: Only defined for Since: 1.4.0.0 |
NFDataNatural | Since: 1.4.0.0 |
NFDataVoid | Defined as Since: 1.4.0.0 |
NFDataVersion | Since: 1.3.0.0 |
NFDataUnique | Since: 1.4.0.0 |
NFDataThreadId | Since: 1.4.0.0 |
NFDataExitCode | Since: 1.4.2.0 |
NFDataCChar | Since: 1.4.0.0 |
NFDataCSChar | Since: 1.4.0.0 |
NFDataCUChar | Since: 1.4.0.0 |
NFDataCShort | Since: 1.4.0.0Tutorial sketchup bahasa indonesia pdf. |
NFDataCUShort | Since: 1.4.0.0 |
NFDataCInt | Since: 1.4.0.0 |
NFDataCUInt | Since: 1.4.0.0 |
NFDataCLong | Since: 1.4.0.0 |
NFDataCULong | Since: 1.4.0.0 |
NFDataCLLong | Since: 1.4.0.0 |
NFDataCULLong | Since: 1.4.0.0 |
NFDataCFloat | Since: 1.4.0.0 |
NFDataCDouble | Since: 1.4.0.0 |
NFDataCPtrdiff | Since: 1.4.0.0 |
NFDataCSize | Since: 1.4.0.0 |
NFDataCWchar | Since: 1.4.0.0 |
NFDataCSigAtomic | Since: 1.4.0.0 |
NFDataCClock | Since: 1.4.0.0 |
NFDataCTime | Since: 1.4.0.0 |
NFDataCUSeconds | Since: 1.4.0.0 |
NFDataCSUSeconds | Since: 1.4.0.0 |
NFDataCFile | Since: 1.4.0.0 |
NFDataCFpos | Since: 1.4.0.0 |
NFDataCJmpBuf | Since: 1.4.0.0 |
NFDataCIntPtr | Since: 1.4.0.0 |
NFDataCUIntPtr | Since: 1.4.0.0 |
NFDataCIntMax | Since: 1.4.0.0 |
NFDataCUIntMax | Since: 1.4.0.0 |
NFDataAll | Since: 1.4.0.0 |
NFDataAny | Since: 1.4.0.0 |
NFDataFingerprint | Since: 1.4.0.0 |
NFDataSrcLoc | Since: 1.4.2.0 |
NFData a => NFData [a] | |
NFData a => NFData (Maybe a) | |
NFData a => NFData (Ratio a) | |
NFData (Ptr a) | Since: 1.4.2.0 |
NFData (FunPtr a) | Since: 1.4.2.0 |
NFData a => NFData (Identity a) | Since: 1.4.0.0 |
NFData a => NFData (Min a) | Since: 1.4.2.0 |
NFData a => NFData (Max a) | Since: 1.4.2.0 |
NFData a => NFData (First a) | Since: 1.4.2.0 |
NFData a => NFData (Last a) | Since: 1.4.2.0 |
NFData m => NFData (WrappedMonoid m) | Since: 1.4.2.0 |
NFData a => NFData (Option a) | Since: 1.4.2.0 |
NFData a => NFData (NonEmpty a) | Since: 1.4.2.0 |
NFData (Fixed a) | Since: 1.3.0.0 |
NFData a => NFData (Complex a) | |
NFData (StableName a) | Since: 1.4.0.0 |
NFData a => NFData (ZipList a) | Since: 1.4.0.0 |
NFData a => NFData (Dual a) | Since: 1.4.0.0 |
NFData a => NFData (Sum a) | Since: 1.4.0.0 |
NFData a => NFData (Product a) | Since: 1.4.0.0 |
NFData a => NFData (First a) | Since: 1.4.0.0 |
NFData a => NFData (Last a) | Since: 1.4.0.0 |
NFData (IORef a) | NOTE: Only strict in the reference and not the referenced value. Since: 1.4.2.0 |
NFData a => NFData (Down a) | Since: 1.4.0.0 |
NFData (MVar a) | NOTE: Only strict in the reference and not the referenced value. Since: 1.4.2.0 |
NFData (a -> b) | This instance is for convenience and consistency with Since: 1.3.0.0 |
(NFData a, NFData b) => NFData (Either a b) | |
(NFData a, NFData b) => NFData (a, b) | |
(NFData a, NFData b) => NFData (Array a b) | |
(NFData a, NFData b) => NFData (Arg a b) | Since: 1.4.2.0 |
NFData (Proxy k a) | Since: 1.4.0.0 |
NFData (STRef s a) | NOTE: Only strict in the reference and not the referenced value. Since: 1.4.2.0 |
(NFData k, NFData a) => NFData (Map k a) | |
(NFData a, NFData b, NFData c) => NFData (a, b, c) | |
NFData a => NFData (Const k a b) | Since: 1.4.0.0 |
(NFData a, NFData b, NFData c, NFData d) => NFData (a, b, c, d) | |
(NFData a1, NFData a2, NFData a3, NFData a4, NFData a5) => NFData (a1, a2, a3, a4, a5) | |
(NFData a1, NFData a2, NFData a3, NFData a4, NFData a5, NFData a6) => NFData (a1, a2, a3, a4, a5, a6) | |
(NFData a1, NFData a2, NFData a3, NFData a4, NFData a5, NFData a6, NFData a7) => NFData (a1, a2, a3, a4, a5, a6, a7) | |
Methods rnf :: (a1, a2, a3, a4, a5, a6, a7) -> () # | |
(NFData a1, NFData a2, NFData a3, NFData a4, NFData a5, NFData a6, NFData a7, NFData a8) => NFData (a1, a2, a3, a4, a5, a6, a7, a8) | |
Methods rnf :: (a1, a2, a3, a4, a5, a6, a7, a8) -> () # | |
(NFData a1, NFData a2, NFData a3, NFData a4, NFData a5, NFData a6, NFData a7, NFData a8, NFData a9) => NFData (a1, a2, a3, a4, a5, a6, a7, a8, a9) | |
Methods rnf :: (a1, a2, a3, a4, a5, a6, a7, a8, a9) -> () # |
This page points to detailed workload models which are based onworkload logs collected from large scale parallel systems inproduction use.As the models do not necessarily include the same features, a shortdescription of each is also provided.
Some of the models include source code of programs to generateworkloads according to this model.An effort is made to create the workloads according to thestandard workload format.
The following directory attempts to compare the scope of the variousmodels:runtime estimates | |||||||
Calzarossa85 | Unix | no | no | no | no | yes | no |
Leland86 | Unix | yes | no | yes | no | no | no |
Sevcik94 | moldable | no | no | yes | yes | no | no |
Feitelson96 | rigid | no | yes | yes | no | partial | no |
Downey97 | moldable | yes | yes | yes | yes | partial | no |
Jann97 | rigid | no | partial | yes | no | yes | no |
Feitelson98 | varied | yes | partial | partial | implied | no | no |
Lublin99 | rigid | no | yes | yes | no | yes | no |
Cirne01 | moldable | yes | yes | yes | yes | yes | no |
Tsafrir05 | no | no | no | no | no | no | yes |
Please send comments and additional information to.
Calzarossa and Serazzi, 1985
This is actually not a model of a parallel workload, but rather amodel of the arrival process of interactive jobs in a multiuserenvironment.It gives the arrival rate as a function of the time of day.It is included because such cyclic arrival patterns do not appear inother models.
There is no available code for this model.If you would like to contribute such code, please contact us.
If you use this model in your work, pleaseacknowledge it by citing the following reference:
Maria Calzarossa and Giuseppe Serazzi,``A Characterization of the Variation in Time of Workload Arrival Patterns'.IEEE Trans. Comput.C-34(2), pp. 156-162, Feb 1985.
This model was used in the following papers:[feitelson98b][gehring99]
Leland and Ott, 1986
This is actually not a model of a parallel workload, but rather amodel of the runtimes of processes in an (interactive) Unix environment.It is included because it may be relevant for interactive parallelworkloads as well.
There is no available code for this model.If you would like to contribute such code, please contact us.
If you use this model in your work, pleaseacknowledge it by citing the following reference:
W. E. Leland and T. J. Ott,``Load-Balancing Heuristics and Process Behavior'.SIGMETRICS Conf. Measurement & Modeling of Comput. Syst.,pp. 54-69, 1986.
This model has been used and re-affirmed in[harcholb96]and also used in[feitelson98b][gehring99]
Sevcik, 1994
This model attempts to capture the speedup characteristics of parallelapplications, including phenomena such as imbalance, inherent serialwork, and parallel overhead.Such a model is useful for evaluating systems where the degree ofparallelism is changed dynamically.
There is no available code for this model.If you would like to contribute such code, please contact us.
If you use this model in your work, pleaseacknowledge it by citing the following reference:
K. C. Sevcik,``Application Scheduling and Processor Allocation in MultiprogrammedParallel Processing Systems'.Performance Evaluation19(2-3), pp. 107-140, Mar 1994.
This model was used in the following papers:[parsons95]
Feitelson, 1996
This model characterizes rigid jobs based on observations from 6 logs.It includes the distribution of job sizes in terms of number ofprocessors, the correlation of runtime with parallelism, and repeatedruns of the same job.
Download code (C program) (10 KB)
If you use this model in your work, pleaseacknowledge it by citing the following reference:
D. G. Feitelson, ``Packingschemes for gang scheduling'.In Job Scheduling Strategies for Parallel Processing,D. G. Feitelson and L. Rudolph (Eds.), Springer-Verlag, 1996,Lect. Notes Comput. Sci. vol. 1162, pp. 89-110.
This model (or variations of it) were used in the following papers:[feitelson97a][feitelson98][feitelson98b][lo98][ghare99][talby99b][aida00][mualem01][feitelson01][feitelson03a][liux12][shih13]
Downey, 1997
This model is based on observations from the SDSC Paragon logs andthe CTC SP2 log.Its two main innovations are in the modeling of job runtimes in a waythat allows the remaining runtime to be estimated conditioned on howlong the job has already run,and modeling moldable jobs where the number of processors used is notset by the model but can be chosen by the scheduler.
Download code for workload generation (C program) (6 KB)
Download code for complete simulation (C program) (19 KB)
• Brand:Line 6 • Model:James Tyler Variax JTV-69 • Year: • Serial Number:W11070328 • Condition:Pre-Owned: Excellent • Case:Line 6 Variax Gig Bag • Color:Dark Metallic Red • Neck Construction:Bolt-On • Neck:Vintage Style Tyler Neck (Maple) • Fingerboard:Rosewood • Frets:22 • Inlays:Dots • Binding:NA • Top:NA • Body/Back:Alder • Wings:NA • Hardware:Chrome • Pickups:Line 6 HSS • Coil Tapping:NA • Bridge:James Tyler Custom Tremolo • Tuners:Grover Imperials • Selector:5 Way • Knobs:Volume, Tone, Selector • Inventory Number:2G3069 • Notes/Extras:25-1/2' Scale.
If you use this model in your work, pleaseacknowledge it by citing the following reference:
Allen B. Downey,``A ParallelWorkload Model and Its Implications for Processor Allocation'.6th Intl. Symp. High Performance Distributed Comput., Aug 1997.
This model was used in the following papers:[downey97c][downey97a][lo98][gehring99][talby99b][cirne00][zhou00][zhou01][feitelson01][feitelson03a][sabin06][huang13a][huang13b][huang13c]
Jann et al, 1997
This is a detailed model of part of the CTC SP2 log.It handles rigid jobs, and provides information about thedistributions of runtimes and interarrival times.
New model parameters were later provided for the workload on the ASCIBlue machine (while parameters are there, they seem to be unusable).
Download original sample code (C program) (10 KB)
Download extended code for complete model,with both parameter sets (C program)(17 KB)
If you use this model in your work, pleaseacknowledge it by citing the following reference:
Joefon Jann, Pratap Pattnaik, Hubertus Franke, Fang Wang, Joseph Skovira, and Joseph Riodan,``Modelingof Workload in MPPs'.In Job Scheduling Strategies for Parallel Processing,D. G. Feitelson and L. Rudolph (Eds.), Springer-Verlag, 1997,Lect. Notes Comput. Sci. vol. 1291, pp. 95-116.
The parameters for the ASCI Blue workload were given in:
H. Franke, J. Jann, J. E. Moreira, P. Pattnaik, and M. A. Jette,``AnEvaluation of Parallel Job Scheduling for ASCI Blue-Pacific'.In Supercomputing '99, Nov 1999.
Regrettably, these parameters seem to be erroneous.
This model (in either version) was used in the following papers:[talby99b][dasilva00][mualem01][zhang01][feitelson01][zhang03b][feitelson03a][feitelson05b][liux12][shih13]
Feitelson and Rudolph, 1998
This is actually more of a framework to create models of the internalstructure of parallel application, in order to be able to investigatethe connections between application behavior and scheduling.
There is no available code (or even parameter values!) for this model.If you would like to contribute such code, please contact us.
If you use this model in your work, pleaseacknowledge it by citing the following reference:
Dror G. Feitelson and Larry Rudolph,``Metricsand Benchmarking for Parallel Job Scheduling'.In Job Scheduling Strategies for Parallel Processing,D. G. Feitelson and L. Rudolph (Eds.), Springer-Verlag, 1998,Lect. Notes Comput. Sci. vol. 1459, pp. 1-24.
This model was used in the following papers:[gehring99]
Lublin, 1999/2003
This is a very detailed model for rigid jobs, that includes an arrivalpattern with a daily cycle, runtimes that are correlated with thenumber of nodes, and a distinction between interactive and batch jobs.
A detailed description is provided at the head of the programimplementing this model.
Download code (C program) (38 KB)
If you use this model in your work, pleaseacknowledge it by citing the following reference:
Uri Lublin and Dror G. Feitelson,TheWorkload on Parallel Supercomputers: Modeling the Characteristics ofRigid Jobs. J. Parallel & Distributed Comput.63(11), pp. 1105-1122, Nov 2003.
This model was used in the following papers:[talby99b][batat00][feitelson01][wiseman03][frachtenberg03b][feitelson03a][barsanti06][goh08][zeng09][sodan09][sodan10][abbes10][minh11][sodan11][toosi11][utrera12][neves12][shih13]
Cirne and Berman, 2001
This is a comprehensive model for generating moldable jobs.It is composed of two parts:
- A model for generating a stream of rigid jobs
- A model for turning the rigid jobs into moldable ones, bygenerating a set of alternative <partition size, runtime> options.This is partly based on Downey's speedup model, for which parameterdistributions are proposed.
Download code for complete model(compressed tar file of C++ source) (37 KB)
Download code for moldability model(compressed tar file of C++ source) (39 KB)
If you use this model in your work, pleaseacknowledge it by citing the following references:
Walfredo Cirne and Francine Berman,``AComprehensive Model of the Supercomputer Workload'.4th Ann. Workshop Workload Characterization, Dec 2001.
and/or
Walfredo Cirne and Francine Berman,``AModel for Moldable Supercomputer Jobs'.15th Intl. Parallel & Distributed Processing Symp., Apr 2001.
This model was used in the following papers:[cao04]
Tsafrir, 2005
This is a very detailed model that generates realistic user runtimeestimates, upon which backfill schedulers rely.The model targets the modal nature of user estimates (very few popularvalues; most popular is the maximal estimate).It is composed of two parts:
- generating a realistic distribution of user runtime estimates, and
- embedding this distribution within a real workload log or the output of a workload model.
Download model's code:Compressed tar file (614K) of C++ source, documentation, and examples
or see detailed listing ofindividual files.
If you use this model in your work, please acknowledge it by citingthe following references:
- Dan Tsafrir, Yoav Etsion, and Dror G. Feitelson, ``Modeling User Runtime Estimates'.11th Workshop on Job Scheduling Strategies for ParallelProcessing (JSSPP), pp. 1-35, Jun 2005.Lecture Notes in Computer Science Vol.3834 (528K).
- Dan Tsafrir,``A Model/Utility to Generate User RuntimeEstimates and Append Them to a Standard Workload File'.URL http://www.cs.huji.ac.il/labs/parallel/workload/m_tsafrir05
Comments are closed.