Some Q&As about Intel Alder Lake

(source: HC33.slack.com)

[Q1] Intel in the past has called its decoders 'simple and complex', with previous generations in a 3+1 (4+1?) design. Now the P-core has '6' decoders, and the materials so far haven't stated how many are simple and how many are complex. Can we get clarification on that?
[Q3] As you know, with a hybrid design, the level at which each core has a 'last level cache' could differ - as has been done on other chips. I'd argue that just saying '30 MB LLC' leaves room for interpretation, especially as it wasn't explicitly stated at Architecture day either way - hence the question :wink: In previous years/architecture days Intel would lay out L1/L2/L3 along with clusivity and associativity in a table for each type of core; this time it wasn't explicitly done that way, so clarity on the matter would be appreciated.
	> The deeper dive into decoders memory architecture and core architecture should be directed to Adi and Steve. I will be more that happy to deep dive into the PM and thread director HW/FW/SW

[Q2] You show that the E-cores are built in a four core complex with a 4 MB shared L2 cache. Do these E-cores still have 3 MB of L3 cache per complex in the design, and can access the chip-wide 30 MB of LLC, or is the memory access for the E-Cores straight from their shared L2 up to DRAM?
	> Yes, the E-Core module have also 3M and is connected to the ring with access to the full LLC.

[Q5] Against which Skylake was Gracemont compared (e.g. Skylake on 14nm, Comet Lake on 14nm++++)?
[Q6] The industry-standard is to show the power-performance curves of both the big and small core on the same graph. In other words, how do Gracemont and Golden Cove compare in power/perf?
	> We will publish more power performance details close to the official into

[Q7] Is there any fundamental limitation of Thread Director that would mean it could not dispatch to cores with heterogeneous ISAs, or were the decisions related to ISA compatibility in Alder Lake (i.e. fusing off AVX-512) made for other reasons beyond limits of what Thread Director can handle?
	> Alder lake architecture is same ISA and architecture for both types of cores. The limitation is not Thread Director. Today SW "contract" is such that if an application sets 	affinity, the OS will honor it.

[Q8] On slide 10, we see the 3 packages which show that Alder Lake requires a separate PCH/IO hub. Are there any Alder Lake products that are a true SoC with no separate PCH/IO hub?
	> Mobile are single chip. Desktop have additional on board PCH

[Q9] No Alder Lake die shot(s) for this time? For Tiger Lake presentation at Hot Chips 2020, a die shot of 4C variant is provided in the slides.
	> No die shots yet. More details will be released around ADL intro

[Q10] On slide 11, there is a small package shown to the bottom left of the Alder Lake desktop chip. What is this chip?
	> PCH

[Q13] In slide 11, the PCIe3/4/5 diagram(s) are very confusing. Do ALL dies (not necessarily SKUs) have PCIe5? Can you say which dies have how many lanes of PCIe3, 4, and 5?
	> All dies have PCI Gen-5 and legacy Gen-4. The exact ADL SKUs will be published closer to official intro

[Q15] Do heuristics of program runtime have to be regenerate for the Thread Director or can it be preloaded by the OS?
	> After app start, they re calculate. Once scheduled in and out, context can be saved

[Q16] Does the Thread Director run on a P-core or an E-core?
	> Thread director runs on HW and Firmware. Specifically the telemetry and classification runs today only on the P-Core

[Q17] Will TD be available for Linux, and if so what kernel and when?
	> It is WIP for Linux. It is coming soon. Which build and exactly when will be published closer to intro

[Q18] Will there be an API/controls for a user to set some or all TD parameters?
	> There is already an API (e.g. Eco QoS) that let's an application to declare its priority. Class is microarchitectural and semantic less, enumerated in the table and may change/grow each generation.
	Interesting thought though...

[Q19] Does the Thread Director care for load balancing for scheduling-candidate cores when running workloads with num_threads >= num_cores?
	> Core and Thread count are reported correctly to reflect the real capability of the SoC. Load balancing is the OS job.

[Q20] From the explanation, thread director does not migrate a running process between P an E cores. Is that right?
	> Correct. The OS is responsible for migration. The EHFI table shows the relative performance for each class and the OS will take the action to migrate when reaching a scheduling point

[Q21] What are the security implications of Thread Director as a side channel?
	> Thread director is about performance no DOS concerns. As for exposing information, it is built on top of today's Intel monitoring capability, so I see no added resk

[Q22] Does Ecore and  Pcore ISA fully compatible with each other? Is there any ISA difference that needs software level handling?
	> Yes correct, Fully ISA compatible with no need for SW enabling. On client the ISA is 	AVX 256 + added instructions such as VNNI. Server features are disabled, some fused off and some removed.

[Q23] Can both P-core and E-core active at the same time? If so, will that limit how much P-core can draw power?
	> Definitely. Unlike hybrid for power scalability, P-Core and E-Core are designed to run together. This is how we get the computational density for MT. We do manage and optimize the power efficiency work point to maximize the MT performance as described in slide 21

[Q24] What is the latency for a big core to access data in the shared L2 of the small core clusters?
	> The exact latency is not disclosed at this point. It is connected to the same ring as the P-Cores. It is architecturally MLC. Shared data are stored in the LLC

[Q26] Does the Thread Director take QoS into account? For example, will streaming audio or streaming video get higher priority even if the actual loading may not be high enough to justify scheduling on a P core?
	> Priority is defined by the OS. Thread Director instructs the OS that is the right core to schedule on given that priority. On Windows OS, this priority is not a function of loading. Loading is managed by the SoC power management using the existing Speed 	Shift Technology.
	> Speed Shift Technology will use the QoS information from the OS to set the right working point.

[Q28] Is the time needed to schedule a thread from a P-core to a E-core different then the time needed from P-core to P-core?
	> Same time within the normal variance you would expect on non hybrid architectures.

[Q29] What parameters are used in the ML model for the thread telemetry?
	> It is built on top of Intel's monitoring capability. It uses spin loop detection, mix of instruction, Execution efficiency in terms of IPC and execution efficiency in terms of memory bottlenecks.

[Q30] Will the on-line control decisions create instability by re-scheduling threads continuously?
	> Is there unified power management for the entire SoC? If so, how does I/O impact the power for the cores and also the thread scheduling?

[Q31] Is there unified power management for the entire SoC? If so, how does I/O impact the power for the cores and also the thread scheduling?
	> Intel Speed Sift Technology and additional features do individual, full SoC and full system power and thermal control. I/O is part of this control. Yes, I/O can take some of the power budget from compute.
	Power will impact scheduling only when we reach highly constrained conditions as I described in slide 16

[Q34] One Confirmation: Both P-Core and E-Core support CLDEMOTE instruction?
	> Currently CLDEMOTE not supported

[Q35] Based the Alder Lake picture, does 4 gracemont core are the same size than 1 golden cove core?
	> 1st order of approximation - yes

[Q37] Did you remove the upper half of the AVX512 units in Golden Cove cores, or merely disable the functionality?
	> It is a mix - some of the server features on Golden Cove are fused off in client and some are physically removed
	> At this point we can say that AVX 512 is not supported on Client, only on server parts.