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?

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

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.

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.

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).

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.

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.

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.

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.