Skip to content

Conversation

@andygrove
Copy link
Member

@andygrove andygrove commented Nov 21, 2023

Which issue does this PR close?

Related to discussion in #7001

Rationale for this change

By default, the benchmarks have been running with two partitions (i.e., concurrency of two), which is unrealistic given the number of cores on modern laptops. This PR defaults to num cores instead. We can still override this and explicitly set the number of partitions.

This is the difference this makes for me (Threadripper with 24 cores).

┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Query        ┃      main ┃ bench-default-partitions ┃        Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ QQuery 1     │  655.23ms │                 283.37ms │ +2.31x faster │
│ QQuery 2     │  148.53ms │                 160.08ms │  1.08x slower │
│ QQuery 3     │  277.50ms │                 215.95ms │ +1.28x faster │
│ QQuery 4     │  166.20ms │                 131.36ms │ +1.27x faster │
│ QQuery 5     │  334.64ms │                 248.19ms │ +1.35x faster │
│ QQuery 6     │  144.79ms │                  97.53ms │ +1.48x faster │
│ QQuery 7     │  718.12ms │                 367.63ms │ +1.95x faster │
│ QQuery 8     │  385.01ms │                 293.77ms │ +1.31x faster │
│ QQuery 9     │  571.56ms │                 387.59ms │ +1.47x faster │
│ QQuery 10    │  459.09ms │                 388.16ms │ +1.18x faster │
│ QQuery 11    │  143.07ms │                 119.23ms │ +1.20x faster │
│ QQuery 12    │  257.05ms │                 244.25ms │     no change │
│ QQuery 13    │  447.24ms │                 385.33ms │ +1.16x faster │
│ QQuery 14    │  233.90ms │                 126.45ms │ +1.85x faster │
│ QQuery 15    │  192.98ms │                 143.86ms │ +1.34x faster │
│ QQuery 16    │  163.44ms │                 176.92ms │  1.08x slower │
│ QQuery 17    │  335.34ms │                 230.92ms │ +1.45x faster │
│ QQuery 18    │ 1188.63ms │                 678.13ms │ +1.75x faster │
│ QQuery 19    │  360.65ms │                 193.74ms │ +1.86x faster │
│ QQuery 20    │  356.26ms │                 168.59ms │ +2.11x faster │
│ QQuery 21    │  825.86ms │                 491.50ms │ +1.68x faster │
│ QQuery 22    │  163.89ms │                 201.47ms │  1.23x slower │
└──────────────┴───────────┴──────────────────────────┴───────────────┘

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

No

@andygrove andygrove requested a review from Dandandan November 21, 2023 14:38
@alamb
Copy link
Contributor

alamb commented Nov 21, 2023

We are going to need some bigger benchmarks :) -- by the time the queries are in the 250ms range, there is a lot of noise with whatever else is going on in the system :)

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thanks @andygrove

for i in 0..self.common.iterations {
let config =
SessionConfig::new().with_target_partitions(self.common.partitions);
let config = SessionConfig::new().with_target_partitions(
Copy link
Contributor

Choose a reason for hiding this comment

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

I think SessionConfig already defaults to the number of CPUs, so we can probably just avoid setting this at all if self.common.partitions.is_none()

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.

4 participants