Windows doesn't means x86.
And why a university ever care about what CPU you are running?
If your university's server running linux is supported. Every CPU that runs linux is already supported including ARM and MIPS and even RISC-V.
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.
Mac With Apple-Designed Arm Processor Coming in First Half of 2021
- Thread starter MacRumors
- Start date
- Sort by reaction score
Windows doesn't means x86.
And why a university ever care about what CPU you are running?
If your university's server running linux is supported. Every CPU that runs linux is already supported including ARM and MIPS and even RISC-V.
Desktop applications are a tiny percentage of the software market. Apple is happy to trade away compatibility with windows for compatibility with iOS.
In other words: Apple doesn't care if a few organizations with special needs stop buy macs, because many many more iOS device owners will more than replace them.
1. Yes. Using intrinsics in C++.
2. Pretty much every realtime physics library or fast noise library
3. Some do. BulletPhysics has a NEON (ARM's SIMD) pipeline as well as SSE4 and AVX2. Some don't. FastNoise is SSE2,SSE4, or AVX2 only.
While I do find Ming Chi Kuo has hit it on the head quite a few times, he's also missed a few or had to retract with an update.
I don't think Apple is really going to do this as much as people think they will.
What does make sense is a clamshell iPad if you want to call it a Macbook thats fine, but it's not an Intel replacement in the MacBook Pro, iMac & Mac Pro systems. If Apple is smart they should embrace AMD's newer Ryzen and Threadripper CPU's for the Pro series systems.
People forget ARM did try to enter into the server market a few years ago with a high end design: 32-core 3.3 GHz Arm server designed by Ampere. It was not as powerful as Intel or even the newest AMD CPU's running Linux.
I don't think Apple is really going to do this as much as people think they will.
What does make sense is a clamshell iPad if you want to call it a Macbook thats fine, but it's not an Intel replacement in the MacBook Pro, iMac & Mac Pro systems. If Apple is smart they should embrace AMD's newer Ryzen and Threadripper CPU's for the Pro series systems.
People forget ARM did try to enter into the server market a few years ago with a high end design: 32-core 3.3 GHz Arm server designed by Ampere. It was not as powerful as Intel or even the newest AMD CPU's running Linux.
What difference does it make what ARM couldn't achieve? Apple's ARM designs blow away ARM's.
I'm talking software, and it better have it, otherwise it would be useless. (it'll be slow, but slow is better than not running at all)
Kind of like Windows on ARM. I wouldn't own one, but it'd do in a pinch if it had some other selling point.
There are two parts to this discussion: PERFORMANCE and FUNCTIONALITY
With massive performance gains by APPLE with ARM chip performance, many users will be happily well served with “peppy”, limited performance ARM Macs
On the functionality side, it remains to be seen if ARM can handle virtualisation. And, there is little reason for to keep to one processor class: entry level machines could have ARM and prosumer Macs could have INTEL
With massive performance gains by APPLE with ARM chip performance, many users will be happily well served with “peppy”, limited performance ARM Macs
On the functionality side, it remains to be seen if ARM can handle virtualisation. And, there is little reason for to keep to one processor class: entry level machines could have ARM and prosumer Macs could have INTEL
Are you a game developer?
It's really hard to find a game developer building his own engine now so I almost forget about that.
I do aware about how useful SIMD is in those libs and how GPU acceleration is still not mature enough yet.
I guess if ARM on client computer took off they probably will be much better support for ARM.
Just like how software h264 encoding/decoding was optimized for ARM when mobile device need them back in the days without hardware ISP.
I'm curious about this on the Windows side as well, it seems for the moment ARM is quite attractive to Microsoft as their answer to Chromebooks - but if it does become popular and a competitive ecosystem develops for it, it could quite quickly eat into full ultrabook territory. If Intel are sensible they themselves are probably already experimenting with Arm CPU designs to hedge their bets, which would make all this even more interesting.
ARM can handle virtualization. Check AWS EC2 A1 Graviton.
And also Windows Hyper-V on ARM.
And also KVM on Linux on ARM.
Functionality was never a related topic for ARM. If Apple decide to drop virtualization it will drop them from Intel Mac also.
Last edited:
Apple saw most of its explosive growth after it introduced an ARM-based mobile device.
Wonder if this is related to the newest warnings on the newest Catelina beta? I received no less than 5 popups warning me about drivers / extensions that would no longer be supported soon, just like when 64bit came out. Worse part is, some would probably never be made compatible because they are for older products.
I think time will show the Catalina release is what's paving the way for an eventual ARM-based MacOS.
Intel did this already. It's called Xscale and that was a beast beating Intel's own x86 in low power scenarios.
Intel killed it and sold the remains to Marvell.
There's more to it than the Apple ARM magic. Yes Apple has done a good job with the ARM instruction set with their own chip design. Scaling it and emulation so Intel apps can run on it without loosing the performance is the area Apple needs to prove they can do. That why I said it doesn't make economic sense.
I totally agree, but I have trouble with thinking Apple can acheive massive performance increases. That's not easy, especially with a RISC architectures. You have to make it more CISC like in that it can do more than one instruction at a time (each core), or you need to make it more cores, and that has its own set of problems. Oh well, it'll be interesting at least.
Raspberry Pi's (3B and 4) already support a aarch64 virtualizing hypervisor.
"Useless" is an extreme overstatement. Most people don't need x86 compatibility.
From a quick google it looks like that was quite a time ago though - far removed from the situation today where it could realistically develop into a threat to their consumer chip business... seems sensible to me that they would be leaving their option to join them open if they can't beat them!
All Android ARM phones are virtualized (TrustZone). As I recall, one of the older iPhones ran under a hypervisor due to a security flaw.
I am leaning towards thinking that it will be an iPad with a mouse and somewhat better multitasking. They spin it as the ultimate replacement for a Macbook, with gaming (Arcade), video editing (iOS iMovie), office suite (Apple's and Windows 365) and of course some mobile version of Photoshop. Likely drop the touch screen. Just look at how many Apple apps have been iOS-ized and dumbed down for this purpose already.
I totally agree, but I have trouble with thinking Apple can acheive massive performance increases. That's not easy, especially with a RISC architectures. You have to make it more CISC like in that it can do more than one instruction at a time (each core), or you need to make it more cores, and that has its own set of problems. Oh well, it'll be interesting at least.
What craziness is this?
Doing more than one instruction at a time per core is NOT a "CISC"-like thing. Every RISC processor can do that (other than some toys in labs, or what not). Hell, in 1997 I designed hardware to enable that for UltraSparc V.
The difference between RISC and CISC has nothing to do with that.
The main differences:
1) CISC instructions are typically variable length, making decoding more difficult
2) CISC typically allows ALU instructions to directly modify or read from RAM, and has more complicated addressing modes, making instruction decode and memory access contention more difficult
3) CISC typically uses microcode to break down these complicated instructions into simpler RISC-like instructions. That requires a sequencer, Microcode rom, etc. The trade-off is: let the compiler figure out how to efficiently break a problem down, or let the CPU try and do it on-the-fly.
4) Most RISC instructions take the same amount of time. This simplifies pipelining, resulting in fewer pipeline bubbles (in theory)
5) RISC typically has more registers. This reduces the need to hit slow memory, but at the potential cost of higher penalties for context switching.
Only if they aren't ported, or aren't from the Mac app store. The software people use most will be available on ARM.