Mac affinity #2
Mac affinity #2
Conversation
|
Oh bugger I've got to change the makefile too. My actual makefile for test uses dynamic versions of libraries to get it to build, so I gotta isolate the changes from what's actually needed here. |
Compiles, builds, runs correctly. Done!
|
As mentioned in #1, this is just a mirror of the Prime95 source code, so I would recommend emailing George your patch or posting it on the Mersenne forum. |
|
@gwoltman sent a reply to this PR at shafferjohn/Prime95#2 (comment) but it's misplaced, so I'm bringing the thread back here.
We go behind hwloc's back and use our own thing. Hence the change in common.c for The Affinity API is present on all Intel macOS 10.5+, which is a superset of what mprime can run on. In other words no more test is required, we can always set |
|
(I would normally make this a comment-edit append to save screen space, but since George is mostly using email, I figured that added things should be their own messages). I've thought about patching hwloc itself to provide this functionality, but there is a significant mismatch between what hwloc thinks (cpu sets) and what the kernel API exposes (core-sharing tags) [the kernel internally uses CPU sets but does not expose them, just Apple messing with ya!]. It would be possible to provide an implementation that checks whether the cpuset only spans one physical core and act accordingly, but the bitwise operations involved is giving me a headache. For now let's use the more obvious encapsulation: just tags as "virtual core number". (I've said before on mersenneforum that there is a one-to-one tag-core relationship as long as the number of tags do not exceed the number of cores.) It's closer to what we intend anyways: run on core number X. |
|
I've changed commonb.c as follows:
/* Skip setting affinity if OS does not support it. At present time, that
is Apple. 2025-11-10: John Shaffer provided a way for Apple to set
affinity. */
#ifndef __APPLE__
if (!OS_CAN_SET_AFFINITY) return;
#endif
…On Mon, Nov 10, 2025 at 3:55 AM Mingye Wang ***@***.***> wrote:
*Artoria2e5* left a comment (primesearch/Prime95#2)
<#2 (comment)>
(I would normally make this a comment-edit append to save screen space,
but since George is mostly using email, I figured that added things should
be their own messages).
I've thought about patching hwloc itself to provide this functionality,
but there is a significant mismatch between what hwloc thinks (cpu sets)
and what the kernel API exposes (core-sharing tags) [the kernel internally
uses CPU sets but does not expose them, just Apple messing with ya!]. It
would be possible to provide an implementation that checks whether the
cpuset only spans one physical core and act accordingly, but the bitwise
operations involved is giving me a headache.
For now let's use the more obvious encapsulation: just tags as "virtual
core number". (I've said before on mersenneforum that there is a one-to-one
tag-core relationship as long as the number of tags do not exceed the
number of cores.) It's closer to what we intend anyways: run on core number
X.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFJ4KM5DCHEZAYJTOKAXOAD34BHJNAVCNFSM6AAAAACLSD7BICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJQGI3TIOBVGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
That works too if you're not so keen on changing commonc.c to bypass the setting of OS_CAN_SET_AFFINITY. George, I really do recommend that you use the webpage and view the actual, whole patch. Alternatively you can use "curl https://github.com/primesearch/Prime95/pull/2.patch" for a plaintext version. PS: I'm Mingye Wang, not John Staffer! It's just that I sent the initial patch to John Staffer instead of here. |
|
Hi Mingye,
Sorry, I missed that part of the patch.
Regards,
George
…On Mon, Nov 10, 2025 at 6:53 PM Mingye Wang ***@***.***> wrote:
*Artoria2e5* left a comment (primesearch/Prime95#2)
<#2 (comment)>
That works too if you're not so keen on changing commonc.c to bypass the
setting of OS_CAN_SET_AFFINITY. George, I really do recommend that you use
the webpage and view the actual, whole patch. Alternatively you can use
"curl https://github.com/primesearch/Prime95/pull/2.patch" for a
plaintext version.
PS: I'm Mingye Wang, not John Staffer! It's just that I sent the initial
patch to John Staffer instead of here.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFJ4KM2M3RK3OKOI4QDCV5334EQPJAVCNFSM6AAAAACLSD7BICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJUGM4DMMBQGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi Mingye,
I'm having trouble compiling on my 2017 MacOSS Monterey. Any thoughts?
MACOSX_DEPLOYMENT_TARGET=10.9 gcc -I.. -I../gwnum -I../linux -std=gnu99 -O2
-DX86_64 -DCOMMAND_LINE_MPRIME -m64 -DPORT=10 -c prime.c
In file included from prime.c:601:
In file included from ./os_routines.c:519:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/thread_act.h:13:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/mig_errors.h:66:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/mig.h:126:2:
error: unknown type name 'vm_address_t'; did you mean
'vm_map_address_t'?
vm_address_t reserved; /* reserved for MIG
use */
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/i386/vm_types.h:129:33:
note: 'vm_map_address_t' declared here
typedef uint64_t vm_map_address_t;
^
In file included from prime.c:601:
In file included from ./os_routines.c:519:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/thread_act.h:13:
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/mig_errors.h:66:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/mig.h:172:26:
error: unknown type name 'vm_address_t'; did you mean
'vm_map_address_t'?
extern void mig_allocate(vm_address_t *, vm_size_t);
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/mach/i386/vm_types.h:129:33:
note: 'vm_map_address_t' declared here
typedef uint64_t vm_map_address_t;
^
…On Mon, Nov 10, 2025 at 9:07 PM George Woltman ***@***.***> wrote:
Hi Mingye,
Sorry, I missed that part of the patch.
Regards,
George
On Mon, Nov 10, 2025 at 6:53 PM Mingye Wang ***@***.***>
wrote:
> *Artoria2e5* left a comment (primesearch/Prime95#2)
> <#2 (comment)>
>
> That works too if you're not so keen on changing commonc.c to bypass the
> setting of OS_CAN_SET_AFFINITY. George, I really do recommend that you use
> the webpage and view the actual, whole patch. Alternatively you can use
> "curl https://github.com/primesearch/Prime95/pull/2.patch" for a
> plaintext version.
>
> PS: I'm Mingye Wang, not John Staffer! It's just that I sent the initial
> patch to John Staffer instead of here.
>
> —
> Reply to this email directly, view it on GitHub
> <#2 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AFJ4KM2M3RK3OKOI4QDCV5334EQPJAVCNFSM6AAAAACLSD7BICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJUGM4DMMBQGE>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
George, The errors appear to be from the kern headers I'm including, but not the particular parts that I'm using. I happen to also have a (slow) machine stuck on Montgomery with XCode 16 being the latest available official toolchain, so I'll try and see what can be done. Perhaps I just need to include some more useless headers. |
|
Correction. XCode 16 corresponds to a much newer version than Monterey (I can't get the name right), but I can always fish out an older SDK version from third-party places like https://github.com/joseluisq/macosx-sdks and make sure it builds. Non-email append. 10.9 SDK compiles fine, suspecting a version in between. For now my "guess" for a solution is |
|
I'm afraid the current version in main (p95v3101b1) includes a typo: pthread_t should be thread_t. I also revised the placement of the mac branch in commonb.c in this version, added a bit to commonc.c (as we've discussed before), and added two include directives to aff.c (you do seem to have that version as indicated by the error). I recommend rolling back the changes and re-applying this version. In the meantime I am still yet to reproduce the compilation error. For now my suggestion is: try adding |
|
Hi Mingye,
I'd already repaired the typos. Good news: Including mach/vm_types.h
solved my issues building on Monterey. I'll upload v31.1 today for you to
test.
…On Wed, Nov 12, 2025 at 11:24 AM Mingye Wang ***@***.***> wrote:
*Artoria2e5* left a comment (primesearch/Prime95#2)
<#2 (comment)>
I'm afraid the current version in main (p95v3101b1) includes a typo:
pthread_t should be thread_t. I also revised the placement of the mac
branch in commonb.c in this version, added a bit to commonc.c (as we've
discussed before), and added two include directives to aff.c (you do seem
to have that version as indicated by the error). I recommend rolling back
the changes and re-applying this version.
In the meantime I am still yet to reproduce the compilation error. For now
my suggestion is: try adding #include <mach/vm_types.h> before the thread
includes.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFJ4KM7QY42JIZTDRGK53TL34NNL3AVCNFSM6AAAAACLSD7BICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMRSGUYDSNZQGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
3 participants
This is the same as shafferjohn/Prime95#3, except that I've tested the code this time. It compiles and appears to work as intended in a very short test (does not print "does not support", actually calls the set-function).