For what it’s worth, all of Intel’s chip fabs these days are oriented towards x86. They’re not really making anything else these days (aside from integrated graphics for x86).
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Qualcomm Claims Snapdragon X Elite 21% Faster Than Apple's M3 Chip
- Thread starter MacRumors
- Start date
- Sort by reaction score
Well, hold on a moment, the post you’re quoting made a very specific claim about hardware accelerated web browsing on Linux ARM. I don’t know what the answer to that particular claim is, but the existence of Linux on ARM doesn’t refute the claim. (I’d assume they do use hardware acceleration on Android, is there any reason that can’t be ported to normal Linux? Certainly, Google would want to add support for it if desktop Linux on ARM became a large enough platform that they couldn’t ignore it. Just because Google makes Android and ChromeOS doesn’t mean that they’d want to shortchange Chrome on ARM Linux to bolster Android/ChromeOS. After all, that would give folks a reason not to use Chrome.)Arch Linux ARM - Wikipedia
en.wikipedia.org
Ubuntu for ARM | Download | Ubuntu
Download Ubuntu Server for ARM with support for the very latest ARM-based server systems powered by certified 64-bit processors.ubuntu.com
Debian GNU/Linux Installation Guide
This document contains installation instructions for the Debian GNU/Linux 12 system (codename bookworm), for the 64-bit ARM (arm64) architecture. It also contains pointers to more information and information on how to make the most of your new Debian system.www.debian.org
So, as usual the issue will be device drivers for whatever computer they put the new chip into.
"Make" is a hard word to pin down... I think people are getting too caught up in words. Do you bake a cake, or does the oven? To make a cake you need a recipe creator, an assembler, and tools. Do any, all, or none of those participants "make" something?
It's like bragging my 1000 HP Audi is faster than your 200 HP Honda Civic. Like, obviously it's faster... lol.
Wake me up when Qualcomm has its own OS, software, and hardware platform that supports its chip efforts.
Will we get companies like Adobe and Blackmagic to add optimization to their software to support these chips? Hell, will Microsoft?
It's one thing to have a speedy chipset but, how will the rest of the hardware, OS, and software respond to it?
Will we get companies like Adobe and Blackmagic to add optimization to their software to support these chips? Hell, will Microsoft?
It's one thing to have a speedy chipset but, how will the rest of the hardware, OS, and software respond to it?
Intel shoveled their modems on the Intel fabs (probably not for the better) . And they moved a decent chunk of their FPGA work onto their own fabs after acquiring Altera. Intel has tried to diversify past just 'x86 chips' but they have been exceedingly clumsy at it ( along with dubious effort... and just play dumb mismanagement driving the process into a ditch. ).
There is progress.
Ericsson processors built on 'Intel 4' process node beat Meteor Lake to deployment
IDM 2.0 is finally getting somewhere.
And as of these new Meteor Lake (Ultra series ) SoCs ... the Intel fabs are not making the iGPUs. Using tiles/chiplets has opened up a window for Intel to outsource the production of the physical GPU to TSMC. ( which is 100% align with what they are doing with Intel dGPUs; for better or worse. )
It is not practical for Intel just to make just one relatively narrow product on a fab process and still stay in the fab business. Even Intel isn't large enough volume to amortize out the spiraling increasing costs for 'next , next gen' fab processes. Now that AMD has taken substantive share and Apple has flipped their share.... even more so. Intel has lost the volume to be able to keep their fabs busy enough just with internal work. They couldn't 'grow' volume bigger to get past the upfront costs. They need to spread R&D and infrastructure out over more products than what they sell.
Cool but it doesn't mean much until it's in actual machines, and isn't just emulating x86 apps.
The second one isn't particularly plausible because Apple has a non standard extension to the instruction set. The mode that Rosetta leverages isn't standard ARM opcodes. Apple has likely entangled exactly what they did into patents. So Arm isn't likely going to at it to their standard. And it more than a 'shim'.
Furthermore Microsoft's approach to compatibility thru 'emulation' is different. Microsoft has done backflips to get system where can mix and match x86 and ARM code together (e.g, have x86 plug-in work with Arm code app). Apple didn't try to do that at all. So the hardware assist that the Windows implementations need is substantively different.
AMX isn't standard. ProRes de/encoding isn't standard. And Windows is far more attached to the more standard alternatives to those. Since Windows has to support a wide number of system vendors it will likely tract the larger scoped standards; not Apple's proprietary quirks. Extremely unlikely Qualcomm is going to be the only long term Arm SoC for Windows. (not really true now , so not going to get more 'true' later.)
Someone may come up with a 'hack' that kind of , sort of runs a subset of macOS and apps that 'happens to work' if stay completely away from Arm deviations that Apple deeply leverages. It is likely going to more quirky that it is worth.
Until Microsoft fully commits to the ARM architecture, none of this truly matters.
As it stands, most Windows apps haven't been ported to ARM architecture, including Google Chrome, WhatsApp, and countless others.
Sure, you can run them through an emulator, but from dozens of reviews I've read, they often work slowly and/or unreliably.
What good is a state of the art ARM chip (and I doubt it'll be that good) when most software doesn't support it?
As it stands, most Windows apps haven't been ported to ARM architecture, including Google Chrome, WhatsApp, and countless others.
Sure, you can run them through an emulator, but from dozens of reviews I've read, they often work slowly and/or unreliably.
What good is a state of the art ARM chip (and I doubt it'll be that good) when most software doesn't support it?
Last edited:
Just for the record, I got an M3 Max MBP, and its fans are almost always off. When they do come on, it's usually at the lowest possible RPM and are still effectively silent (That happens when gaming). I've only managed to get them spinning with Blender doing some heavy duty work.
Last edited:
The answer is complicated, but your hunch is right: as of 2023, few people will benefit from a 32-core processor, or from 64 GiB RAM.
Part of the answer is that the OS has dozens of background processes running. From things like the kernel and WindowServer (the thing that draws the user interface) to system-wide features like spell check to background tasks like Spotlight disk indexing or Time Machine backups. Then, on macOS, there's also GUI apps that run in the background. All of that already makes a second core useful: even if your current app takes up 100% of the first core, all those background processes can move to the second core.
On top of that, Apple (and several others now, including Intel) has the concept of different CPU tiers; Apple calls this p-cores and e-cores (for performance and efficiency).* Most of the examples I named above? They don't really need a fast CPU core. They just need one to do some computation. So macOS will schedule most of those tasks to occur on e-cores, which not only makes them take up a lot less energy, but also means, again, that apps that do benefit from a fast core (a p-core) have more resources.
But as for whether your foreground app can actually make good use of many p-cores? That depends:
- what's the bottleneck? In reality, a lot of tasks these days aren't actually CPU-bound, but I/O-bound: they wait not for some computation, but for the SSD, or (increasingly commonly) for the network. Especially, of course, when you're on cellular.
- or, they're tasks that would be CPU-bound, but can actually be accelerated a different way: by having the GPU perform it. Or, perhaps, the Neural Engine. Again, that's very good, but it means your CPU cores are bored.
- finally, suppose they do run on the CPU. Then it's still a question of: can you actually parallelize them? Meaning, in layman's terms, can you split the task into say four smaller tasks of roughly equal effort, execute each of those on a different core, then when you're done merge the results back together and still have them make sense? Is that easy to program? Is the performance benefit big?
*) both Intel and Qualcomm have actually moved to three CPU tiers now. Perhaps Apple will follow suit.
They exist in the real world. Pretty good chance if you offered a Qualcomm employee $1B in untraceable cash for a prototype you could get one ( they'd 'loose' a prototype system and ship it to you). That is just not a price point you'd likely pay.
Being on the shelf at a Best Buy and existing in the 'real world' are two very different states.
The ramp to fab out a several hundreds of thousands of chips takes a while. There is lots of stuff that happens before Apple ships in volume. Apple just doesn't do alot of future promising while they are doing that. Qualcomm has to sell the chips to the system vendors who then sell to the customers. It just isn't the same product roll out.
Yeah that's crazy.80W to compete with M3?
M3 is like 20W when under heavy load IIRC
80W is estimated TDP of M3 Max
They're bragging about their 80W SOC beating a 20W ish SOC. Yay.
I'm confused where the ISA comes into play. The question was whether a different ARM SoC could boot macOS, and yes, barring some cryptographic mechanism on Apple's part that prevents boot from non-Apple chips, a shim to emulate their device tree is ultimately all it takes.
If your point is "but Rosetta won't run as fast", sure, OK. But that wasn't the question.
Backflips indeed. Like naming the x86 program files folder "Program Files (x86)", the x64 one "Program Files", and the ARM64 one "Program Files (Arm)". Yeah, I guess you could call that a "backflip". I'd go with "bad".
They didn't, but OTOH, you can simply have multiple architectures in the same binary, so it's not as important.
I'm unsure where Windows factors into this discussion.
What does ProRes have to do with the CPU?
There aren't that many deviations.
The assertions were: "Apple Silicon is custom designed by Apple. It’s NOT an off the shelf ARM SOC. There’s no way macOS will run on an ARM Hackintosh by another manufacturer."
Which, yes, Apple Silicon is a custom design. But so is Snapdragon X Elite. Neither are Cortex.
Speed in and of itself isn't something that would make me want to get a computer with that chip, if I ware a Windows user that is.
If we can’t buy it, it doesn’t exist. Numbers and benchmarks don’t matter on something you can’t buy. Apple might as well tout their M7 over these if that’s the case. Till people can buy it it’s just posturing.
Thanks.
Curious would you consider the upcoming Snapdragon 8 Gen 4 to be part of second generation of the X Elite since a key part of the IP will be integrated or used in the SD?
You know who could probably build a world class Arm implementation and also has access to the full x86 instruction set that they can Frankenstein into their architecture wherever it helps?: AMD
I'm just waiting for something to reach the light of day. It's probably not in their interest to upset the x86, er..., apple cart before they absolutely need to but I'm looking forward to seeing their approach when it comes out.
Comparable to M3 Pro @ 12 cores, slower than M3 Pro @ 16 Cores and M3 Max.
Considering the power draw is comparable to a Max, this is an underperforming chip.