SUSE Package Hub 15 oneclick install
Install ghcspeculation
NOTE: This oneclick installation requires that the SUSE Package Hub extension to already be enabled.
See http://packagehub.suse.com/howtouse/ for information on enabling the Package Hub extension
If the extension is not enabled, this installation will fail while trying to enable an invalid repo.
This package might depend on packages from SUSE Linux Enterprise modules. If those modules are not enabled, a package dependency error will be encountered.
SUSEPackageHub15StandardPool
Package Hub 15
Dummy repo  this will fail

ghcspeculation
A framework for safe, programmable, speculative parallelism
A framework for safe, programmable, speculative parallelism, loosely based on:
* Prakash Prabhu, G. Ramalingam, and Kapil Vaswani, "/Safe Programmable
Speculative Parallelism/", In the proceedings of Programming Language Design
and Implementation (PLDI) Vol 45, Issue 6 (June 2010) pp 5061.
<http://research.microsoft.com/pubs/118795/pldi026vaswani.pdf>
This package provides speculative function application and speculative folds.
Speculative STM transactions take the place of the transactional rollback
machinery from the paper.
For example:
''spec' g f a' evaluates 'f g' while forcing 'a', if 'g == a' then 'f g' is
returned, otherwise 'f a' is evaluated and returned. Furthermore, if the
argument has already been evaluated, we skip the 'f g' computation entirely.
If a good guess at the value of 'a' is available, this is one way to induce
parallelism in an otherwise sequential task. However, if the guess isn't
available more cheaply than the actual answer, then this saves no work and if
the guess is wrong, you risk evaluating the function twice. Under high load,
since 'f g' is computed via the spark queue, the speculation will be skipped
and you will obtain the same answer as 'f $! a'.
The bestcase timeline looks like:
> foreground: [ a ] > foreground: [] (check g == a) > spark: [
f g ] > overall: [ spec g f a ]
The worstcase timeline looks like:
> foreground: [ a ] > foreground: [] (check g == a) > foreground:
[ f a ] > spark: [ f g ] > overall: [ spec g f a
]
Note that, if 'f g' takes longer than a to compute, in the HEAD release of GHC,
'f g' will be collected and killed during garbage collection.
> foreground: [ a ] > foreground: [] (check g == a) > foreground:
[ f a ] > spark: [ f g ###### (#'s mark when this spark is
collectable) > overall: [ spec g f a ]
Under high load:
> foreground: [ a ] > foreground: [] (check g == a) > foreground:
[ f a ] > overall: [ spec g f a ]
Compare these to the timeline of 'f $! a':
> foreground: [ a ] > foreground: [ f a ] > orverall:
[ f $! a ]
'specSTM' provides a similar time table for STM actions, but also rolls back
sideeffects. The one unfortunate operational distinction is that it is forced
to compute 'a' in the background thread and therefore degrades slightly less
gracefully under load, although we mitigate this effect by only enqueuing if
the number of sparks for the current capability is lower than the total number
of capabilities, to try to avoid wasting time when all computational resources
are in use.
SUSE Package Hub 15 oneclick install
Install ghcspeculation
NOTE: This oneclick installation requires that the SUSE Package Hub extension to already be enabled.
See http://packagehub.suse.com/howtouse/ for information on enabling the Package Hub extension
If the extension is not enabled, this installation will fail while trying to enable an invalid repo.
This package might depend on packages from SUSE Linux Enterprise modules. If those modules are not enabled, a package dependency error will be encountered.
SUSEPackageHub15StandardPool
Package Hub 15
Dummy repo  this will fail

ghcspeculation
A framework for safe, programmable, speculative parallelism
A framework for safe, programmable, speculative parallelism, loosely based on:
* Prakash Prabhu, G. Ramalingam, and Kapil Vaswani, "/Safe Programmable
Speculative Parallelism/", In the proceedings of Programming Language Design
and Implementation (PLDI) Vol 45, Issue 6 (June 2010) pp 5061.
<http://research.microsoft.com/pubs/118795/pldi026vaswani.pdf>
This package provides speculative function application and speculative folds.
Speculative STM transactions take the place of the transactional rollback
machinery from the paper.
For example:
''spec' g f a' evaluates 'f g' while forcing 'a', if 'g == a' then 'f g' is
returned, otherwise 'f a' is evaluated and returned. Furthermore, if the
argument has already been evaluated, we skip the 'f g' computation entirely.
If a good guess at the value of 'a' is available, this is one way to induce
parallelism in an otherwise sequential task. However, if the guess isn't
available more cheaply than the actual answer, then this saves no work and if
the guess is wrong, you risk evaluating the function twice. Under high load,
since 'f g' is computed via the spark queue, the speculation will be skipped
and you will obtain the same answer as 'f $! a'.
The bestcase timeline looks like:
> foreground: [ a ] > foreground: [] (check g == a) > spark: [
f g ] > overall: [ spec g f a ]
The worstcase timeline looks like:
> foreground: [ a ] > foreground: [] (check g == a) > foreground:
[ f a ] > spark: [ f g ] > overall: [ spec g f a
]
Note that, if 'f g' takes longer than a to compute, in the HEAD release of GHC,
'f g' will be collected and killed during garbage collection.
> foreground: [ a ] > foreground: [] (check g == a) > foreground:
[ f a ] > spark: [ f g ###### (#'s mark when this spark is
collectable) > overall: [ spec g f a ]
Under high load:
> foreground: [ a ] > foreground: [] (check g == a) > foreground:
[ f a ] > overall: [ spec g f a ]
Compare these to the timeline of 'f $! a':
> foreground: [ a ] > foreground: [ f a ] > orverall:
[ f $! a ]
'specSTM' provides a similar time table for STM actions, but also rolls back
sideeffects. The one unfortunate operational distinction is that it is forced
to compute 'a' in the background thread and therefore degrades slightly less
gracefully under load, although we mitigate this effect by only enqueuing if
the number of sparks for the current capability is lower than the total number
of capabilities, to try to avoid wasting time when all computational resources
are in use.