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

multithreading control? #31

Closed
odunbar opened this issue Feb 9, 2023 · 1 comment · Fixed by #43
Closed

multithreading control? #31

odunbar opened this issue Feb 9, 2023 · 1 comment · Fixed by #43

Comments

@odunbar
Copy link
Collaborator

odunbar commented Feb 9, 2023

Tullio will perform hyperthreading by blocking matrices. It prefers to calculate how many threads would be worthwhile at the time, somewhat unclear if it can be overriden, though this comment implies a KW argument threads=n will do it
https://github.com/mcabbott/Tullio.jl/blob/78cd6b18d2c5a77acf9051746432869ad5514fee/src/threads.jl#L11-L22

We may wish to control this value, so that other operations might also be threaded on top of this

@odunbar odunbar changed the title Hyperthreading control? multithreading control? Feb 9, 2023
@odunbar
Copy link
Collaborator Author

odunbar commented Apr 19, 2023

I think the easiest option would be to add just false or to use Tullio's option. i.e. to RandomFeatureMethod add atullio_threading::Bool kw argument and @tullio threads=tullio_threading flag

Note-to-self. I have noticed that Tullio's speed up for e.g. A^T*A bottleneck is only around 2-3x for upto 56 threads (increases until around 8 threads before plateauing), likewise with prediction. This indicates that for likely problems it will be typically better to thread outside of the RF code.

@odunbar odunbar mentioned this issue Apr 20, 2023
1 task
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 a pull request may close this issue.

1 participant