3 ms·

Runtime detection is the process querying what extensions are available, and then selectively using those. You adjust what the query returns to only return the

Runtime detection is the process querying what extensions are available, and then selectively using those. You adjust what the query returns to only return the common set. Except that they almost always do this runtime detection once, on startup, and then choose/thunk codepaths accordingly. If the OS just happens to start my avx2 process on a little core (and how is it going to know better?), that's going to turn off all of my optimizations, regardless of where the process subsequently gets migrated to. You already can't if you're shipping binaries to users unless you only support Skylake & newer? There's a lot of CPUs currently in use that don't support AVX2. So... you either already have this problem and you're familiar with it, or you're not doing this and it's moot. Except nobody in 30 years of x86 dev expects to get a different answer from CPUID during runtime.

davrosthedalek 6y ago
.. and within a function because the scheduler decided to move you to a different core.
wmf 6y ago
If all the cores are configured to advertise the lowest common denominator instructions it will work.
- CountSessine 6y ago
  But that defeats the purpose of supporting any extensions at all in the big core that the little core doesn't support. Software will get the lowest common denominator answer and just not use avx2. So why support it in the first place? Why not just do the right thing and have uniform extension support like big.LITTLE?
  - wmf 6y ago
    Chips aren't designed from scratch. They're assembled out of previously designed components and in this case Core cores and Atom cores were never designed to work together.
    - CountSessine 6y ago
      No - but that just means that Intel shouldn’t do this at all. Either don’t support stuff like avx and avx2 in the big core by disconnecting those blocks or support a slow microcode version of avx and avx2 in the little cores. Supporting different extensions for a CPU used with modern preempting OS’s doesn’t make any sense.
      - kllrnohj 6y ago
        > Either don’t support stuff like avx and avx2 in the big core by disconnecting those blocks That's partly what they did. From the article: "One thing we can confirm in advance – the Sunny Cove does not appear to be AVX-512 enabled." Maybe they also fused off AVX & AVX2 support in the Sunny Cove core as well, we'll see. And disabling AVX in cores that otherwise support it is already a common thing - see the Pentium & Celeron lineups that Intel currently sells. They don't have AVX/AVX2, even though the cores inside them definitely could offer it.
  - Symmetry 6y ago
    Currently Intel likes to disable features on some models of Core cores for product segmentation reasons. I'm pretty sure processors sold under the Pentium or Celeron brands already have enough features fused off that they're roughly comparable to the Atoms this is being pared with. You also fuse off things like sections of cache or whole cores that have manufacturing defects.

davrosthedalek 6y ago

.. and within a function because the scheduler decided to move you to a different core.

wmf 6y ago

If all the cores are configured to advertise the lowest common denominator instructions it will work.

CountSessine 6y ago
But that defeats the purpose of supporting any extensions at all in the big core that the little core doesn't support. Software will get the lowest common denominator answer and just not use avx2. So why support it in the first place? Why not just do the right thing and have uniform extension support like big.LITTLE?
- wmf 6y ago
  Chips aren't designed from scratch. They're assembled out of previously designed components and in this case Core cores and Atom cores were never designed to work together.
  - CountSessine 6y ago
    No - but that just means that Intel shouldn’t do this at all. Either don’t support stuff like avx and avx2 in the big core by disconnecting those blocks or support a slow microcode version of avx and avx2 in the little cores. Supporting different extensions for a CPU used with modern preempting OS’s doesn’t make any sense.
    - kllrnohj 6y ago
      > Either don’t support stuff like avx and avx2 in the big core by disconnecting those blocks That's partly what they did. From the article: "One thing we can confirm in advance – the Sunny Cove does not appear to be AVX-512 enabled." Maybe they also fused off AVX & AVX2 support in the Sunny Cove core as well, we'll see. And disabling AVX in cores that otherwise support it is already a common thing - see the Pentium & Celeron lineups that Intel currently sells. They don't have AVX/AVX2, even though the cores inside them definitely could offer it.
- Symmetry 6y ago
  Currently Intel likes to disable features on some models of Core cores for product segmentation reasons. I'm pretty sure processors sold under the Pentium or Celeron brands already have enough features fused off that they're roughly comparable to the Atoms this is being pared with. You also fuse off things like sections of cache or whole cores that have manufacturing defects.