I also recommend this written article about this topic: Arm vs x86: Instruction sets, architecture, and all key differences explained - www.androidauthority.com/arm-vs-x86-key-differences-explained-568718/

The biggest problem that x86 has are its strong guarantees. Every CPU architecture gives programmers implicit grantees. If they require guarantees beyond that, they have to explicitly request those or work around the fact that they are not available. Having lots of guarantees makes writing software much easier but at the same time causes a problem for multicore CPUs. That's because all guarantees must be uphold across all cores, no matter how many there are. This puts an increasingly amount of burden on the bus that interconnects the single cores, as well as any shared caches between them. The guarantees that ARM gives are much weaker (just as the ones of PPC and RISC-V are much weaker), which makes it much easier so scale those CPUs to a bigger amount of cores, without requiring a bus system that needs to become drastically fast or drastically complex, as such a bus system will draw more and more power and at some point become the bottleneck of the entire CPU. And this is something Intel and AMD cannot change for x86, not without breaking all backward compatibility with existing code. Now as for what "guarantees" actually means, let me give you some examples: If one core writes data first to address A and then to address B and another core monitors address B and sees it has changed, will it also see that A has changed? Is it guaranteed that other cores see write actions in the same order they were performed by some core? Do cores even perform write actions in any specific order to begin with? How do write actions and read actions sort towards each other across cores? Do they sort at all? Are some, all, or none of write actions atomic? Over 99% of the time none of these questions matter to code that you write, yet even though less than 1% of all code needs to know the answers to these questions, the CPU has to stick to whatever it promises 100% of the time. So the less it promises, the easier for the CPU to keep it and the less work must be invested into keeping it. When Microsoft switched from x86 in the fist Xbox to PPC in the Xbox360, a lot of code broke because that code was not legit in the first place. The only reason why this code was working correctly so far were the strong guarantees of the x86 architecture. With PPC having weaker guarantees, this code would only work sometimes on these CPUs, causing very subtle, hard to trace bugs. Only when programmers correctly applied atomic operations and memory barriers, as well as used guarded data access (e.g. using mutexes or semaphores), the code was still working correctly as when using these, the compiler understands exactly which guarantees your code needs to be correct, and knowing for which CPU you are compiling, it also knows whether it has to do something to make your code work correctly or whether it will work correctly "on its own" as the CPU gives enough guarantees for that, in which case the compiler will do nothing. I see code every second day that only works coincidentally as it's being used on a CPU that has certain guarantees but this very same code would fail on other CPUs for sure. At least if they have multiple cores, there are multiple CPUs in the system, or the CPU executes code in parallel as if there were multiple cores (think of hyper-threading). The guarantees of x86 were no issue when CPUs had a single core and systems had a single CPU but they increasingly become an issue with the number of cores rising. Of course, there are server x86 CPUs with a huge number of cores but take a look at their bus diagrams. Notice how much more complex their bus systems are compared to the consumer x86 CPUs? And this is an issue if you want fast CPUs with many cores running at low power, providing long battery life and not requiring a complex cooling system or otherwise will run at very high temperature. And cores is currently the easiest way to scale CPUs, as making the cores run at higher speed is much harder (the clock frequency of CPUs is currently usually below what it used to be before all CPUs got multicore) and it's even harder to make the CPU faster without raising clock frequency and adding more cores as most optimizations possible have already been done. That's why vendors need to resort to all kind of trickery to get more speed out of virtually nothing and these tricks causes other issues, like security issues. Think of Meltdown, Spectre, and Spectre-NG. These attacks used flaws in the way how optimizations were implemented to make CPUs faster without actually making them faster, e.g. by using speculative execution, so the CPU is not faster but it still can perform work when it otherwise couldn't and it it was doing the work correctly, it appears to be faster. If what it has just done turns out to be wrong, though, it had to rollback what it just did and this rollback was imperfect as they didn't clean up the cache, thinking that nobody can look directly into it anyway, so why would that matter? But that assumption was wrong. By abusing another of these tricks to make CPUs faster, branch prediction, it is possible to reveal what is currently cached and what isn't and that way software can get access to memory it should never have access to. So I think the days of x86 are counted. It will not die tomorrow but it will eventually die as in many aspects x86 is inferior to ARM and RISC-V who both give you more computational power for less money and less electric power and this is not a temporarily thing, as no matter what trickery and shrinking they are going to apply make x86 faster, the same trickery and shrinking can also be applied to ARM and RISC-V to make them faster as well, yet on top of that, it will always be easier to give them more cores as well and that's why they keep winning in the long term.

Nice to hear from someone who actually knows what they are talking about. Not for the sake of making youTube content.

I stopped midway saying to myself, why I feel like I was tricked into a college lecture and not noticing it except midway but still liking it

There are thousands of useless videos "Apple moving to it's own silicon!!!"...but this is the only video that is actually informative.

Struggled to find someone who can actually explain something as complex as Arm v x86 in such straightforward terms. thank you.

Nobody can explain it better than you. Thanks for packing it all under 21 mins. I know it's tough.

Just to give a feedback: The pronunciation of the name Dobberpuhl was perfect.

Gary, you’ve been there and done that ⭐️

The possibilities for how this will go and how it will effect the industry or other players in said industry is endless. Very interesting next few years for numerous reasons, this being a big one. Great vid too btw.

Hey gary, your videos are awesome. I am waiting for some more rust videos. Last rust video helped me to get started in rust lang.

Subbed. Just straight up information easily explained. Love it

Absolutely beneficial I learned a lot. I still have a lot more learning to do. Definitely subscribed and will be pulling up other videos that you’ve done for additional information.

Thank you! You get extra points for mentioning Elite - I played that so much on a Commodore 64 when I was around 16

In your slide listing the major differences in RISC v CISC, one thing that struck ME as relevant because of my interest in compilers and which admittedly may not be particularly worth mentioning depending on your audience, is that RISC instructions also tend to be more uniform in the sense that if you want to do an add instruction, for example, you don't have to really think about what instructions are allowed with which registers. Also, the instruction pointer register is just a regular general purpose register while that register is often special purpose in other architectures. It's awkward and roundabout to even access. Often you need odd tricks like to use Intel's call instruction as if you're calling a function for its side effect of pushing the instruction pointer to the stack. Then from there, you can pop the value off. But in arm, you just have it in one of your normal registers. Obviously, you must beware if you dump random garbage into it that you'll start running code from a different place in memory but that should be obvious. Yet such uniformity can eat space and so the THUMB instructions don't have it.

My cat: trying to catch the red dot.

My father was working for DEC at that time, and he told me a lot about the Alpha chip and their foray into 64bit before AMD and Intel brought their consumer 64bit chips to market. He also told me about the purchase by Compaq(and subsequently HP) and that a lot of people weren't keen on the purchase as there was concern all their efforts would disappear. These days DEC is barely a whisper when people talk about tech history, but I still remember sitting at an ivory CRT with the red 'DIGITAL' branding on it. Edit: Thanks Gary for the little nostalgia trip.

Wow I learn a lot just from watching your video, thanks Gary :)

Gary is arguably the best person to explain these kind of topics in layman's terms. Intel will finally get some humolity lesson.

Great overview and explanation of the current situation. Very helpful.

I was afraid in the beginning that all I'll hear is history but I'm glad I watched til the end the answers to my questions were answered.

This video is so underrated like lol you explained something I was never able to understand in just 20 minutes

Really great to hear someone who knows about Acorn. In 1986 I lived in North-western Ontario (Canada). Our library put in a desk with 6 computers on it. They were the North American version of the BBC Micro, made by Acorn. It was the first computer I worked on. I didn't find out about the ARM chip and the Archimedes until the mid nineties. And it was shortly after that time that ARM was spun off. BTW, Acorn was owned by Olivetti at this time. When I found out about the Raspberry Pi, I got onboard. I had a model A chip, and then I bought a Pi 4 just in time for Covid, so I could use my camera module to have a second camera for Zoom.

Brilliant ✌️ Thank you for making sense of the current silicon architecture challenges 👍

I understood Intel was a memory maker initially however a Japanese company commissioned intel to develop its calculator chips that ultimately developed into microprocessors

I've got an impression memory is (relatively) slower and more expensive TODAY than back then. Then - in the early 1980s - performances of RAM and CPUs were not far apart, so CPUs were not that handicapped by RAM - they could fetch instructions directly and remain fully utilized. Today it is different: RAM is much, much slower than CPU, so CPUs spend a good part of their transistor budgets on internal multilevel caches. Whereas on modern systems you can have 128 GB of RAM or more, the one that actually matches your CPU speed is the L1 cache which is tiny - Ryzen 5950x has only 64 kilobytes of L1 cache per core (32 kB for code and 32 kB for data). I would say the instruction set "density" is even more important now.

Excellent overview! WIth the CPU race on at the moment, it would be great to have an updated version of this video in around 6 months from now 😊

I'm an ex-DECie tech guy too. Glad to see someone helping to explain their place in history. All these years later, I'm still heart broken.

This was absolutely fascinating. Thank you!

I am a simple man . I see gary, I like the video

Gary, you explaination is smooth like butter!

Many thanks Gary and appreciate your effort and time to research on the contents in this video.

I was waiting for this video. Thanks

*GARY!!!* Good Morning Professor!* *Good Morning Fellow Classmates!*

Very nice video and full of details! Keep those coming!

@Gary Explains Very educational. Thank you for this.

Very rich in details this video as usual, thank you 🙏🏾 Gary.

So what would be any arguments in favor of the Intel (or X86 in general) side of the situation?

Very informative Gary. Cheers!

Its like going to a seminar but for free! Thanks a bunch.

Silly question : why haven't we uses ARMs processors in PC before ??

It is interesting how the CISC vs. RISC battle has evolved with Intel's CISC holding the lead for many years. Unfortunately, Intel rested on its laurels by keeping the 8086 architecture and boosting its operating frequencies while reducing the chip size production down in nm levels. Thermal limits with this architecture have literally been reached giving Apple/ARM the open door with their approach which now after many years has surpassed the 8086 architecture. It will be interesting to see how Intel reacts given their hegemony control of the market.

Was looking for such a vid. Nice.

Gary you are awesome. I had no idea Xscale was off the back of arm. So much history.

surpised you didn't mention the softbank acquisition. all my arm stock got paid out when that happened and it kinda surprised me. totally thought I'd just get rolled over into softbank stock.

The big problem of Intel is that they invested heavily in branch prediction. And it was a wise move. Their single core performance was really great but then Spectre and Meltdown happened and they had to shut down the biggest improvements. Their rivals AMD or ARM invested more in multicore processors. They aren't affected by these vulnerabilities and so Intel has a lot of catching up to do.

Tanx Gary you are my favorite IT teacher

Great job Gary.

And everyone thought Acorn was finished when it's RISC Archimedes computer flopped...

Sir ! When will ARM v9 arrive ? Are there any dates or assumptions ? What will be it like ?

Best video on this topic by far

Great explanation, really enjoyed it!

Everyone comparing ARM and Intel, no one talking about ARM and AMD Like the Ampere Altra(80 core) VS EPYC 7742(64 core). Ampere is 4% more powerful, and uses 10% less energy making it 14.4% more efficent than AMD. But some people might point out that for AMD to compete with an 80 core, they have to pump more power into their 64 core which uses disproportunately more energy, than poerformance it improves, i'll be REALLY interested to see how a fully 7NM AMD EPYC where that space savings from a 7nm IO die instead of 12nm makes room for two more 8 core CCDs for a total of 80 cores. Some might argue, that if AMD had used a fully 7nm processor and had 80 cores, they would be not only more powerful, but also more efficicent(less energy for that power)

My brain has been itching for few years now whenever I hear ARM vs Intel, but I was too lazy. Finally everything is flushed and cleared out.

This is an EXCELLENT review for some one who programmed with an Intel 4004 way back when. Thank you so much. Regards, RJM

Thanks for the whole story that was awesome.

The last school project I did was on the development of Elite. Such a cool game! Also, planet Arse.

Mean while when we could expect to see risc-v isa based smartphones and PCs. If someone would be bring out high performance , Out of order, deeper pipeline, multi threaded risc v processor then it might give tough competition to ARM

Love your videos as always 👏🏻

Brilliant, thanks Gary

10:52 *Apple

Now we all know where Garry's knowledge of IC's come from... :)

Very interesting presentation. Many thanks Gary.

Thanks for the video, if I use Windows ARM on Macbook (via Parallel) can I download windows app from any source? Or does it have to be from the Microsoft Store only?

I grew up using the 8088 in engineering school and upgraded my PCs along the way. I worked for Intel for 20 years after they acquired the multiprocessor company I worked for. I got rid of most of their stock after I stopped working for them and I saw the future in mobile. These days, my W10 laptop sits barely used while I'm perfectly happy with a $55 Raspberry Pi hooked up to my 55" TV. Each time I use my W10 laptop it seems to be doing some scan or background tasks that take up most of the CPU cycles. Old Dinosaurs fade away.

I can already imagine the videos in a few years "The fall of Intel"... Sad...

Absolutely brilliant video. Thank you for sharing

Thanks Gary.

nanometer litrography doesnt mean anything when comparing 2 CPUs from different manufacturers because they define what they mesure as litography differently, aka intel CPUs will have more density of components at the same litograpjy size and even 1 size smaller from another manufacturer like tsmc

Hey what do you think about RISC V Macro op Fusion and its importance for RISC V to eventuall replace x86 and ARM for open sauce (maybe)

Excellent gary thanks for the great videos

Very smart and detail explanation. Thx Gerry

Finally someone knowledgeable ❤️ thanks for sharing this information with us.

Hello gary can you make some videos on operating system but at the lower kernel level how things work, bootstrap,how drivers interact,how gui is build on the top of windowing system

That’s a great lecture, Sir. Thanks

Great update 👍 Thanks for sharing 👍😀

it may have been worth mentioning the NEON extension for ARM in more detail, as it is in essence what MMX was for the pentium - Hardware decoding of h264 data streams among other things. (relatively speaking)

Brilliant explanation of x86 vs risc architecture.

Thank you so much for this video 👍🏻👌🏻✌🏻

Thanks. Very informative

Its cool that gary takes time to read and replies to sensible comments here even if his video is uploaded months or even a years ago. Other channels dont do that.

Thanks Gary!

Great video! How powerful do you think Apple GPUs are going to be? Do you think they're going to compete with a 2080 ti?

Nice video and thanks to Mr Gary for the enlightenment .

HPE also has a system based on the Fujitsu A64FX chip. Well, it was announced as the Cray CS500 but will now be marketed as the Apollo 80.

80286 had segmentation, but it did not have paging. I think OS/2 would smoke a cigarette waiting for segment swaps. 80386 had segmentation swaps and paging. Paging was the what the engineers wanted. Beefier MOBO chips were needed to support DMA while the CPU continued to execute code. 8086 machines smoked during the DMAs with DOS.

Do you think Apples new Mac ARM SoCs are based on ARMs Neoverse N1 or better yet E1 architecture? Because all the other ARMs chips before were based in a cluster sizes up to a maximum of 4 cores. The E1 can have a cluster up to 8 cores. The N1 can have clusters from 8 cores up to a maximum of 16 cores.

Gary, I wonder if you could design a speed test like the one you made for the new and old cpu but for the arm mac when its released

Hey Gary, I'd like to know more about how Metal, Vulkan and OpenGL works differently. Can you make a vid about it? Your vids of how things work are very informative.

Great video Gary

Hi great video. I'm wondering if you ever run low on content, could you cover the very interesting history of the Datapoint 2200? I know pretty nuch everybody would disagree with this assertion, but in my nind it is the first fully contained "Personal Computer".

Nice explanation. However, I would like to know why did Apple have to base its processor architecture on ARM if it was designing it's own custom architecture? Is it because they needed the ARM instruction set? If yes, couldn't they make their own instruction set? Or that is a very long process?

3:03 Small Correction -- Itanium, at launch did not have x86 backward compatibility. Later on an x86 software emulation was made but it was too slow.

what about RISC-V? heard it is quite different from the ARM architecture.....

Thanks for converting those complex documentations into understandable English for plebians like me! Interesting things I've learnt so far: * AMD made direct Intel clones in the beginning. * Intel is forced to use AMD's 64bit. implementation because they couldn't develop their own successful one. * Intel has made ARM chips and has a license for ARMv6, but sold its ARM division off. * Apple had a much longer history with ARM than I expected. * Imagination went bankrupt so Apple bought lots of their IP and developed their own GPUs from there. * Apple was the first to incorporate 64bit into smartphones.

Talking about porting of apps from programmer perspective: can x86 to ARM shift be done automatically? I've read many comments pointing that Apple moving to ARM might have some problems with actually convincing app developers to move to ARM. Apple is also offering special ARM based prototype computers for programmers just for testing so they could be ready for release of ARM Mac. Why is that? Isn't that a matter of simple app recompilation? Can't Apple do that automatically for apps in its store?

what is the program used for the laser sight ?

Have you made a vid on Marvel's Thunderx3/latest chip and how it got from xscale to current design???

Hi Gary, Does this mean that Intel will create a straight up RISC processor to compete with Apple M1 chip? Better speed to power ratio?

Great video! Thank you.