Re: [INTERNALS-WIN] --enable-native-intrinsics issue

On 28.12.2018 at 21:02, Kalle Sommer Nielsen wrote:

> Den fre. 28. dec. 2018 kl. 20.38 skrev Anatol Belski <[email protected]>:
>
>> --enable-native-intrinsics doesn't require the actual host to support the chosen features. Thus, the actual features need to be present on the target machine. AVX2 is still a rare case, but most of the current x86 hardware supports AVX.
>>
>> The default processor feature set is SSE2. If compiler generates some AVX2 optimized binary, it won't run on machines that don't support AVX2. An external starter tool could be used, that invokes a suitable binary depending on the feature detection. However that's not universally doable. Say for Apache where PHP is a DLL. For FCGI it might be error prone, too. And otherwise, one would have to deliver bins with different optimizations along with the default ones. So that's not a real solution. And btw, even in the SSE2 builds there's a dynamic feature detection which is used internally for some functions in the core, like addslashes(), etc.
>>
>> Still, binaries generated to use more recent CPU features might show better results. Snapshots currently produce AVX optimized binaries for 7.3 and master. I had no chance to test AVX2 yet :( In any case that's not different from other platforms when doing cross compilation. For example any distributions would usually deliver max SSE2 bins, but a user is free to use -march=native when compiling themselves. I don't see a reason to overcomplicate this, especially as there's no good way to deal with this at runtime. Implementing -march=native might make sense, but its absence is not critical. Free tools like coreinfo or cpuz are available, too.

Thanks for the explanation, Anatol!

> Yeah I realize that, however what I was thinking was to add a program
> that can tell the CPU features so that potential builders can more
> easily spot. Like a simple C++ program that exposes that with
> __cpuid/__cpuidx.
> 
> But I agree, a runtime solution is not gonna be an option worthwhile
> at all, for the obvious performance degration it comes with. However I
> think we could help our users/developers (especially those not too
> familiar with more advanced Windows build setups) on this front.

I guess that those who are not familiar with more advanced Windows build
setups won't even be aware of this configure option, and that others may
sometimes want to build for other platforms.  It seems to me that we
merely should document the feature and its potential issues.  Not sure
where, though, since the “Manual PHP Installation on Windows” section[1]
is not about doing own builds; maybe these documentation should be added
to the Windows step by step build with SDK 2 page[2]?

[1] <http://www.php.net/manual/en/install.windows.manual.php>
[2] <https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2>

-- 
Christoph M. Becker