Also, what ever the next version of Windows is, it's not new. It'll just be a branch of Win10, AFAICT. I haven't seen anything about low level changes. So, still the stinking layered up mess of services and interfaces built on the ever aging NT substructure.About ADL scheduling:
Intel 10nm Alder Lake Desktop CPUs Launching During Halloween 2021, Will Feature Support On New LGA 1700 Socket Motherboards
Intel's 12th Generation Alder Lake K-series desktop CPUs based on the 10nm Enhanced SuperFin architecture are expected to launch in October.wccftech.com
The Windows scheduler added support for heterogenous scheduling which took into account the app intent for scheduling on big.LITTLE architectures.
By app intent, I mean Windows tries to provide a quality of service for apps by tracking threads which are running in the foreground (or starved of CPU) and ensuring those threads always run on the big core. Whereas the background tasks, services, and other ancillary threads in the system run on the little cores. (As an aside, you can also programmatically mark your thread as unimportant which will make it run on the LITTLE core.)
Work on Behalf: In Windows, a lot of work for the foreground is done by other services running in the background. E.g. In Outlook, when you search for a mail, the search is conducted by a background service (Indexer). If we simply, run all the services on the little core, then the experience and performance of the foreground app will be affected. To ensure, that these scenarios are not slow on big.LITTLE architectures, Windows actually tracks when an app calls into another process to do work on its behalf. When this happens, we donate the foreground priority to the service thread and force run the thread in the service on the big core.
The key being that Alder Lake isn't big.LITTLE. Alder Lake is big.Medium (I refuse to use Intel's big.bigger terminology). Thus the need for changes to the scheduler. You are correct that Windows has had big.LITTLE for quite some time. But that isn't what Alder Lake uses or what Alder Lake is intended for.It is BS because:
Quote above coming form Microsoft and not from some dubious source. The scheduler is already working perfectly fine, which you can see when you happen to have a Windows big.LITTLE machine (perhaps excluding Lakefield)
I also posted a picture of the task manager, showing the system services on the little cores, while the big cores are power gated - except the one big core, which running the foreground app here
The key being that Alder Lake isn't big.LITTLE. Alder Lake is big.Medium (I refuse to use Intel's big.bigger terminology). Thus the need for changes to the scheduler. You are correct that Windows has had big.LITTLE for quite some time. But that isn't what Alder Lake uses or what Alder Lake is intended for.
how does big medium change anything, its only if you had big medium little would you do something different.
IE. list the exact use case where the scheduling method for big little would be different for big medium.
The key being that Alder Lake isn't big.LITTLE. Alder Lake is big.Medium (I refuse to use Intel's big.bigger terminology). Thus the need for changes to the scheduler. You are correct that Windows has had big.LITTLE for quite some time. But that isn't what Alder Lake uses or what Alder Lake is intended for.
Sure it does, changing the name from small to medium brings a 10-15% performance uplift at the very least. You're new around here, aren't you? Let me give you the talking points:This does not change anything.
And this is how we get from not needing 6-8 classic cores on a modern desktop, but needing 6+ hybrid cores with additional scheduler optimizations on top to make everything work "faster". You see, this is why YOU don't work in Marketing, you common sense engineer! /s
It is hard to find a words for this. Hm, lost in the woods of smoothly video playback. Completely useless, "in reality that PC also could be a AMD Ryzen PC".It is absurd for a company like Intel, to do such useless "imagine that it is Alder Lake PC and laptop".
SPR die shot.
Up to 15 cores per die, so a max config of 60 cores assuming all of them are enabled.
SPR die shot.
Up to 15 cores per die, so a max config of 60 cores assuming all of them are enabled.
That die shot is obviously incorrect, @ashFTW already confirmed multiple times that SPR is 80 cores based on physical evidence.
...i revised it to 72 cores. I still believe that to be true, unless Intel only made one tile that has to work in both x2 and x4 configurations, in which case more I/O and mem controllers have to be put on each tile, reducing the number of cores that it can be accommodate.
i revised it to 72 cores. I still believe that to be true, unless Intel only made one tile that has to work in both x2 and x4 configurations, in which case more I/O and mem controllers have to be put on each tile, reducing the number of cores that it can be accommodate.
i revised it to 72 cores. I still believe that to be true, unless Intel only made one tile that has to work in both x2 and x4 configurations, in which case more I/O and mem controllers have to be put on each tile, reducing the number of cores that it can be accommodate.
So you think it is possible Intel taped out, produced a full set of masks, and manufactured a 15 core tile and then scrapped that and started all over again with a larger 19 core design? That is... highly unlikely.If you look at the die shot the bottom area doesn't look like an extra row of cores. I suppose it's possible that the die used is very old and the final version has 76 (72).
I think there will be a 2 die configuration for Xeon W/HEDT but that would be quad channel.
It's not lazy at all. The whole point of tiled design is reuse. The design and mask costs for newer manufacturing nodes are prohibitive unless you can achieve sufficient volume. Monolithic SoCs can only scale to a certain point and then you're forced to tile. I don't think Intel is disaggregating at all here, they're just designing specifically for multi-chip modules using advanced packaging techniques. Every SPR tile has 15 cores plus one quarter of the uncore stuff. A 4-tile package will have a maximum of exactly 60 cores.That would be a pretty lazy thing to do, given Intel in the past has made several die sizes for each Xeon generation.
SPR supports uncore of 8 DDR5, and 80 PCIe 5.0, and up to 4 UPI. Let’s look at the options to achieve this in 2 and 4 tiles.
Tile A: all core
Tile B: half of uncore, rest core
Tile C: one fourth of uncore, rest core
to achieve medium and small configurations: two B tiles
to achieve larger configuration: 1) two A and 2 B tiles 2) four C tiles, or 3) four B tiles
if Intel only made the B tile, then the max cores with 4 tiles will be close to 60. If they made B and C, or A and B, they can go up to 72.
Lets wait and see.