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

Optimize for requesting 1 device #18

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

kerthcet
Copy link
Contributor

@kerthcet kerthcet commented Dec 6, 2023

What I mainly do in the PR:

  • Optimize for the case when we required is actually the size.
  • Optimize for the case when size == 1, We'll pick the device with the minimum sum of scores with available devices.

Signed-off-by: kerthcet <[email protected]>
1. The required device number is equal to the size
2. Require 1 GPU, in this case, 	we will pick the device with the minimum sum of scores with available devices.

Signed-off-by: kerthcet <[email protected]>
}

// Optimize for the case when size == 1.
// We'll pick the device with the minimum sum of scores with available devices.
Copy link
Contributor Author

@kerthcet kerthcet Dec 6, 2023

Choose a reason for hiding this comment

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

We can discuss here, from my POV, since 1 device no longer needs the communication with other GPUs, so the lower score the better.

Copy link
Member

Choose a reason for hiding this comment

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

For requests with 1 device is the choice not irrellevant from the perspective of the application requesting the device? It may be that assigning the device with the lowest connectivity in this case provides some advantage since other more connected devices are available for future requests that require multple devices.

Do you have benchmarks to show whether this change improves performance at all?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It may be that assigning the device with the lowest connectivity in this case provides some advantage since other more connected devices are available for future requests that require multple devices.

Yes, exactly the case, benefit to the future request for multi-devices.

I have no benchmark yet, but I can provide one if needed, generally, this is not quite aimed for the performance but for the application friendly and rational utilization as you described above.

@kerthcet kerthcet changed the title Optimize for requesting 1 devices Optimize for requesting 1 device Dec 6, 2023
@kerthcet
Copy link
Contributor Author

kerthcet commented Dec 8, 2023

cc @elezar

Copy link
Member

@elezar elezar left a comment

Choose a reason for hiding this comment

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

Thanks @kerthcet.

I think the first two commits look good. Let's pull these into a separate PR.

With regards to the optimizations, I will have to look at this more closely.

gpuallocator/besteffort_test.go Show resolved Hide resolved
}

// Optimize for the case when size == 1.
// We'll pick the device with the minimum sum of scores with available devices.
Copy link
Member

Choose a reason for hiding this comment

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

For requests with 1 device is the choice not irrellevant from the perspective of the application requesting the device? It may be that assigning the device with the lowest connectivity in this case provides some advantage since other more connected devices are available for future requests that require multple devices.

Do you have benchmarks to show whether this change improves performance at all?

Signed-off-by: kerthcet <[email protected]>
@elezar elezar assigned elezar and unassigned kerthcet Jan 27, 2024
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