-
Notifications
You must be signed in to change notification settings - Fork 11.6k
ggml-threading.cpp #7576
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
base: master
Are you sure you want to change the base?
ggml-threading.cpp #7576
Conversation
I'll need to update for #7598 |
extern void atomic_store(atomic_int* ptr, LONG val); | ||
extern LONG atomic_load(atomic_int* ptr); | ||
extern LONG atomic_fetch_add(atomic_int* ptr, LONG inc); | ||
extern LONG atomic_fetch_sub(atomic_int* ptr, LONG dec); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is very important that these functions are inlined, so they cannot be made extern
. Additionally, we cannot export symbols with these names, because they are very likely to create conflicts. Same with the pthread and sched_yield stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Valid points.
That's the exact kind of feedback I was looking for. Thanks.
extern void set_numa_thread_affinity(int thread_n); | ||
extern void clear_numa_thread_affinity(void); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same issue here, we cannot export functions with these names. At least they need a ggml_
prefix.
Move all the threading related stuff to it's own file as discussed in the text of #6915
I picked cpp because I was thinking we'd use std::thread so we won't have to maintain two implementations of the thread operations. It'll also let us use std::mutex and std::atomic, and those primitives will likely be faster than our own implementations. However, this would just be the leading structural change. My goal with this PR is to not make any functional changes, and then we can do separate tests of the actual functional changes.
@slaren @ggerganov Do you think I'm headed in the right direction with the structural changes? I still need to do some more testing and self-reviews and I've only tested this really in windows so far, but I want to make sure I'm not headed in the wrong direction.