Skip to content

Add k-way merge and heapsort benchmarks#65

Merged
konsumlamm merged 1 commit intolspitzner:masterfrom
treeowl:k-way
Dec 18, 2021
Merged

Add k-way merge and heapsort benchmarks#65
konsumlamm merged 1 commit intolspitzner:masterfrom
treeowl:k-way

Conversation

@treeowl
Copy link
Copy Markdown
Collaborator

@treeowl treeowl commented Dec 16, 2021

Better to have some benchmarks than none.

@treeowl
Copy link
Copy Markdown
Collaborator Author

treeowl commented Dec 16, 2021

A couple results so far:

  1. Improve worst-case bounds #26 improved all the results, some of them considerably.
  2. If we arrange for specialization to the Ord instance, we can win maybe 20%.

@treeowl treeowl force-pushed the k-way branch 2 times, most recently from bb02e01 to 48e146c Compare December 17, 2021 19:24
@treeowl treeowl changed the title Add k-way merge benchmarks Add k-way merge and heapsort benchmarks Dec 17, 2021
@treeowl
Copy link
Copy Markdown
Collaborator Author

treeowl commented Dec 17, 2021

@konsumlamm Do you have any objections to adding these few benchmarks, or can I just go ahead?

@treeowl treeowl marked this pull request as draft December 17, 2021 20:13
@treeowl
Copy link
Copy Markdown
Collaborator Author

treeowl commented Dec 17, 2021

Wow, I just realized I did the k-way merge benchmark all wrong. I'll get that fixed!

Copy link
Copy Markdown
Collaborator

@konsumlamm konsumlamm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have absolutely no objections to adding a few benchmarks, but some style nitpicks.

Comment thread benchmarks/HeapSort.hs
Comment thread benchmarks/HeapSort.hs Outdated
Comment thread pqueue.cabal Outdated
Comment thread benchmarks/PHeapSort.hs
heapSortRandoms n gen = heapSort $ take n (randoms gen)

heapSort :: Ord a => [a] -> [a]
heapSort xs = [b | (b, ~()) <- P.toAscList . P.fromList . map (\a -> (a, ())) $ xs]
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why use a list comprehension here instead of another map?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it shouldn't matter, because an outer map should fuse with toAscList (I think the latter has a rewrite rule) and avoid producing thunks to select the first components. But if that doesn't happen, things won't look great because rnf for lists doesn't fuse (maybe the assumption is that if you rnf something then you'll use it again, but that's not a great assumption).

Comment thread benchmarks/PHeapSort.hs
Comment thread benchmarks/KWay/MergeAlg.hs
Comment thread benchmarks/BenchMinPQueue.hs Outdated
Comment thread benchmarks/BenchMinQueue.hs Outdated
@treeowl
Copy link
Copy Markdown
Collaborator Author

treeowl commented Dec 18, 2021

OK, it should make a lot more sense now. Previously I was trying to merge unsorted streams, which was totally wrong and may well explain why the bare queues were performing worse than the augmented ones. Now the streams are sorted.

@treeowl
Copy link
Copy Markdown
Collaborator Author

treeowl commented Dec 18, 2021

I'm struggling to get the time it takes to run the benchmarks down to something reasonable. I tried setting a time limit, but Gauge blew right past it by an order of magnitude. Clearly I'm doing something wrong. Is there some number of evaluations per sample I need to tweak somehow? I don't think we should delay merging to fix this, but we should get to it at some point.

Copy link
Copy Markdown
Collaborator

@konsumlamm konsumlamm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The time limit seems to work for me, any benchmark specifically that "blew right past it by an order of magnitude"?

We should consider using tasty-bench instead of gauge, it's a lot faster (and much lighter on dependencies), it wouldn't even require a time limit, although sometimes kWay (10^3) 1000000 seems to get stuck, maybe we should just remove that bench. Also, tasty-bench is much more actively maintained.

Comment thread benchmarks/BenchMinPQueue.hs Outdated
Comment thread pqueue.cabal Outdated
Comment thread benchmarks/KWay/RandomIncreasing.hs
Comment thread benchmarks/KWay/RandomIncreasing.hs Outdated
Better to have some benchmarks than none.
@treeowl
Copy link
Copy Markdown
Collaborator Author

treeowl commented Dec 18, 2021

The time limit seems to work for me, any benchmark specifically that "blew right past it by an order of magnitude"?

We should consider using tasty-bench instead of gauge, it's a lot faster (and much lighter on dependencies), it wouldn't even require a time limit, although sometimes kWay (10^3) 1000000 seems to get stuck, maybe we should just remove that bench. Also, tasty-bench is much more actively maintained.

I ran into trouble when I added heapsort benchmarks for longer lists. 10^6 elements was unbearably slow. I don't think I ever got 10^7 to finish benchmarking. I don't really care what benchmarking framework we use, as long as it's reliable. Should we merge this, and then let you replace it with tasty? I don't know how to set that up.

Copy link
Copy Markdown
Collaborator

@konsumlamm konsumlamm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really care what benchmarking framework we use, as long as it's reliable. Should we merge this, and then let you replace it with tasty? I don't know how to set that up.

Ok (it's really straightforward).

@konsumlamm konsumlamm merged commit e12822a into lspitzner:master Dec 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants