mersenneforum.org The correct way for MacOS users to check for CPU instruction sets
 Register FAQ Search Today's Posts Mark Forums Read

2020-10-25, 15:45   #1
Artoria2e5

Oct 2020

1 Posts
The correct way for MacOS users to check for CPU instruction sets

The current README has this to say about determining the SIMD build mode on Macs:

Quote:
 Mac OS X has no /proc/cpuinfo file, so Mac users will need to [Apple Icon] → About This Mac, then compare the processor type displayed in the resulting dialog box against the following Wikipedia entries:
This actually does not work at all since Apple now only tells you it's a "6-core Intel i7 CPU". The correct way to do it, which does not involve wikipedia, is by querying
one of the following on the terminal:

Code:
$sysctl hw.optional hw.optional.floatingpoint: 1 hw.optional.mmx: 1 hw.optional.sse: 1 hw.optional.sse2: 1 hw.optional.sse3: 1 hw.optional.supplementalsse3: 1 hw.optional.sse4_1: 1 hw.optional.sse4_2: 1 hw.optional.x86_64: 1 hw.optional.aes: 1 hw.optional.avx1_0: 1 hw.optional.rdrand: 1 hw.optional.f16c: 1 hw.optional.enfstrg: 1 hw.optional.fma: 1 hw.optional.avx2_0: 1 hw.optional.bmi1: 1 hw.optional.bmi2: 1 hw.optional.rtm: 0 hw.optional.hle: 0 hw.optional.adx: 1 hw.optional.mpx: 0 hw.optional.sgx: 0 hw.optional.avx512f: 0 hw.optional.avx512cd: 0 hw.optional.avx512dq: 0 hw.optional.avx512bw: 0 hw.optional.avx512vl: 0 hw.optional.avx512ifma: 0 hw.optional.avx512vbmi: 0$ sysctl machdep.cpu.features
FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
As I understand, the former is the BSD way of describing stuff, while the latter is specific to Mac OS/Darwin.

 2020-10-25, 22:52 #2 retina Undefined     "The unspeakable one" Jun 2006 My evil lair 5×11×107 Posts IMO the only true-and-correctTM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set. This it because it isn't just the CPU you are testing for, it is also the OS. If the OS doesn't enable, and support the instruction set you want to use, even if the CPU has it, then you won't be able to execute them. If you get no exception thrown then you are good to go. And it generalises to all OSes and systems out there. No need to find special files and parse text outputs and whatnot.
2020-10-25, 23:11   #3
rogue

"Mark"
Apr 2003
Between here and the

2·3,019 Posts

Quote:
 Originally Posted by retina IMO the only true-and-correctTM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set. This it because it isn't just the CPU you are testing for, it is also the OS. If the OS doesn't enable, and support the instruction set you want to use, even if the CPU has it, then you won't be able to execute them. If you get no exception thrown then you are good to go. And it generalises to all OSes and systems out there. No need to find special files and parse text outputs and whatnot.
If you want to check programatically, you can use __builtin_cpu_supports() in C/C++. Write a small command line program that checks for each feature you care about.

2020-10-26, 11:53   #4
xilman
Bamboozled!

"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across

242328 Posts

Quote:
 Originally Posted by retina IMO the only true-and-correctTM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set. This it because it isn't just the CPU you are testing for, it is also the OS. If the OS doesn't enable, and support the instruction set you want to use, even if the CPU has it, then you won't be able to execute them. If you get no exception thrown then you are good to go. And it generalises to all OSes and systems out there. No need to find special files and parse text outputs and whatnot.
I am curious.

Can you give a specific example of an instruction which is supported by the bare metal but which can not be executed because of a restriction imposed by the overlying OS?

This is a genuine question because I have never come across an example before.

2020-10-26, 11:58   #5
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

5·11·107 Posts

Quote:
 Originally Posted by xilman I am curious. Can you give a specific example of an instruction which is supported by the bare metal but which can not be executed because of a restriction imposed by the overlying OS? This is a genuine question because I have never come across an example before.
There are many.

The AVX instructions that use ZMM registers, for example, must be enabled by the OS before anyone can use them. I believe this is because the FXSAVE/FXRESTORE type instructions have a different format for the extra registers. So if the OS is unaware of how, or unwilling, to enable such instructions, then the applications also can't use them.

2020-10-26, 22:12   #6
xilman
Bamboozled!

"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across

101000100110102 Posts

Quote:
 Originally Posted by retina There are many. The AVX instructions that use ZMM registers, for example, must be enabled by the OS before anyone can use them. I believe this is because the FXSAVE/FXRESTORE type instructions have a different format for the extra registers. So if the OS is unaware of how, or unwilling, to enable such instructions, then the applications also can't use them.
So what happens if I hand-craft an executable file which contains such an instruction and then try to execute it?

2020-10-26, 22:44   #7
retina
Undefined

"The unspeakable one"
Jun 2006
My evil lair

5·11·107 Posts

Quote:
 Originally Posted by xilman So what happens if I hand-craft an executable file which contains such an instruction and then try to execute it?
If the instruction is not supported then you get an exception. You can test it with an older OS not aware of AVX and try executing some AVX instructions on a newer CPU.

2020-10-27, 19:27   #8
ewmayer
2ω=0

Sep 2002
República de California

1157110 Posts

Quote:
 Originally Posted by Artoria2e5 The current README has this to say about determining the SIMD build mode on Macs: This actually does not work at all since Apple now only tells you it's a "6-core Intel i7 CPU". The correct way to do it, which does not involve wikipedia, is by querying one of the following on the terminal: Code: \$ sysctl hw.optional [snip]
A good suggestion, thanks. The README has been updated.
Quote:
 Originally Posted by retina IMO the only true-and-correctTM method of finding out what one's system can execute is to simply execute an instruction from the set. If you get an exception then you can't use that set. This it because it isn't just the CPU you are testing for, it is also the OS.
...and the compiler and assembler one is using under said OS. IIRC when George was first beginning to play with the then-new avx-512 instruction set, he found that MASM had no support for it. I had no such trouble with the latest stable version of gcc/as under Linux of the "GIMPS KNL", but found that the accompanying version of gdb did not properly support display of the avx-512 registers, so we needed to go to a newer unstable-branch gdb.

Anyhow, the OP-post stuff is all about quickly getting a builder/user to "which instructions should be supported on my CPU?", building with the associated inline-asm selected, then seeing if the resulting binary runs properly.

 Similar Threads Thread Thread Starter Forum Replies Last Post dash1729 Software 3 2020-08-19 20:30 carpetpool Abstract Algebra & Algebraic Number Theory 1 2017-12-28 12:48 MattcAnderson Miscellaneous Math 3 2017-10-18 00:24 robert44444uk Computer Science & Computational Number Theory 15 2017-01-04 12:39 mfgoode Miscellaneous Math 2 2006-04-04 00:18

All times are UTC. The time now is 01:46.

Thu Dec 3 01:46:58 UTC 2020 up 83 days, 22:57, 1 user, load averages: 2.32, 2.25, 1.98