Re:Intel Discloses Lakefield CPUs Specifications
by wmf on Wednesday June 10, 2020 @04:04PM
(#23481418)
If all the cores are configured to advertise the lowest common denominator instructions it will work.
Re:Intel Discloses Lakefield CPUs Specifications
by CountSessine on Wednesday June 10, 2020 @04:48PM
(#23481919)
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?
Re:Intel Discloses Lakefield CPUs Specifications
by Symmetry on Wednesday June 10, 2020 @07:39PM
(#23483453)
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.
Re:Intel Discloses Lakefield CPUs Specifications
by wmf on Wednesday June 10, 2020 @05:15PM
(#23482203)
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.
Re:Intel Discloses Lakefield CPUs Specifications
by CountSessine on Wednesday June 10, 2020 @05:32PM
(#23482391)
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.
Re:Intel Discloses Lakefield CPUs Specifications
by kllrnohj on Wednesday June 10, 2020 @06:33PM
(#23482959)
> 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.
Re:Intel Discloses Lakefield CPUs Specifications
by davrosthedalek on Wednesday June 10, 2020 @03:52PM
(#23481288)
.. and within a function because the scheduler decided to move you to a different core.
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.