-
Notifications
You must be signed in to change notification settings - Fork 496
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
deprecate existing weight APIs #111
Comments
As a quick test I took a work project and cargo updated to 0.4.3. With |
@Eh2406 can you characterize the workload somehow? Is the work well balanced for each item, or skewed heavily? Maybe you can synthesize something that performs similarly? For possible tunables related to length, I think we'll want both a minimum (don't bother splitting below this length) and a maximum (always split at least down to this length), where |
so I am running on a stage 2 is 1-2s either way. much of which is the linear overhead before the into_par_it and if I replace into_par_iter with into_iter: 69s, 69s, 72s. so rayon is giving me a 2x improvement in speed, good for a 2 core machine. Is there a programmatic way to determine the number of cores as opposed to the number of logical processors? Don't know why all stages together are faster than just the first stage. But It looks like without |
I really dislike the However, I'd like to retain some control, how the work is split. So I'd propose to simply introduce an optional way, to specify the number of threads used. Something like It is minimally intrusive, but offers precise manual control, if needed. EDIT: Just saw, this was considered through |
I think @cuviper has some thoughts here and wanted to take a crack at this. I'm going to assign to them and remove the Help-Wanted label for now. |
Per this comment, we should deprecate the existing weight APIs. I think we probably still want some room for manual tuning, but it should be simpler by default -- and if we are going to let people give fine-grained numbers, it should be tied to the length (like seq. cutoff) rather than some abstract notion of weight. Ideally though we'd add these APIs along with representative benchmarks where they are needed.
The text was updated successfully, but these errors were encountered: