Small point of correction - 10nm refers to process size, not die size...

@JourneymanGeek - Articles that I have read always refer to it as the "die size". I mean the die size, hasn't been literally 14 nm for years, despite Intel referring to it as various iterations of (14 nm,14nm+,14nm++, etc). Hence the reason Intel is switching things up with Intel 7

What I don't get, is people are saying that 10nm from Intel is smaller than the 7nm from AMD, and AMDs 7nm is smaller than Apples 7nm??? This is why, I ask if it is just a marketing ploy, because when they are just naming the chip by a size, but there is no standard for determining the size, its not relevant IMO, its just marketing tactics.

@JourneymanGeek is correct, the "die size" is size of the whole chip or core, not a single transistor (or its gate width). It's a few mm^2, not nanometers! Any article you've seen using 10 nm as a "die size" is wrong. Perhaps you've seen the term "die shrink"? That means shrinking everything to a smaller feature size without other redesigns, which of course shrinks the overall die size as a result. i.e. "die shrink" is a more specific term, which means porting to a smaller process size without other significant design changes like adding more cache or other microarchitectural resources.

For example en.wikichip.org/wiki/intel/microarchitectures/sunny_cove#Die shows an actual floorplan (colour-enhanced die shot) of a Sunny Cove core (from an Ice Lake-client CPU), with ~3.5 mm x ~1.97 mm dimensions, giving ~6.91 mm² die size. (for a single core with its slice of L3). That chip is built on the "Intel 10" process, which is the "process size", so the chip dimensions are millions of times the (very approximate) width of a gate in a single transistor.

@JΛY-ÐΞV: Yes, "process size" names like TSMC 7nm are getting farther and farther from reality, and get used more like a version number for marketing. Intel is fully embracing that by changing to "Intel 10" instead of calling it their 10nm process, because their numbers came out higher than TSMCs for similar transistor density. (TSMC may still be ahead on density, but not by as much as the > 4x transistors per area you'd expect from Intel 10nm vs. TSMC 4nm.) extremetech.com/computing/296154-how-are-process-nodes-defin‌​ed looks like a good article.

Process size used to be fairly realistic, but as things like FinFET came along where the gate wrap around the channel, the amount of transistors you could pack into a given area started to depend on more factors. But I think the process node names were often chosen to be like 22nm meaning "as dense as you'd get from a 22nm feature size using the traditional layout". But with nobody using the simple traditional layout for a transistor, that 22nm isn't the physical size of anything anymore. (That might be a distortion, not sure of my memory)

Or there's speculation that it's just pure marketing like Intel 14nm being called that instead of 16nm because they'd always gone down by a factor of 1/sqrt(2) before: forums.anandtech.com/threads/… which mentions some factors like gate pitch vs. gate length.

@ Ramhound and @JourneymanGeek : I made an edit on this answer to fix the die vs. process size terminology. Instead of just deleting some details from the answer, I expanded. In its current state, I think all use of die vs. transistor size terminology is sensible. (Although "avoid having to shrink 32 performance cores" isn't how I'd have described anything. Shrink implies some change when moving to a new process, but Alder Lake is a new design. It's more like "avoid trying to fit 32 performance cores onto a reasonable size die", and yes defects / yields on a new process are an issue.)

@PeterCordes - Your addition is fine, I was just going to say "node size", avoiding the "process" since it felt too similar to processor. Your point in attempting to increase the core count endlessly, into a certain node size, was the point I was attempting to make why Intel would move to a efficiency and performance core layout.

@hobbs - That is the only part of my answer where I cannot provide hard cold facts, since Windows 11 isn't release yet, and Alder Lake products don't exist yet. Windows 11 is indeed expected to take advantage of Alder Lake efficiency cores. I would imagine services like Windows Defender, Windows Update, and other similar services would use the efficiency cores allowing active applications to take advantage of the performance cores.

I see efficiency and performance (big.LITTLE) as the next thing that is changing with processor architectures since we efficiently reach the limit on the frequency, so the next logical thing, would be the number of cores a node can handle. The only way to add more performance cores is to make size of the processor larger, but that goes against the consumer demand, for smaller and more energy efficient devices. Honestly, there is probably diminishing returns, on the number of cores a processor on consumer products.

big/small cores are possible at any process size. What makes them interesting now is that even "small" cores can be fast enough to be useful, because transistor budgets are so big that continuous improvements to mainstream (big) cores have pushed them so far into the diminishing returns of area and especially power. Hyperthreading solves part of the problem of getting throughput out of one big core, but not the power part of the problem. (And with clocks, especially turbo, being limited by power and power density, that's a bigger and bigger deal.)

And yeah, the other part of it is that we now have enough area to put "enough" big cores on a chip with room left over. Frequency gains slowed down significantly since about 2013, so scaling out to more cores has already been a thing for years, with a tradeoff for different workloads between more cores vs. per-thread performance.

@PeterCordes Oh.... okay, thank you for the clarification. I study Computer Science, and I am learning how to write Assembly next semester, which has lead me to research CPU's then I got into this whole Intel Alder Lake release — which is supposed to happen in less than a month (10/22/2021). They are so good at marketing, that now, just after researching them, I want to buy one. Currently, I am using a Sky Lake I7 6700 4core/8thread, at 3.4-4.0GHz and the rate of data of transfer is slow, plus I want to be able to get Windows 11, and play Age of Empires 4.

@PeterCordes - I never intended to make it sound like big.LITTLE couldn't be done at any node size, it's just we have reach a point in processor architecture, where it makes the most sense. The only way to increase frequency is to provide more power to the silicon, but consumers want devices that last days instead of hours, I am certainly one of those consumers. Likewise, it makes total sense for Intel to merge multiple generations of their products, and exponentially shrink those products as manufacturing processes improve.

@JΛY-ÐΞV: As an asm / performance tuning / CPU architecture guy, I'd really like to have a CPU that can run AVX-512, otherwise I'd be a lot more interested in getting an Alder Lake myself. It's a neat design so I'm interested to read about it, and hopefully OS schedulers will make good use of it. The Linux kernel already has patches to make the scheduler aware of Alder Lake (phoronix.com/…).

@Ramhound: Right, yeah, didn't mean to make it sound like you were. Power has always been a big deal especially for laptop CPUs, so I think the key factors that make now the time for heterogeneous multicore are transistor budgets being huge enough to have more than 6 or 8 "big" cores on a consumer CPU. (And the market, including benchmarks, putting significant value on multi-core throughput, and core counts, so a way to advertize higher core counts for the same area is a marketing win if we're looking for cynical reasons.) I think that's the basic point you were making with shrinking cores.

If there are diminishing returns on the number of threads a consumer device should have, and the only way to increase the frequency of a core, is to provide more power to it. We also have to assume that Intel and AMD were reaching the limit on the number of cores they could force into a node size, you are left with small incremental performance increases, on product launches costing billions. So it makes sense Intel wants to get the most out of their product launches, and providing a x86 equivalent of big.LITTLE, is a way to do that.

From my perspective, or rather, from the perspective of a software developer: If Microprocessor Architecture __ like this becomes the norm, Its going to change how _Desktop Software is designed, and written, written. Alder Lake has a crap ton of threads, all being powered by specialized cores. I assume everyone else here writes some code, meaning that you are familiar with assigning a process to a thread, (_i.e something that looks like this: "Code that says: This process will start on this thread @ this moment, then that process on that thread will end & release the thread).

But how will the API's look when different thread types can be used, is that something that languages will be able to control? If so I am guessing specific languages will be able to design software for it. And what will languages like JavaScript (used primarily for browsers) look like under the hood, in other words, will ECMAScript Standardized JavaScript Engines Like Spider Monkey, and V8, have to change to take advantage of this new architecture, or will everything be done in the drivers written for the 12Gen Alder Lake Microprocessors?

I don't really expect any sold answer for the questions above, I am just pointing out that these processors MAY (heavy on the may) have what is required to advance several major technologies, like the internet & high-end desktop software.

@JΛY-ÐΞV JavaScript doesn't support threading, in the sense that a JS program can't start new threads, AFAIK. Desktops (and even phones) have been multi-core for a long time and that still hasn't changed, but presumably people are considering whether/how to add thread awareness to languages like JS.

JS implementations can of course use threads if they can find anything to do in parallel, and of course separate browser tabs can have their own JS "programs" running.

Note that servers have used many-core CPUs for decades, with high-end servers having maybe 56 physical cores / 112 logical cores. And that's just 2x 28-core Xeons. Top-end Xeon Platinum 8380 is 40c / 80t per package, and you can have 2 or 4 in a server pretty easily.

@JΛY-ÐΞV dispatching work to threads is not a new concept. Having a long-running "worker thread" to avoid the overhead of starting up a new thread to run a certain function is normal for computationally intensive code.

@JΛY-ÐΞV The interesting question is whether some programs are going to start trying to out-smart the OS by pinning certain threads to certain cores or sets of cores, e.g. to stop a low-priority thread from ever running on a "performance" core. stackoverflow.com/questions/68444429/…

I tend to agree with the answers that say most programs shouldn't (except maybe as an option), since the choice depends on what else is happening on the system, and the OS or even the user will have a better ability to make decisions.

(Perhaps even with feedback from the hardware about what kind of thing it's running, e.g. code that's mostly bottlenecked on memory bandwidth might not run any slower on an efficiency core. But I don't think current OSes use perf counter heuristics as part of scheduling decisions.)

@PeterCordes I got mixed up, and was thinking about Java, and wanted to make a point about JavaScript. I think I just got overly excited because I know quite well that JS is single threaded Asynchronous Language.

I think what I was trying to ask is how tangible the difference in the two cores will be to developers? Will their abstraction make it past assembly? or will the processes passed to the different threads, and the core type they are passed to, be dictated by software at the lowest of levels?

@JΛY-ÐΞV The only difference is performance of some of the cores. As I mentioned in my answer, they support exactly the same selection of instruction-set extensions. For software, that's basically indistinguishable from an existing Xeon system with the max-turbo limits set differently for some cores than others. (Like you can currently do under Linux, for example.)

Fun fact: current Intel "client" CPUs (non-Xeon) run all their cores at the same speed (except for any that are asleep with the clock halted)

@JΛY-ÐΞV "processes passed to the different threads" - not sure exactly what you mean by that. I was guessing earlier that you meant "some work to do", rather than the usual meaning of an OS-level process with a PID, which might have multiple software threads. (Because the latter meaning is incompatible with "passed to threads")

@JΛY-ÐΞV Also not sure what you mean by abstraction. There is no abstraction in assembly language. Heterogeneous CPUs are designed to work well in systems where only the OS's scheduler knows about the differences between cores, and all other software exists as it does now.

(Because there's no need and not much if any benefit to doing more, and because getting major OSes to tweak their schedulers is all Intel can expect. It would have been unrealistic and a commercial disaster for them to build a CPU that only worked well if all software had to be recompiled with alder-lake-aware compilers.)

The way you're talking about assembly and work being passed to threads makes me wonder if you think that code in a multi-threaded program is somehow special. "Multi-core assembly" is not a thing; there isn't anything special other than accessing memory that other threads might also be reading and writing. stackoverflow.com/questions/980999/…

If you're writing a (toy) OS, that OS has to enumerate the available cores and bring them up (but that's not dependent on which kind of cores alder lake has), but user-space programs don't have to do that.

I mentioned that Intel couldn't have expected to sell a CPU that did need special support from multi-threaded software. The ways that could happen could be if some of the cores have AVX-512 enabled. Or if some of the cores were ARM64 not x86!