4 ms·

There are feature flags for formerly slow instructions that are now fast. E.g. rep mov https://www.phoronix.com/scan.php?page=news_item&px=Intel-5.6-FSRM-Memmo

There are feature flags for formerly slow instructions that are now fast. E.g. rep mov https://www.phoronix.com/scan.php?page=news_item&px=Intel-5.6-FSRM-Memmove https://www.phoronix.com/scan.php?page=news_item&px=Intel-5....

tedunangst 5y ago
Which flag should I check for fast PEXT?
- dataflow 5y ago
  See [1], or [2] and [3]. [1] https://github.com/as-com/varint-simd/blob/f4c4af672403cc68391ee5dd1d9eb478ce410c8a/build.rs#L17 https://github.com/as-com/varint-simd/blob/f4c4af672403cc683... [2] https://en.wikipedia.org/wiki/X86_Bit_manipulation_instruction_set#cite_note-18 https://en.wikipedia.org/wiki/X86_Bit_manipulation_instructi... [3] https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...
  - tedunangst 5y ago
    So... ignore the cpuid bit indicating the instruction is present and look at manufacturer string, which is exactly what intel is being lambasted for here.
    - dataflow 5y ago
      No, you don't ignore the CPUID feature bit. You use the CPUID to enable the feature by default, but override that default by blacklisting specific models that you know would have undesirable implementations. So what you would do for PDEP/PEXT would be use_pdep = cpuid.supports_bmi2() && !cpuid.is_amd_before_zen3() and not use_pdep = cpuid.is_intel_haswell_or_later()
wtallis 5y ago
That feature flag is merely a macro in the Linux kernel source code, and doesn't appear to be exposed to userspace. It is entirely different from the kind of flags under discussion, which are in the return values of the CPUID instruction and available for any program to query.
- gpderetta 5y ago
  from the patch: The enhancement applies to string lengths between 1 and 128 bytes long. Support for fast-short REP MOVSB is enumerated by the CPUID feature flag: CPUID [EAX=7H, ECX=0H).EDX.FAST_SHORT_REP_MOVSB[bit 4] = 1 So there is indeed a CPUID feature flag for fast rep movsb.

tedunangst 5y ago

Which flag should I check for fast PEXT?

dataflow 5y ago
See [1], or [2] and [3]. [1] https://github.com/as-com/varint-simd/blob/f4c4af672403cc68391ee5dd1d9eb478ce410c8a/build.rs#L17 https://github.com/as-com/varint-simd/blob/f4c4af672403cc683... [2] https://en.wikipedia.org/wiki/X86_Bit_manipulation_instruction_set#cite_note-18 https://en.wikipedia.org/wiki/X86_Bit_manipulation_instructi... [3] https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...
- tedunangst 5y ago
  So... ignore the cpuid bit indicating the instruction is present and look at manufacturer string, which is exactly what intel is being lambasted for here.
  - dataflow 5y ago
    No, you don't ignore the CPUID feature bit. You use the CPUID to enable the feature by default, but override that default by blacklisting specific models that you know would have undesirable implementations. So what you would do for PDEP/PEXT would be use_pdep = cpuid.supports_bmi2() && !cpuid.is_amd_before_zen3() and not use_pdep = cpuid.is_intel_haswell_or_later()

wtallis 5y ago

That feature flag is merely a macro in the Linux kernel source code, and doesn't appear to be exposed to userspace. It is entirely different from the kind of flags under discussion, which are in the return values of the CPUID instruction and available for any program to query.

gpderetta 5y ago
from the patch: The enhancement applies to string lengths between 1 and 128 bytes long. Support for fast-short REP MOVSB is enumerated by the CPUID feature flag: CPUID [EAX=7H, ECX=0H).EDX.FAST_SHORT_REP_MOVSB[bit 4] = 1 So there is indeed a CPUID feature flag for fast rep movsb.