NostaSeronx
Diamond Member
- Sep 18, 2011
- 3,571
- 1,118
- 136
Well, that escalated quickly from from something false but funny to something so patently false that is borderline insulting.Intel's approach is more like Prime+Gold than traditional big.Little
You mean they fused off AVX AVX-512 on the Sunny Cove Core? Sweet. I love Intel.Lakefield has no ISA parity. Wikichip says AVX won't work on Core chips for Lakefield.
You're preaching to the choir. I think having support for all of the ISA is paramount as it helps adoption. But given Intel past behavior I doubt they'll go that route.If Gracemont has support for AVX-512, that will change. It doesn't need full width. 2x cycles using 256-bit units or 4x cycles with 128-bit cycles will work.
Didn't Atom's core have AVX512 support already in Knights landing?You're preaching to the choir. I think having support for all of the ISA is paramount as it helps adoption. But given Intel past behavior I doubt they'll go that route.
Yes, but with minimal overlap (no the same instructions mostly), AVX512 is quite a mess:Didn't Atom's core have AVX512 support already in Knights landing?
Executables are not tagged. It is responsibility of the programmer to deliver correct code to the cores by querying features.I wonder if ISA parity really is needed. Aren't the executables tagged with ISA requirements? Can't the processes be pinned to the CPU that has the right support in the SoC?
Executables supporting AVX-based ISA extensions have probably not been compiled with heterogeneous core configurations in mind. I'm guessing Intel ran into problems in testing and decided to fix the problem in hardware rather than try to have everyone recompile everything.You mean they fused off AVX AVX-512 on the Sunny Cove Core? Sweet. I love Intel.
I wonder if ISA parity really is needed. Aren't the executables tagged with ISA requirements? Can't the processes be pinned to the CPU that has the right support in the SoC?
That sounds like nightmare scenario and was designed for strictly heterogenous scenario, where features are detected once at startup and scheduled using those features detected.Executables are not tagged. It is responsibility of the programmer to deliver correct code to the cores by querying features.
In fact a single executable can support multiple code pathes for different feature levels.
Is that a limitation of Windows executable format or of x86? AArch64 ELF have HWCAP.Executables are not tagged.
Then you can't migrate and benefit from a better ISA. Well I guess this clearly means you need the same ISA on all cores.It is responsibility of the programmer to deliver correct code to the cores by querying features.
In fact a single executable can support multiple code pathes for different feature levels.
elf_hwcap is a gobal which is initialized by the kernel at load time. The user application then queries hwcap at runtime callingIs that a limitation of Windows executable format or of x86? AArch64 ELF have HWCAP.
unsigned long hwcap = getauxval(AT_HWCAP);
Precisely.Then you can't migrate and benefit from a better ISA. Well I guess this clearly means you need the same ISA on all cores.
Exactly the wishful thinking we all love you forExactly, Gracemont with IPC around Sky Lake would be pretty powerfull and IMO it's not correct to be named as LITTLE core (as ARM's LITTLE cores are typically very low IPC in-order cores). It's more like MIDDLE core: saving a lot of die space and energy while delivering 80% IPC of Sunny Cove (or 60% of Golden Cove).
8x Golden Cove (IPC +40% over SKL) + 8x cores of SKL IPC .... this thing could be pretty competitive against Zen3 and Zen4.
Now imagine if AMD would launch this big.LITTLE desktop CPU and you're gonna see immediately how ridiculous your sentence sounds all of a sudden.It is responsibility of the programmer to deliver correct code to the cores by querying features.
Oh I thought it was a property in the ELF file. Thanks for correcting my misunderstanding!elf_hwcap is a gobal which is initialized by the kernel at load time. The user application then queries hwcap at runtime calling
From there on the applications typically initializes function pointers with the matching implementation.Code:unsigned long hwcap = getauxval(AT_HWCAP);
There is nothing static in the elf file.
Yes the /proc/cpuinfo output on ARM is regularly being discussed to get around that...Biggest difference here between x86 and ARM is, that on ARM there is no trivial way to figure out HW capabilities at EL0, so kernel need to expose these capabilties.
Since Windows can run on Raspberry you can't assume ARMv8.2On Linux you can use the code snippet posted above, on Windows there is no equivalent i am aware of but you can safely assume ARMv8.2.
I fail to see what is ridiculous (well except that big.LITTLE for desktop sounds ridiculous of course).Now imagine if AMD would launch this big.LITTLE desktop CPU and you're gonna see immediately how ridiculous your sentence sounds all of a sudden.
The notion that efficient programming is the responsibility of the software developer. But anytime AMD is first with a technology or a different way of executing, they're almost always blamed for it. Mantle/DX12, async computing etc.I fail to see what is ridiculous (well except that big.LITTLE for desktop sounds ridiculous of course).
Technically Windows on ARM can run on a variety of ARM SoCs as is as long as they have proper EFI and device recovery support. It pretty much is a generic ARM64 implementation of Windows (plus x86 emulation/WoW on top).Since Windows can run on Raspberry you can't assume ARMv8.2Joke aside I hope MS will support more than Qualcomm chips.
That leak was incorrect, it was corrected later. Rocket Lake has AVX-512 support. That being said, being swayed by Zen 3/4 would make sense either way (until 7nm desktop, at least).Not sure if the below slide has been discussed yet? Couldn't find anything about it in the 3-4 days after the article so apologies if it came up later.
But as much as I was counting on Rocket Lake to be a 14nm Willow Cove backport, it seems to be the final iteration of Coffee Lake, not even with AVX512 included.
![]()
The 15W / 125W TDP split makes sense if you see it as a powerful CPU for ultramobile where there is no room for a dGPU and reuse it for higher-end/SFF desktops for non-gamers.
I was looking forward to upgrade to Rocket Lake around april next year but I guess I'll have to wait at least another year for Alder Lake or be swayed by Zen in the meantime.
My estimate right now:
Comet Lake S - 10C - skylake - 14nm - april 2020
Rocket Lake S - 8C - skylake - 14nm - nov 2020 ~ april 2021
Alder Lake S - 8C/8c - Willow Cove - 7nm/10nm? - april ~ nov 2022
Can you point to the correction? Curious if the stated VRM is wrong as well.That leak was incorrect, it was corrected later. Rocket Lake has AVX-512 support. That being said, being swayed by Zen 3/4 would make sense either way (until 7nm desktop, at least).
Alder is 10nm, and it should be Golden Cove, no?
https://www.reddit.com/r/intel/comments/e4z524 From a quick search, I found this reddit thread discussing the news. Keep in mind that this isn't confirmation that Rocket is Willow Cove, that's sharkbay's speculation. AVX-512 support is almost certain, though.Can you point to the correction? Curious if the stated VRM is wrong as well.
I have trouble seeing a 10nm desktop product ever coming to fruition, so I think it will be skipped. OTOH, I find it hard to believe they'll skip two generations of micro-architecture for the desktop. But the truth will probably in the middle so most likely would be 10nm/Willow Cove or 7nm Golden Cove.
I have no idea why people on this forum keep thinking that intel will release desktop CPUs with completely different architectures fighting for the exact same customer group some mere months away from each other... your estimate makes zero sense... Rocket Lake is not happening this year and it will be a wonder if intel gets TGL out this year in any meaningful quantity.Not sure if the below slide has been discussed yet? Couldn't find anything about it in the 3-4 days after the article so apologies if it came up later.
But as much as I was counting on Rocket Lake to be a 14nm Willow Cove backport, it seems to be the final iteration of Coffee Lake, not even with AVX512 included.
The 15W / 125W TDP split makes sense if you see it as a powerful CPU for ultramobile where there is no room for a dGPU and reuse it for higher-end/SFF desktops for non-gamers.
I was looking forward to upgrade to Rocket Lake around april next year but I guess I'll have to wait at least another year for Alder Lake or be swayed by Zen in the meantime.
My estimate right now:
Comet Lake S - 10C - skylake - 14nm - april 2020
Rocket Lake S - 8C - skylake - 14nm - nov 2020 ~ april 2021
Alder Lake S - 8C/8c - Willow Cove - 7nm/10nm? - april ~ nov 2022