bootandy/archived-dust
1
0
Fork 0
mirror of https://github.com/bootandy/dust.git synced 2026-06-08 11:29:05 +03:00
Code Issues 21 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #387] Parallelisation seems excessive #172

New Issue
Closed
opened 2026-06-08 11:25:59 +03:00 by zhus · 2 comments
zhus commented 2026-06-08 11:25:59 +03:00
Owner
Copy Link
Copy Source

Originally created by @Debilski on GitHub (Apr 22, 2024).
Original GitHub issue: https://github.com/bootandy/dust/issues/387

I ran dust on a server with >40 cores and htop was basically going all red from system call CPU usage. Is it possible to have a lower default on the number of threads that dust uses per default? I have my doubts that it makes much of a difference after a certain threshold.

I am aware that I can set RAYON_NUM_THREADS=1 on the command line but since this is a shared system the majority of users won’t know about this setting.

Originally created by @Debilski on GitHub (Apr 22, 2024). Original GitHub issue: https://github.com/bootandy/dust/issues/387 I ran dust on a server with >40 cores and htop was basically going all red from system call CPU usage. Is it possible to have a lower default on the number of threads that dust uses per default? I have my doubts that it makes much of a difference after a certain threshold. I am aware that I can set `RAYON_NUM_THREADS=1` on the command line but since this is a shared system the majority of users won’t know about this setting.
zhus closed this issue 2026-06-08 11:25:59 +03:00
zhus commented 2026-06-08 11:25:59 +03:00
Author
Owner
Copy Link
Copy Source

@Dj-Codeman commented on GitHub (Apr 23, 2024):

I agree that a way to limit threads better than Rayon_whatever is needed but I think the default behavior is okay. Going back and forth from my Hpe server with Tb's of data and my laptop tweaking the default thread pool would hinder at least one of those use cases. I suggest #388, it just adds a -T flag to allow us to specify however many threads we want.

<!-- gh-comment-id:2071285736 --> @Dj-Codeman commented on GitHub (Apr 23, 2024): I agree that a way to limit threads better than `Rayon_whatever` is needed but I think the default behavior is okay. Going back and forth from my Hpe server with Tb's of data and my laptop tweaking the default thread pool would hinder at least one of those use cases. I suggest #388, it just adds a `-T` flag to allow us to specify however many threads we want.
zhus commented 2026-06-08 11:25:59 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (May 6, 2024):

https://github.com/bootandy/dust/pull/395
will go out in next release. thanks @Dj-Codeman

<!-- gh-comment-id:2096750462 --> @bootandy commented on GitHub (May 6, 2024): https://github.com/bootandy/dust/pull/395 will go out in next release. thanks @Dj-Codeman
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
 windows help wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zhus (Sergey Zhukov)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bootandy/archived-dust#172
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?