Adding DList, Acc & snoc benchmarks - #23
Merged
chrisdone merged 3 commits intoNov 22, 2021
Merged
Conversation
Where DList does not provided the operation (& so implicitly required to convert
toList and back - those tests would give wrong impression that DList structure
has these types of operation), but DList so far does not have idiomatic indexing
or sort.
DList append is lazy, as DList append efficiency is
based on GHC laziness.
For example:
For strict DList `append` results would be:
benchmarking Append/Data.List:10000
time 137.8 μs (134.8 μs .. 141.1 μs)
0.997 R² (0.995 R² .. 0.999 R²)
mean 137.7 μs (136.1 μs .. 139.6 μs)
std dev 6.051 μs (4.767 μs .. 7.889 μs)
variance introduced by outliers: 44% (moderately inflated)
benchmarking Append/Data.DList:10000
time 125.7 μs (124.3 μs .. 127.3 μs)
0.999 R² (0.998 R² .. 0.999 R²)
mean 128.0 μs (126.5 μs .. 130.3 μs)
std dev 6.144 μs (4.477 μs .. 9.412 μs)
variance introduced by outliers: 49% (moderately inflated)
benchmarking Append/Data.Sequence:10000
time 261.2 ns (258.4 ns .. 264.8 ns)
0.999 R² (0.998 R² .. 0.999 R²)
mean 266.4 ns (263.5 ns .. 270.5 ns)
std dev 11.97 ns (9.705 ns .. 16.21 ns)
variance introduced by outliers: 64% (severely inflated)
-- Which is redicilous, as List `(++)` does traversal for every append, & DList
that should be the O(1) star in operation only a tidbit faster.
When Seq append is: O(log(min(n1,n2)))
And DList append is: O(1)
DList should be around or faster in `append` then Seq.
So for benchmarks to show DList `append` optimization - append should be lazy:
```
benchmarking Append/Data.List:10000
time 145.3 μs (144.1 μs .. 146.7 μs)
0.998 R² (0.995 R² .. 0.999 R²)
mean 151.7 μs (148.1 μs .. 158.4 μs)
std dev 17.26 μs (9.959 μs .. 27.60 μs)
variance introduced by outliers: 85% (severely inflated)
benchmarking Append/Data.DList:10000
time 12.33 ns (12.18 ns .. 12.45 ns)
0.999 R² (0.999 R² .. 0.999 R²)
mean 12.35 ns (12.21 ns .. 12.54 ns)
std dev 553.6 ps (423.6 ps .. 800.3 ps)
variance introduced by outliers: 69% (severely inflated)
benchmarking Append/Data.Vector:10000
time 17.98 μs (17.79 μs .. 18.19 μs)
0.999 R² (0.998 R² .. 0.999 R²)
mean 17.91 μs (17.73 μs .. 18.12 μs)
std dev 658.2 ns (522.5 ns .. 880.2 ns)
variance introduced by outliers: 43% (moderately inflated)
benchmarking Append/Data.Vector.Unboxed:10000
time 5.341 μs (5.315 μs .. 5.371 μs)
0.999 R² (0.999 R² .. 1.000 R²)
mean 5.377 μs (5.327 μs .. 5.506 μs)
std dev 248.3 ns (127.8 ns .. 460.3 ns)
variance introduced by outliers: 58% (severely inflated)
benchmarking Append/Data.Vector.Storable:10000
time 5.585 μs (5.424 μs .. 5.711 μs)
0.997 R² (0.997 R² .. 0.999 R²)
mean 5.473 μs (5.414 μs .. 5.554 μs)
std dev 231.5 ns (190.7 ns .. 287.6 ns)
variance introduced by outliers: 54% (severely inflated)
benchmarking Append/Data.Sequence:10000
time 281.7 ns (278.1 ns .. 284.1 ns)
0.999 R² (0.999 R² .. 0.999 R²)
mean 279.5 ns (276.9 ns .. 283.0 ns)
std dev 10.04 ns (7.474 ns .. 14.37 ns)
variance introduced by outliers: 53% (severely inflated)
```
Now results look normal, [] is horrible in append, Vector still known to be quite
"bad" with appends - but miles better then [], Seq is second best with
logarithmic append & DList has O(1).
DList shines in `append`, but quite horrible, sometimes even more then `[]` in
other tests, which is quiting for DList strength & weaknesses.
I know Nikita Volkov as a Haskeller with a lot of smart logical solutions to probems. Acc is a tree-like structure which tree balances to the operation applied, so when a lot of same operations applied to the structure - data tree is kept optimized for that operation. It is designed to be a builder-phase data type. Therefore it lacks a lot of abilities. Upstream thread with the author is: nikita-volkov/acc#1
With datatypes that do efficient snocing - it is often easier to reason about & build algorithms on, as data structure becomes FIFO. As for example accumulator would add to the tail & then traversing the data structure alalizing elements from old to new, which is easy to align with laziness. DList & Acc also shine in snocing, that is also a main point to add snocing.
This was referenced Nov 22, 2021
Closed
Member
|
Thanks, I re-ran the results, will update the readme! |
Contributor
Author
|
Thanks. I've notified the authors. Wanted to check things with the authors that I did everything right & maybe they would give/have additional ideas. |
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #21, #22.
According information is put in according commit messages.
Current results are:
Results 👆
My laptop still can be considered pretty powerful, if needed - I can load into a clean environment & send clean benchmark update.