www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the oldest Mac targeted by D programmers?

reply Walter Bright <newshound2 digitalmars.com> writes:
I've been experimenting with code generation in DMD for the AVX instruction
set, 
in particular the replacement of SSE 16 byte vectors with AVX 16 byte vectors 
(no, not the 32 byte ones!).

In my experiments on my machines, two of them support the AVX instruction set,
one of which is my Mac Mini, as determined by this program:

   import core.stdc.stdio;
   import core.cpuid;

   void main() {
     printf("%d %d\n", core.cpuid.avx, core.cpuid.avx2);
   }

or by running:

   sysctl -a | grep machdep.cpu.features

and looking for AVX1.0.

My Mac Mini sez:

   ~> sysctl -a | grep machdep.cpu.features
   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 EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2
   xAPIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

My older MM clearly does not support AVX2, though.

This leads to the question is AVX support a minimum configuration for Macs? Can 
AVX instruction generation become the default for OSX?
Dec 06 2016
next sibling parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 6 December 2016 at 09:12:16 UTC, Walter Bright wrote:
 
 My Mac Mini sez:

   ~> sysctl -a | grep machdep.cpu.features
   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 EST TM2 SSSE3 CX16 TPR PDCM 
 SSE4.1 SSE4.2
   xAPIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

 My older MM clearly does not support AVX2, though.
AVX2 is not listed in machdep.cpu.features, at least not on my machine; you need to look in the machdep.cpu.leaf7_features list. https://csharpmulticore.blogspot.nl/2014/12/how-to-check-intel-avx2-support-on-mac-os-x-haswell.html -Johan
Dec 06 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/6/2016 1:31 AM, Johan Engelen wrote:
 AVX2 is not listed in machdep.cpu.features, at least not on my machine; you
need
 to look in the machdep.cpu.leaf7_features list.

 https://csharpmulticore.blogspot.nl/2014/12/how-to-check-intel-avx2-support-on-mac-os-x-haswell.html
Bummer. Seems like I have nothing that does AVX2. Worse, my motherboard will not support the AMD Carrizo processor (the only AMD AVX2 one) so upgrading means a new computer. Grumble, grumble.
Dec 06 2016
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 6 December 2016 at 09:12:16 UTC, Walter Bright wrote:
 I've been experimenting with code generation in DMD for the AVX 
 instruction set, in particular the replacement of SSE 16 byte 
 vectors with AVX 16 byte vectors (no, not the 32 byte ones!).

 In my experiments on my machines, two of them support the AVX 
 instruction set,
 one of which is my Mac Mini, as determined by this program:

   import core.stdc.stdio;
   import core.cpuid;

   void main() {
     printf("%d %d\n", core.cpuid.avx, core.cpuid.avx2);
   }

 or by running:

   sysctl -a | grep machdep.cpu.features

 and looking for AVX1.0.

 My Mac Mini sez:

   ~> sysctl -a | grep machdep.cpu.features
   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 EST TM2 SSSE3 CX16 TPR PDCM 
 SSE4.1 SSE4.2
   xAPIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0

 My older MM clearly does not support AVX2, though.

 This leads to the question is AVX support a minimum 
 configuration for Macs? Can AVX instruction generation become 
 the default for OSX?
No. Avx arrived in sandy bridge, early 2011. The first sandy bridge processors to land in Macs were shortly after that. macOS Sierra supports hardware back to late 2009 and the OS X versions we support work on even earlier hardware. See everymac.com for apple hardware details. As far I can tell, -march= / -mcpu= options with native as a valid specification is the standard, sane way to deal with this.
Dec 06 2016
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 6 December 2016 at 09:12:16 UTC, Walter Bright wrote:
 This leads to the question is AVX support a minimum 
 configuration for Macs? Can AVX instruction generation become 
 the default for OSX?
No opinion. My whole segment runs on SSE. Zero interest in AVX here, because optimizing for the users which already have the fastest machines is not going to make a difference while optimizing for the lower end does. Hence it's critically important that 32-bit builds use SSE instead of FPU (because denormals) but that's another question and already addressed by LDC. For DMD I'd more interested in yet improving raw compile-time speed, quality, and working 32-bit SSE intrinsics in core.intrinsic (did that changed? D_SIMD wasn't here in 32-bit).
Dec 06 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/6/2016 5:11 AM, Guillaume Piolat wrote:
 No opinion. My whole segment runs on SSE.

 Zero interest in AVX here, because optimizing for the users which already have
 the fastest machines is not going to make a difference while optimizing for the
 lower end does. Hence it's critically important that 32-bit builds use SSE
 instead of FPU (because denormals) but that's another question and already
 addressed by LDC.

 For DMD I'd more interested in yet improving raw compile-time speed, quality,
 and working 32-bit SSE intrinsics in core.intrinsic (did that changed? D_SIMD
 wasn't here in 32-bit).
dmd generates SSE code for OSX 32.
Dec 06 2016
parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 6 December 2016 at 14:28:37 UTC, Walter Bright wrote:
 dmd generates SSE code for OSX 32.
Unfortunately Windows + 32-bit is disproportionately important for my line of work.
Dec 06 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 12/06/2016 08:11 AM, Guillaume Piolat wrote:
 optimizing for the users which
 already have the fastest machines is not going to make a difference
 while optimizing for the lower end does.
Very wise. "Latest is greatest" has become such a sacred cow in the tech sector that far too few developers these days understand basic common-sense logic like that.
Dec 06 2016
parent Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 6 December 2016 at 16:00:43 UTC, Nick Sabalausky 
wrote:
 "Latest is greatest" has become such a sacred cow in the tech 
 sector that far too few developers these days understand basic 
 common-sense logic like that.
I guess it's all about if you control the target hardware. It would be different for scientific software.
Dec 06 2016