251–260 of 263 posts
Earlier quoted context omitted.
Why does intel need to do this? x86 decode is a tiny, tiny part of the overhead of modern x86 CPUs. Architecture for the most part at this point doesn't matter unless you are talking about truly novel approaches like the Mill. Arm certainly is not a significant improvement.
It's more then just decode. Segmentation, x87 emulation, and the interaction with other features are all pain points.
Earlier quoted context omitted.
Why does intel need to do this? x86 decode is a tiny, tiny part of the overhead of modern x86 CPUs. Architecture for the most part at this point doesn't matter unless you are talking about truly novel approaches like the Mill. Arm certainly is not a significant improvement.
It's more then just decode. Segmentation, x87 emulation, and the interaction with other features are all pain points.
Plus, x86-64 basically disables both the things you list. Not that it matters because what is a flat fs/gs/etc register when there is another whole level of page tables for the hypervisor. AKA, you do the translation and store it in a TLB. If you really want to compare this, time how long a modern x86 takes on TLB misses, or for that matter how fast its TLBs are. I think you fill find that they are industry leading...
Same basic thing for the x87, its likely mostly powered down, and when active is probably feeding micro-ops through a SSE functional unit....
So the original posters comment is likely correct, and that has been known for a decade+. X86 if anything has a few accidental advantages, and the idea that its somehow "worse" than the alternatives are provably wrong.
Earlier quoted context omitted.
Intel needs to sacrifice Microsoft and make x86 a legacy architecture. The last time Intel did this it was called Itanium and it was horrible. Historically, almost all attempts to replace an enormously successful product line with something incompatible have failed.
> Historically, almost all attempts to replace an enormously successful product line with something incompatible have failed. Except AArch64, which has a legacy 32 bit mode for compatibility but is otherwise a totally separate ISA, unlike x86-64 and i386.
one example CPUID->MIDR
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/Bh...
https://developer.arm.com/docs/ddi0500/f/4-system-control/45...
The memory model is the same.. etc, etc, etc.
Earlier quoted context omitted.
Any examples?
Nvidia Tegra, all server ARMs, all Wi-Fi APs, higher-end embedded SoCs (e.g. Marvell), etc.
However, that still doesn't mean Intel will certify anything for Thunderbolt that doesn't use their processors. I still haven't seen any evidence of a certified Thunderbolt host device existing that doesn't have an Intel CPU.
Totally expected, because they need to increase performance and lower battery consumption. Now the extent of taking job from main Intel's CPU and spectrum of possibilities of ARM coprocessors are yet to be seen. I can see it doing some hardware related tasks that do not interfere with actual higher stack of macOS and x86 space. But this is all pretty common. This title looks little clickbaity imho.
I expect the same. Prior approaches to mixing architectures in one system and actually moving applications at runtime dynamically, as in big.LITTLE, were either far too complex to target or far too inefficient (1). I also don't see a technological enabler here, that would change anything about either. (1) - I can only imagine it with a virtualized ISA ala IBM. Still - even they didn't do that. The capabilities only e…
Earlier quoted context omitted.
It's not just about clock speed. While Intel Core CPUs don't scale down to power budgets as low as ARM cores, they are impressively efficient on a perf/watt basis. Smart phones achieve high battery life mostly by being very aggressive about reducing CPU load in software (see iOS killing apps the moment they go into the background). General purpose operating systems don't work like that so there's more reliance on the…
sounds like Intel hit a pretty sweet work/watt by increasing work while keeping lid on wattage. ARM delivers battery life by lowering work.
Earlier quoted context omitted.
Oddly, ARM is eating the PC architecture from the inside. What's on your raid card? An arm. What's in your usb devices? An arm. What's in your SSD? An arm. A PC is beginning to look like a network of arms with an intel driving. How long will the intel core last?
Intel margins in that single chip are probably a few orders of magnitude of ARM royalties on all those embedded CPUs combined. Intel has little to fear from those chips. On the other hand, Apple does seem to have the capability to design competitive desktop class CPUs, so who knows.
Earlier quoted context omitted.
I expect the same. Prior approaches to mixing architectures in one system and actually moving applications at runtime dynamically, as in big.LITTLE, were either far too complex to target or far too inefficient (1). I also don't see a technological enabler here, that would change anything about either. (1) - I can only imagine it with a virtualized ISA ala IBM. Still - even they didn't do that. The capabilities only e…
bit.LITTLE isn't a mixing of architectures, it's a mixing of micro-architectures. And the fact that big.LITTLE designs are commonly used now, and even Apple adopting their own version of it in their latest SoC is a validation of its benefits.