18 ms·
Intel's New Chimera: Alder Lake
- throwaway0x7E6 4y agoI feel that P and E split requires putting an asterisk next to the core count. it is dishonest to sell a CPU with N fully featured cores and M gimped cores as a CPU with N+M cores
- Zardoz84 4y agoThis have the same vibes that AMD FX cpus "core" count.
- rocqua 4y agoThat is indeed how they are marketed. Either as 8+4core or 8p4ecore. I have only seen the 8+8core referred to as a 16 core machine once. And it was Apple making a comparison to Intel and calling Intel's cpu a 16 core.
- throwaway0x7E6 4y agooh yeah, I looked it up, you are right. I didn't notice that before
- giantrobot 4y agoEven worse (to me) is the P-cores have two way hyperthreading enabled so Intel says the CPU supports N(2)+M threads. While Intel has always behaved as if their hyperthreading meant a chip had N(2) core of performance, in the real world it's was more like N(1.5) at best. So a CPU with 20 threads has maybe eight running at full speed of a P-core and the other twelve pretty gimped comparatively.
- mrath 4y agoI don't have an idea on CPU design. Can this lead to M1 like performance?
- destroy-2A 4y agoI think the article is is saying it won’t lead to much of anything except headaches.
- ggreer 4y agoThat's the impression I got as well. That made me discount Agner's arguments since they apply to Apple's M1, and the M1 is great in both raw performance and power efficiency.
- r00fus 4y agoDifference: Apple controls software + hardware and can this immediately utilize hardware efficiencies like a new Arch with a simultaneous release. Intel doesn’t control Windows.
- can16358p 4y agoNot in its current form.
- quux 4y agoThe goal of this kind of design is M1 like energy efficiency, not performance (I don't know if the Alder Lake P cores can outperform an M1 P core.) M1 has a similar architecture with performance and efficiency cores, but so far I haven't heard of it causing problems for software developers. All versions of macOS that support M1 also have a scheduler that is able to move threads between E and P cores nicely.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- iforgotpassword 4y agoI wish there was at least a switch to allow the CPU to report the proper CPUID on each core and ideally, also keep AVX512 enabled. You could have a bios setting writing to an MSR. But I guess some idiot gamer somewhere might still enable this setting without understanding a word of the warning it's accompanied by and Intel wants to avoid that. But I'm hopeful this is a stop-gap solution and we'll just make the p-cores more power efficient under medium load, and merely have the OS clock them lower when something is determined a background task. Then we "only" have to get that part to become smart enough.
- esperent 4y agoSuch a condescending comment. Why should this "idiot gamer", who might be a child, be expected to know about this stuff?
- userbinator 4y agoWhy should children be expected to not learn anything the hard way?
- iforgotpassword 4y agoYes, an attempt at sarcastically describing Intels train of thought was made. But really, why would a child change random bios settings anyway? You can easily render your system unbootable by changing random things there. Better make knifes illegal before an unsupervised toddler hurts themselves?
- zaptrem 4y agoThat's how they learn! I'm forever grateful for all the times I accidentally bricked my PC and had to work my way out of it.
- kijiki 4y agoI very much don't understand why Intel didn't disable AVX-512 on the P cores, unless and until the OS writes to a new MSR that means "I understand that the P cores can do AVX-512, while the E cores cannot", and then enable AVX-512 on the P cores. Old OS versions continue to work fine, and newer OS versions can opt into the new world and benefit.
- kolbusa 4y agoMy guess would be that this is because of thread migration. (After reading the TFA: that's what Agner says right there in the 4th paragraph.) (After re-reading the comment: I guess that the OS changes would need to be extensive with little to no benefit: running AVX2 on all cores will likely be faster than running 2 P cores with AVX512. The only thing that is really affected is the code that could use AVX512_FP16, but I doubt there's a lot of it outside of Intel.)
- kijiki 4y ago> I guess that the OS changes would need to be extensive I don't think that is true. In the simplest case, you could modify the #UD handler to notice when the fault is caused by an AVX512 instruction running on an E-core, and then simply and pin the process to the P-cores, migrate the process, and continue. All existing scheduler functionality. > The only thing that is really affected is the code that could use AVX512_FP16, but I doubt there's a lot of it outside of Intel. AVX512 is a lot more than just extending the vector width, and that extended functionality can be very useful for quickly emulating other CPU's vector instruction sets.
- berkut 4y agoThey have, haven't they? And officially it was never supported. The article even mentions it: some BIOSs had the ability to override it, but it sounds like that's been disabled in the microcode?
- inkyoto 4y agoI understand even less why Intel has been creating numerous AVX extensions (1,2 and 512) instead of focusing on a single programmable variable vector length extension that would not require the addition of new opcodes every time the CPU supported maximum vector length increased. It has been clear for a long while that the vector length was going to gradually increase every few years to support new data processing requirements, so the writing has been on the wall all along.
- can16358p 4y agoPerhaps the easier option would be DRM software and anything that needs instructions that are only on a specific core type, stick to those cores. It might reinvolve changes to DRM software but looking at the current compromises, looks like a better deal. Of course Intel should have thought of this and didn't pick this route. I'd love to see the reasoning though.
- native_samples 4y agoIntel is in general heavily constrained by whatever Microsoft chooses to do with Windows. It's not like Apple where they can introduce a new hw feature and then immediately use it in the operating system. For example the M1 Macs have the big little architecture integrated with Grand Central Dispatch. Many, many interesting Hardware features have died in the Intel world because the Windows team simply did not add good enough support for it and there was nothing Intel could do. In this case detecting DRM software and scheduling it differently would require sophisticated support in the operating system, or even ideally DRM support implemented by the operating system. However these things are probably beyond Microsoft's capabilities in its current state.
- q-big 4y agoI would rather say that if such a CPU breaks DRM software, this should be considered a feature.
- can16358p 4y agoI see your point. Well it would be nice if Microsoft found a way to implement them and coordinate with Intel, with backwards compatibility of course (which is the key point of Windows). Then this brings another question to my mind: if Intel is so contrained by Microsoft's decisions (which make sense) they should have been in a good relationship designing things that work nice together. Why did they design their CPU in a way that would break in Windows usage in the first place? They must have much more R&D than saying "let's design this hybrid CPU and put a new instruction set on some cores and see if it works on Windows and DRM software else we disable those features" kind of approach.
- berkut 4y agoOther than obvious stuff like differences in features (AVX512 - although I thought that wasn't even officially supported at one point even though they haven't disabled it?) between the P and E cores, how does ARM manage it with big/LITTLE cores? Surely that's similar to a degree (Out of order P cores, in order E cores) to what Intel are attempting? Are Intel just taking it too far in terms of disparity between the architectures?
- kimixa 4y agoOn an android device I worked on some 5 years ago (so might be out of date) it used a simple cpu mask. Background tasks always used only the little cores, foreground apps always always used only the big cores. I do not believe it was possible for a single app to run threads on both big and little cores. And my understanding is that every arm big.LITTLE combination supported exactly the same ISA and were intentionally 100% binary compatible. For example, you couldn't pair arm A53 little cores (that support only armv8-a) with A75 big cores (which support armv8.2-a)
- londons_explore 4y agoWith some software work, you could pair differing cores. You'd just deliver a signal to a process saying 'youre about to be moved to a different core type, please recheck the capabilities'. Then, you'd have a compatibility shim that emulates unimplemented instructions using traps for software that hadn't yet been rewritten to understand the above signal.
- justincormack 4y agoThere were s small number of phones shipped with differing cores but it did not work well.
- kouteiheika 4y agoPersonally I don't really see a point in having a hybrid architecture like this unless it'll lead to massively increased core counts, and so far it doesn't look like it does. AMD still beats Intel in both core counts and power efficiency, and they're only using P cores so... what's the point of having E cores? But maybe that's just because it's a first generation technology for Intel? I hope things improve in the future because I sure would love to have more cores available (currently rocking a 32 core Threadripper) and AMD is sure as hell not interested in actually pushing HEDT forward since they became the top dog. (I have a few grand burning a hole in my pocket waiting for a product they don't want to release.)
- zasdffaa 4y ago> because I sure would love to have more cores available (currently rocking a 32 core Threadripper) wtf do you need more cores for??? Wat are you doing? > not interested in actually pushing HEDT forward since consider buying a server.
- szastamasta 4y agoI see nothing particularly hard in utilising 32 cores. When I launch all the services in the project I’m working on my os has plenty work to schedule. Right now I have 3732 threads running on my machine. It’s totally separate question if OS can schedule so many threads effectively on so many cores, and how much coordination overhead there will be. But that’s just something we have to figure out and fix.
- zasdffaa 4y agoI'm interested, what are you doing that can eat all those cores>
- deeringc 4y agoAnyone working on even a medium sized C++ project needs a very high end machine in order to compile. For large projects, 32 core work stations aren't crazy at all. Try building something like Firefox or Chromium on a quad core and you will see what I mean. The cost of the workstation is tiny compared to the cost of the engineer and you really don't want them to be waiting around for half their day (quite literally) because of a miserly equipment budget.
- beebeepka 4y agoHasn't it been at least six months since release? What an odd self promoting entry
- devmor 4y agoResearch and experimentation generally takes time.
- beebeepka 4y agoAs of now, the linked forum thread contains zero research
- matthews2 4y agoAgner Fog's analysis and guidance is gold to anyone trying to optimise software for a specific microarchitecture.
- beebeepka 4y agoI see. Yet, this particular entry only contains tiny amounts of well known information. I feel like this product line has been well covered for months now. Oh well.
- Strom 4y agoThe key to understanding the popularity of stories that contain "well known information" is that not everyone has the same life experiences. For every piece of info you know, there are a lot of people who have never heard of it. Including on HN.
- fancyfredbot 4y agoWas it really "well known" that the complex number multiplication opcodes needed the destination to differ from the source or that the intermediate results were rounded to ensure they were commutative?
- tokamak 4y agoIntel who?
- roomey 4y agoJust trying to figure this out. So the low power high power cores do seem to be inspired by the M1. If they can implement that easily in x86 is another thing but if anyone can Intel can I guess. The half prescion fps are obviously aimed at ML but how on earth are the hoping to compete with gpus on this front? Where is the use case on this (genuine question). The complex numbers bit makes me think of quantum circuit simulation (but that could be bias on my part as that's what I'm looking at). But this is a relatively small field at the moment, and just through normal use nvideas backend simulator blows cpu performance out of the water (both for speed and number of qubits simulated). I assume I'm missing the point here and it is heavily used in compression or something but again if someone had an idea of the usecase for complex number instructions that would be useful! Thank you
- radicaldreamer 4y agobig.LITTLE preceded the M1 by a long while.
- astrange 4y agoFP16 is a common GPU format (ML is better with a different one called BF16). The reason to add it to your CPU is so you can work on the same data without having to do software emulation which is really slow.
- sliken 4y agoAlder lake so far hasn't been anywhere near the efficiency of the M1. > The half prescion fps are obviously aimed at ML but how on earth are the hoping to compete with gpus on this front? Where is the use case on this (genuine question). Sure, it's not GPU competition, but still helpful, after all a fair chunk of the computers on the planet to do not have discrete GPUs.
- thrwawy283 4y agoMy understanding is that Intel boosts power so a single core can chew through a program quicker than being inherently energy efficient (performance-per-watt). Most of the time this benefits Intel, because a core will boost-up-then-down quicker over completion of the program than a more efficient AMD processor core. (This is my layman understanding.) I solidly believe AMD is the king for efficiency, but I wish I could find better benchmarks showing idle power use for AMD vs Intel (not peak power use). My understanding is that Intel has deeper power states its processors settle into. I'm surprised someone doesn't artificially limit or undervolt their Intel proc to approach or surpass what we're seeing from AMD. Would it significantly lengthen the total execution time of the program? Would there still be a significant difference in "performance"? Performance-per-watt is important, and the total amount of power to execute the program. Would this be in Kilowatt/hours? I want to see how many Kilowatt/hours something like Cinebench consumes on similar AMD & Intel processors, so we can derive the "real computing efficiency".
- rocqua 4y agoI believe practical laptop benchmarks show and to have better real-world efficiency. But I haven't kept up very well.
- wmf 4y agoBesides hybrid cores, Intel and AMD are using the same techniques. They both turbo and they have the same low-power modes. This year Intel is slightly ahead in performance and AMD has longer battery life but next year it will probably be different.
- karussell 4y agoFor a desktop or mobile processor this might make sense, but many hosting providers sell dedicated hardware with desktop processors to be used in a server environment. (E.g. Hetzner https://www.hetzner.com/dedicated-rootserver/ex100 https://www.hetzner.com/dedicated-rootserver/ex100) So the provider can save energy and make sense of this, but customers won't notice the energy savings in their pocket and they only notice that they can only use 8 cores. When I tested this a few months ago under Linux every request of our server application would land on a different CPU leading to funny performance characteristics. Even Ubuntu 22.4 does not seem to have the kernel included 5.16+ that fully supports this CPU (https://www.phoronix.com/scan.php?page=article&item=adl-linux516-windows&num=1 https://www.phoronix.com/scan.php?page=article&item=adl-linu...) As we use the JVM the only interesting use case I can imagine would be to assign the slower efficiency cores for the garbage collector.
- xmodem 4y agoWhile there might be some edge cases where it's useful, heterogenous cores don't make a tonne of sense in the datacentre, hence why Intel hasn't made Xeon's with that design. It seems to me this falls firmly in the category of caveat emptor.
- astrange 4y ago> As we use the JVM the only interesting use case I can imagine would be to assign the slower efficiency cores for the garbage collector. Generally speaking trying to run code that shares memory between P and E cores only results in pain. It could work but the software needs to be designed for it.
- rock_artist 4y agoThis reminds me of the 'transition' to multi-core code started in the "Core" days (or actually AMD's Athlon X2). The switch to multi-core/thread/process (as this all were steps towards such approach) needed to be implemented by all layers (h/w, os, s/w). We're now getting from symmetrical to heterogeneous computing becoming the mains-stream on all platforms. Just a few weeks ago there was here the issue with measuring efficiency which is flawed on Apple's Activity Monitor. As the multi-thread code paradigms thrived, asymmetrical-cores will also become part of the toolchain eventually.
- Traster 4y agoYou get a bunch of smart hardware guys into a room, they design this funky exotic architecture. Then the software goes "Allocate these threads to whatever is idle" and suddenly you've completely lost any possible advantage and are thrashing around with no idea what you're doing. The big-little architecture from Apple was accompanied by software that basically handles that for you. From what I heard there were similar problems with Xeon Phi - great theoretical performance but a very difficult programming model and as a result very challenging sales for the Intel sales guys.
- pjmlp 4y agoConsole history is full of such examples.
- orra 4y agoI remember Mono, a .NET runtime, having to change its allocations to fit inside a smaller core. This was because a thread could start on a bigger core but then be shunted onto a smaller core. That fixed the crashing but obviously came with a loss of performance.
- masklinn 4y agoIt was a bit more complicated than that: the issue was that one of the early big.LITTLE designs (Samsung's Exynos 8890) had different cacheline sizes on the big and little cores. glibc's `__clear_cache` would cache the cacheline size on first call, so if the program was started on a big core then migrated onto a little core it would only flush every other cacheline. Which was an issue for any program needing to explicitely clear the caches, like most any JIT. And the mitigation was not to "change its allocation", it was to bypass libgcc and handroll cache clearing: https://github.com/mono/mono/pull/3549 https://github.com/mono/mono/pull/3549 Source: https://www.mono-project.com/news/2016/09/12/arm64-icache/ https://www.mono-project.com/news/2016/09/12/arm64-icache/ This issue didn't only affect Mono e.g. dolphin (https://github.com/dolphin-emu/dolphin/pull/4204 https://github.com/dolphin-emu/dolphin/pull/4204) and ppsspp (https://github.com/hrydgard/ppsspp/pull/8965 https://github.com/hrydgard/ppsspp/pull/8965) had been hitting the same issue and adopted mono's fix. But fundamentally this is the 8890 being broken: as the Mono post notes, technically nothing precludes core migration in the middle of clearing the cache, which would also lead to broken behaviour, with no mitigation.
- kilburn 4y agoI may be way off here, but to me the transition to heterogeneous cores is more of a long term than short them play, anticipating the era where we'll have different kinds of cores in our systems. Even the performance cores of today have circuitry that's there to make certain workloads faster (video decoding, crypto operations, etc.). Other stuff has mostly been offset to the GPUs (actual grahphics-related stuff, machine learning). In an architecture where you can mix/match different kinds of cores, it doesn't sound crazy to have cores that are specially designed for those tasks. Processors could ship with one "crypto-core", a "video-decoding-core", etc.. These should provide similar performance to full performance cores at _much_ lower cost, energy consumption and die area. If (and that's a big if) they can get to a point where: a) Designing/implementing new specific-purpose small cores is not outrageously expensive because the whole coordination/integration part is already solved b) They have a combination of cores that provides similar performance to current p-cores-only cpu's at similar processor cost and power budget. That would be a huge win for processor companies. They would be able to open lines of specialized processors commanding huge premiums for certain industries (think about processors with 128 ml-cores, 128 video-encoding-cores, etc.). Or maybe I'm just delusional :)
- astrange 4y agoIntel CPUs already have video encoding/decoding cores built into the iGPU. Though they don’t allocate nearly the space to GPU that they could. It does provide power advantages more than performance. The downside is that it’s much harder to improve the algorithms after they ship.
- booi 4y agoLuckily video codecs also hardly change in an incompatible way after they ship. There's also varying levels of support that can be fully or partially HW decode/encoded and the pure CPU fallback. Intel's Quicksync is best-in-class and even available on low power Celeron/Atoms
- aaaa_vougoza 4y agoIntel Cell B.E but just around 12 years late.
- deleted 4y ago[deleted]
- wscott 4y agoFunny he defines Chimera as the mythical beast right at the start. I was sure he was thinking of the alternative definition: > a thing that is hoped or wished for but in fact is illusory or impossible to achieve. "the economic sovereignty you claim to defend is a chimera" That said Alder Lake does open up a bunch of new possibilities and isn't an illusion
- fancyfredbot 4y agoIt's strange Agner seems so against this hybrid design despite the fact it's been proven to work so well for ARM. I'd agree this architecture is very difficult to optimize a single application for, but on the other hand he doesn't seem to consider whether it can lead to better performance and battery life in everyday use cases with mixed workloads using less than 100% of available performance.
- zaptrem 4y agoHe seems more annoyed about bad software thread management in Windows 11 (and none at all in Linux and MacOS) and that P & E cores have different instruction set support, which messes with apps.
- fancyfredbot 4y agoIt's weird to be annoyed by the difference in instruction set because by default they do have the same instruction set, and neither support avx512. You have to go to great lengths to enable avx512 on the P cores and as he says only certain motherboards can do it. I'll admit it is a shame that neither core supports avx512 by default though. If he'd said he was upset the gracemont E cores didn't emulate avx512 in microcode then I'd agree completely.
- TaylorPhebillo 4y agoARM big little uses the same instruction set on each core, right? You wouldn't have one 8.2 core and one 8.4 core?
- tux1968 4y agoAnyone else slightly annoyed that the CPUID had to be made the same for both P & E cores, just to accommodate DRM? Making it harder for all software to properly utilize the technology effectively.
- grishka 4y agoI feel like it's a fundamentally bad idea to give P and E cores disparate instructions sets. Apple did it right on the M1 — the cores have different designs, but the E cores support all the instructions the P cores do.
- colejohnson66 4y agoIt’s not just DRM; It’s about being homogeneous. If a process is on an E core and checks CPUID to see that AVX-512 isn’t available, it won’t execute those instructions even if AVX-512 was supported on a P core. As Agner said: > It is completely unrealistic that an application program can handle this situation in a reasonable manner and optimally allocate different threads to the different cores. A suggestion I saw here a lot was “pretend to support it, but detect attempts to use the instructions and pin the task to the P cores.” This would have issues with libraries like libc that would attempt to vectorize themselves and end up forcing an E core appropriate process onto a P core.
- mhh__ 4y agoAgner is very late to this one.
- nullc 4y agoEven more reason to not bother writing code for AVX512 support. Intel seems committed to having no advantage over AMD.
- gonzo 4y agoCalling Gracemont (the E cores) “Atom technology” is a bit weak. They support out of order execution and AVX2. Gracemont is faster, clock-for-clock than Broadwell and nearly as fast as Skylake running ChaChaPoly-1305, as used in WireGuard, largely due to avx2. Intel’s benchmarking shows 80% performance peak vs peak of 4C of Gracemont vs 2C4T of Skylake.