Difference between revisions of "Benchmarking"
Jump to navigation
Jump to search
(→TODO) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 49: | Line 49: | ||
[[File:Coverage.png |1000px|frameless|Combinator types over benchmark applications]] | [[File:Coverage.png |1000px|frameless|Combinator types over benchmark applications]] | ||
| + | |||
| + | == TODO == | ||
| + | |||
| + | As more programs are included in the current test list, we expect to fill more of the gaps of the distribution above. However, this is not guaranteed. Our observation is that most Haskell benchmarks from [https://github.com/ghc/nofib/ nofib] end up using similar data structures and recursion patterns. The result is that these programs tend to cluster around a few reduction patterns, as shown in the figure. | ||
Latest revision as of 09:33, 8 August 2022
Programs
From nofib
- Sorting
- exp3_8
- digits-of-e
- tak
- nfib
- queens
- x2n1
- primes
- Awards
- Boyer
- Clausify
- Knights
- Cichelli
- SCC
- GCD
- Calendar
- RSA
- lcss
- n-body
- binary-trees
- pidigits
From the Reduceron
Other
Synthetic
- planned
Summary
Benchmark Coverage
How structured combinators are distributed over benchmark applications, so far? The following image illustrates the occurrence of each combinator type (1 - 64) over a few programs. SK-combinators are shown separately, as a way to compare with traditional abstraction algorithms.
TODO
As more programs are included in the current test list, we expect to fill more of the gaps of the distribution above. However, this is not guaranteed. Our observation is that most Haskell benchmarks from nofib end up using similar data structures and recursion patterns. The result is that these programs tend to cluster around a few reduction patterns, as shown in the figure.