[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Applying the optimization options #3982

Merged
merged 2 commits into from
Apr 13, 2024
Merged

Applying the optimization options #3982

merged 2 commits into from
Apr 13, 2024

Conversation

kozistr
Copy link
Contributor
@kozistr kozistr commented Apr 6, 2024

All Submissions:

  • Contributions should target the dev branch. Did you create your branch from dev?
  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Change Logs

I made changes to the optimization option for release.

  • using a single codegen-unit

@generall
Copy link
Member
generall commented Apr 6, 2024

Hey @kozistr, could you please explain why setting those options explicitly is required? AFAIK, most of them are already used by default.

@kozistr
Copy link
Contributor Author
kozistr commented Apr 7, 2024

Hey @kozistr, could you please explain why setting those options explicitly is required? AFAIK, most of them are already used by default.

you're right. most of them are already used by default except codegen-units. I just initially thought applying those options explicitly would be good, but never mind. I'll remove them!

changed fce1e2b

@generall
Copy link
Member
generall commented Apr 8, 2024

Still, could you please provide some explanation why we would want codegen-unit and what are the possible cons

@kozistr
Copy link
Contributor Author
kozistr commented Apr 8, 2024

Still, could you please provide some explanation why we would want codegen-unit and what are the possible cons

sure! AFAIK, setting codegen-units to 1 could bring the performance gain or reduce the binary size although taking a longer compilation time (followed by here). I guess it might help to boost the Qdrant performance.

Maybe, if you've already considered this option and thought it wasn't suitable for the Qdrant project, please let me know. (I didn't run lots of tests, or know how codegen-units works deeply, so i might be wrong)

@generall
Copy link
Member
generall commented Apr 8, 2024

It would be nice to have some benchmarks for this..

More specifically, run some searches using https://github.com/qdrant/bfb

/bounty $50

Copy link
algora-pbc bot commented Apr 8, 2024

💎 $50 bounty • Qdrant

💎 $50 bounty • Qdrant

Steps to solve:

  1. Start working: Comment /attempt #3982 with your implementation plan
  2. Submit work: Create a pull request including /claim #3982 in the PR body to claim the bounty
  3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to qdrant/qdrant!

Add a bountyShare on socials

Attempt Started (GMT+0) Review
🟢 @adityajideveloper #1993238306
🟢 @kozistr #3982

@timvisee
Copy link
Member
timvisee commented Apr 10, 2024

Reducing code-gen units to 1 does indeed open the door for more performance optimizations. The problem is that it'll make building extremely slow. Qdrant builds already take a significant amount of time, and I don't think we want to see that as side effect.

@generall
Copy link
Member

The problem is that it'll make building extremely slow.

How extremely? If we need to build it once per release, it is not that bad

@kozistr
Copy link
Contributor Author
kozistr commented Apr 10, 2024

The problem is that it'll make building extremely slow.

How extremely? If we need to build it once per release, it is not that bad

I just ran a docker building on my local machine (i7-7700K CPU, on WSL2, based on main branch),

  • command line: docker build -f Dockerfile . --no-cache
config time size
w/o codegen-units=1 900 secs 162 MB
w/ codegen-units=1 1000 secs 153 MB

% time could be differed on the Github action host

Copy link
@AS1100K AS1100K left a comment

Choose a reason for hiding this comment

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

Adding codegen-units = 1 definitely will increase the performance but it comes with a cost of compile time.

For release profile this extra time is indeed not a big deal as it's not build frequently.

Compile time can also be reduced by modifying the value of codegen-units, but according to me for this codebase codegen-units = 1 is just fine and is balanced between performance and compile time.

/claim #3982

@timvisee
Copy link
Member
timvisee commented Apr 11, 2024

On my machine I'm seeing compilation times of 414 seconds versus 519 with a single codegen unit. It's less of a difference than I had anticipated.

@AS1100K
Copy link
AS1100K commented Apr 11, 2024

That's a good point about compile times varying based on system resources. It's possible GitHub Actions might have a larger difference due to their build environment.

Using codegen-units=1 can improve performance, and small optimizations can add up. Here's something else to consider for future optimizations: exploring potential improvements to multi-threading.

@generall
Copy link
Member

/claim #3982

I am mostly interested in search perf benchmarks

@kozistr
Copy link
Contributor Author
kozistr commented Apr 13, 2024

/claim #3982

I am mostly interested in search perf benchmarks

I ran some benchmarks with the bfb, hash 8ecc126

  • Environment

    • OS: Windows 10 (WSL 2)
    • CPU: i7-7700K
    • Disk: Samsung SSD 970 EVO Plus 1TB
    • RAM: DDR4 48GB
  • treatment: Qdrant 1.8.4

  • experimental: Qdrant 1.8.4 with codegen-units = 1

building index

  • command line: docker run -it --rm --network host bfb ./bfb --dim 1024
    • dimension : 1024
group times
treatment 85.193107507 seconds
experimental 76.164150314 seconds

Search

  • Distance: Dot

  • on-disk: (payload, index, vectors)

  • command line : docker run -it --rm --network host bfb ./bfb --dim 1024 --search --distance Dot --on-disk-payload --on-disk-index true --on-disk-vectors true

    • Dimension: 1024
    • Distance: Dot
    • on-disk: (payload, index, vectors)
    • The reason that I set it up like this is because it's similar to my production environment (on-disk & 1024 dims).

Search timings

group min avg median p95 p99 max
treatment 0.005384548 0.009714346868400054 0.009783974 0.01135127 0.012353613 0.019784106
experimental 0.00537742 0.009676725693100133 0.009701624 0.011258946 0.012252325 0.019721841

Server timings

group min avg median p95 p99 max
treatment 0.004888853 0.008754061682599942 0.008803368 0.010377731 0.011456847 0.019127279
experimental 0.00486561 0.008729234132379823 0.008736518 0.01030292 0.011354128 0.018932535

RPS

group min avg median max
treatment 201.41468678122897 203.95397667696304 204.1001233179035 327.0230449873457
experimental 202.41011500729388 204.7785899851906 204.85674918334945 348.1159128477496

Although there are many configs to test and the result depends on the environment, it seems that codegen-units = 1 gives a slightly better result in my experiments.

I'll do more tests if I'm available.

@generall
Copy link
Member

/tip $50 @kozistr

Copy link
algora-pbc bot commented Apr 13, 2024

Copy link
algora-pbc bot commented Apr 13, 2024

@kozistr: You just got a $50 tip! 👉 Complete your Algora onboarding to collect your payment.

@generall generall merged commit a5ec30f into qdrant:dev Apr 13, 2024
17 checks passed
timvisee pushed a commit that referenced this pull request Apr 22, 2024
* build(config): update profile.release

* build(config): update profile.release
Copy link
algora-pbc bot commented Jul 13, 2024

🎉🎈 @kozistr has been awarded $50! 🎈🎊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants