Every few months one of these types of editorials appears on AI. I call the same BS every time. Apple doesn’t need to use ARM in Mac. It’s not gonna shift their marketshare in any direction. Instead they are focused on making iPad more ‘Mac-like’. Witness the upcoming version of iPadOS.
All this makes for interesting hypotheticals, but it’s a non-starter IMHO...
A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow.
Also, people who are switching to Mac can still use the Mac as a PC if they need to. It provides a comfort blanket. As soon as Apple switched to x86, Mac sales took off.
I wouldn't call running Windows comfortable, not even in another universe. Its best to get rid of it. Running ppc apps under Rosetta was slow, very slow and some apps didn't run at all. Running CISC on RISC or vise versa isn't inherently more difficult. It isn't guaranteed to be symmetrical but that doesn't depend on CISC or RISC (this is nowadays an outdated distinction) or the number of instructions one or the other has. I would say that a 64 bit instruction set (or not) is a more important notion when translating instruction sets. The internal state of the processor and how easily it is represented on another (processor) is also an important notion. I would expect to see a difference in efficiency even per instruction. All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what. Current processors are extremely fast so a factor 5 or so will not be noticed when running most apps.
Edit: one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option.
But people have to use Windows to get work done on programs that aren't available on macOS. So you just say to all those who may rely on those programs for a living "sorry mate, you're out of luck. Goodbye"?
Rosetta wasn't great, but it wasn't particularly slow. Almost everything worked. Do you think then, Apple shouldn't bother with a compatibility layer if x86 > ARM happens, and just again, tell everyone who relies on some x86-only programs for a living that it's too bad, we're moving on and don't care?
RISC and CISC are still relevant when talking about processor emulation.
"All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what." Not that simple. Even if it was on average 5 native instructions per emulated instruction it would still be a huge performance hit. And as I said, it's more difficult to emulate the massive CISC x64 instruction set than it was the relatively concise RISC PPC one. There's also the endianness issue, which means every byte has to be flipped.
"one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option. "
That's because it runs at native speed in hardware. It's not software emulation. It still is at least one extra pipeline stage too.
Interesting speculation at the end about the future of computers. It could be that the CPU will be reduced to a kind of dispatcher with various coprocessors doing all the heavy lifting.
This is what I meant when I mentioned that Microsoft was helping to solve the boot camp issue. Theoretically, Window 10 on ARM would work for the desperate one or two occasional work apps some Mac users need, at least.
Windows on ARM is nothing! Tell me “Office ARM is ready” and create some enthusiasm. Any sign of Office ARM? Not emulated or crippled one, true native ARM compilation of that decades old legacy code.
Windows on ARM makes sense only as much as toaster-fridge convertibles make sense. Because it doesn’t exist anywhere else and probably never will...
A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow.
Hmm... “RISC” doesn’t mean smaller instruction set, it means that instructions are less complex and optimized to perform a more finite task. It basically means each instruction takes less cycles than what a CISC instruction would require, which might be much more “complex” in its execution.
It would be much easier for a RISC ISA to emulate a CISC ISA, because CISC instructions can be easily broken down into smaller instructions. In fact, Intel’s CPUs have RISC cores with a CISC front end to maintain compatibility. So even Intel takes their complex instructions and reduces them to a series of simpler instructions.
Man I wish I could find it agian.... but I'm sure in one of WWDC18 videos and Apple high level exec says something along the lines of "No Mac will ship with just ARM" Possiblely in the context of Marizpan not being a sign of merging iOS and MacOS. It was notable because of the Very Steve way of saying something. Doesn't rule out a combo or hybrid that might not include intel.
If Apple do an ARM Desktop or Laptop it's have new branding or at very least be part of expanded iPad branding.
Like iPhone should have X branding on every model for for the next phase of developement.
To those that want Intel for VMs or even to run Windows in Boot Camp (I do both), the answer is an Intel daughterboard or external box like an eGPU as an option, we had them before we can have them again.
Last time was when most used bulky desktops. It won't work when you're on the road or if you need that special app in a classroom. It will be super expensive and not very popular - just like last time. Apple could perhaps do some kind of Thunderbolt accessory but the current solution comes a zero cost. Any new setup will require software or hardware with cost and complexity. It all reduces the value of the Mac.
Not even close to realistic. Recoding and grandfathering apps just would not work. Apple needs to keep the eye on the prize. RISC vs CISC will go on for years to come. Light, powerful, durable laptops with extraordinary battery life are where the investment needs to be. Put a $750 dollar Macbook Air with good performance, decent storage and ram and you will own the student market.
Why so obsessed with turning Macs into facebook machines? I do prof software engineering work on mac and I need the x86 compatibility. Also I game on steam and not bubble popping iphone games.If apple doesn't like Intel, what about AMD or get an x86 license like Zhaoxin/VIA? Arm is for handhelds.
Mr. Dilger's article almost makes me feel sorry for Intel. Almost.
What's interesting about Intel isn't that they failed to recognize the corner they'd painted themselves into with the x86 architecture -- it's that they DID recognize, and tried to solve it, and failed. They tried to get into other chip fabrications like broadband, and failed. They tried IA-64, and failed. They tried the Atom, and failed. For broadband and Atom it became clear to the industry that Intel's solution wasn't good enough, but for IA-64 and Itanium Intel fell into the classic trap of having a superior product that others wouldn't invest in to use. Microsoft wasn't going for it and neither were the other industry leaders.
You'd think that someone at Intel would learn from all this failure -- Apple (well, really, Jobs, and to a fair extent Cook and Ive) certainly learned from failure, which is why we got the iMac, iPod, iPhone, Mac OS X, etc. Failure, if you survive it, is a good teacher. What has Intel learned? Darned if I know.
I think Intel hasn't got it anymore because they consist of managers (without a clue of course) only. Intels boss has no clue about technology and can only utter manager speak.
A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow.
Also, people who are switching to Mac can still use the Mac as a PC if they need to. It provides a comfort blanket. As soon as Apple switched to x86, Mac sales took off.
I wouldn't call running Windows comfortable, not even in another universe. Its best to get rid of it. Running ppc apps under Rosetta was slow, very slow and some apps didn't run at all. Running CISC on RISC or vise versa isn't inherently more difficult. It isn't guaranteed to be symmetrical but that doesn't depend on CISC or RISC (this is nowadays an outdated distinction) or the number of instructions one or the other has. I would say that a 64 bit instruction set (or not) is a more important notion when translating instruction sets. The internal state of the processor and how easily it is represented on another (processor) is also an important notion. I would expect to see a difference in efficiency even per instruction. All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what. Current processors are extremely fast so a factor 5 or so will not be noticed when running most apps.
Edit: one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option.
But people have to use Windows to get work done on programs that aren't available on macOS. So you just say to all those who may rely on those programs for a living "sorry mate, you're out of luck. Goodbye"?
Rosetta wasn't great, but it wasn't particularly slow. Almost everything worked. Do you think then, Apple shouldn't bother with a compatibility layer if x86 > ARM happens, and just again, tell everyone who relies on some x86-only programs for a living that it's too bad, we're moving on and don't care?
RISC and CISC are still relevant when talking about processor emulation.
"All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what." Not that simple. Even if it was on average 5 native instructions per emulated instruction it would still be a huge performance hit. And as I said, it's more difficult to emulate the massive CISC x64 instruction set than it was the relatively concise RISC PPC one. There's also the endianness issue, which means every byte has to be flipped.
"one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option. "
That's because it runs at native speed in hardware. It's not software emulation. It still is at least one extra pipeline stage too.
The point is that it is an instruction translation and when done in hardware you have little flexibility and room for logic so the translation scheme is simple which means easy to implement in software and with little overhead.
When Apples libraries are translated in advance, code will run at native speed when within the library (this can be an significant part of the apps runtime) (think of Rosetta). Its even possible to translate the app binary in advance which will improve performance even further. Of course if the source code is available, a recompile will make the app run native. Another way to run windows apps on Mac is to use Wine, its impressive to see what works nowadays. I expect Wine to be running on ARM (because Linux runs on ARM), so you can try this. Its also possible to ask the app developer to produce an ARM version of his software, why wouldn't he be willing to do that, especially because windows 10 runs on ARM now.
A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow.
Hmm... “RISC” doesn’t mean smaller instruction set, it means that instructions are less complex and optimized to perform a more finite task. It basically means each instruction takes less cycles than what a CISC instruction would require, which might be much more “complex” in its execution.
It would be much easier for a RISC ISA to emulate a CISC ISA, because CISC instructions can be easily broken down into smaller instructions. In fact, Intel’s CPUs have RISC cores with a CISC front end to maintain compatibility. So even Intel takes their complex instructions and reduces them to a series of simpler instructions.
Interesting speculation at the end about the future of computers. It could be that the CPU will be reduced to a kind of dispatcher with various coprocessors doing all the heavy lifting.
A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow.
Hmm... “RISC” doesn’t mean smaller instruction set, it means that instructions are less complex and optimized to perform a more finite task. It basically means each instruction takes less cycles than what a CISC instruction would require, which might be much more “complex” in its execution.
It would be much easier for a RISC ISA to emulate a CISC ISA, because CISC instructions can be easily broken down into smaller instructions. In fact, Intel’s CPUs have RISC cores with a CISC front end to maintain compatibility. So even Intel takes their complex instructions and reduces them to a series of simpler instructions.
But no, it is not easier for a RISC ISA to emulate a CISC ISA. There are less instructions in RISC architectures vs CISC architectures. which - as I said before, is why Rosetta wasn't that slow. CISC CPUs also have deep pipelining, making emulation even more complex. Good luck with "easily broken down" CISC instructions. They're complex and instructions interact with eachother, which is exactly why they can't be easily broken down.
Yes Intel CPUs are RISC at the core with a CISC interpreter now, because RISC CPUs are much easier to design and optimise because they're much simpler than CISC CPUs. By your own admission, CISC is complex, and RISC is simpler. Ergo, RISC is easier to emulate.
A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow.
Also, people who are switching to Mac can still use the Mac as a PC if they need to. It provides a comfort blanket. As soon as Apple switched to x86, Mac sales took off.
I wouldn't call running Windows comfortable, not even in another universe. Its best to get rid of it. Running ppc apps under Rosetta was slow, very slow and some apps didn't run at all. Running CISC on RISC or vise versa isn't inherently more difficult. It isn't guaranteed to be symmetrical but that doesn't depend on CISC or RISC (this is nowadays an outdated distinction) or the number of instructions one or the other has. I would say that a 64 bit instruction set (or not) is a more important notion when translating instruction sets. The internal state of the processor and how easily it is represented on another (processor) is also an important notion. I would expect to see a difference in efficiency even per instruction. All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what. Current processors are extremely fast so a factor 5 or so will not be noticed when running most apps.
Edit: one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option.
But people have to use Windows to get work done on programs that aren't available on macOS. So you just say to all those who may rely on those programs for a living "sorry mate, you're out of luck. Goodbye"?
Rosetta wasn't great, but it wasn't particularly slow. Almost everything worked. Do you think then, Apple shouldn't bother with a compatibility layer if x86 > ARM happens, and just again, tell everyone who relies on some x86-only programs for a living that it's too bad, we're moving on and don't care?
RISC and CISC are still relevant when talking about processor emulation.
"All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what." Not that simple. Even if it was on average 5 native instructions per emulated instruction it would still be a huge performance hit. And as I said, it's more difficult to emulate the massive CISC x64 instruction set than it was the relatively concise RISC PPC one. There's also the endianness issue, which means every byte has to be flipped.
"one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option. "
That's because it runs at native speed in hardware. It's not software emulation. It still is at least one extra pipeline stage too.
The point is that it is an instruction translation and when done in hardware you have little flexibility and room for logic so the translation scheme is simple which means easy to implement in software and with little overhead.
When Apples libraries are translated in advance, code will run at native speed when within the library (this can be an significant part of the apps runtime) (think of Rosetta). Its even possible to translate the app binary in advance which will improve performance even further. Of course if the source code is available, a recompile will make the app run native. Another way to run windows apps on Mac is to use Wine, its impressive to see what works nowadays. I expect Wine to be running on ARM (because Linux runs on ARM), so you can try this. Its also possible to ask the app developer to produce an ARM version of his software, why wouldn't he be willing to do that, especially because windows 10 runs on ARM now.
The inflexibility with hardware logic blocks has absolutely nothing to do with the complexity of a translation scheme, or how difficult it is to implement in software. Hardware FPUs for example are complex but fast. And software emulation of a FPU is excruciatingly slow. Hardware inflexibility does not mean hardware has to be simple. Logic blocks can be as complex as required and will always be faster than software emulation.
"When Apples libraries are translated in advance, code will run at native speed when within the library (this can be an significant part of the apps runtime) (think of Rosetta)." It doesn't work like that. You can't link to libraries across different architectures.
If you think WINE could run on an ARM Mac that proves your limited understanding of the subject. WINE = Wine Is Not an Emulator. There is no emulation whatsoever. Despite your self proclaimed "Knowitall"... you don't.
Comments
All this makes for interesting hypotheticals, but it’s a non-starter IMHO...
Rosetta wasn't great, but it wasn't particularly slow. Almost everything worked. Do you think then, Apple shouldn't bother with a compatibility layer if x86 > ARM happens, and just again, tell everyone who relies on some x86-only programs for a living that it's too bad, we're moving on and don't care?
RISC and CISC are still relevant when talking about processor emulation.
"All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what." Not that simple. Even if it was on average 5 native instructions per emulated instruction it would still be a huge performance hit. And as I said, it's more difficult to emulate the massive CISC x64 instruction set than it was the relatively concise RISC PPC one. There's also the endianness issue, which means every byte has to be flipped.
"one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option. "
That's because it runs at native speed in hardware. It's not software emulation. It still is at least one extra pipeline stage too.
Windows on ARM makes sense only as much as toaster-fridge convertibles make sense. Because it doesn’t exist anywhere else and probably never will...
Already run into compatibility issues with Windows tablets not able to print from ARM CPU's.
Not enough printers support ARM drivers yet, although this could possibly spur manufacturers to build ARM drivers for their machines.
Still this won't happen for older devices - they won't put the resources into it.
Hmm... “RISC” doesn’t mean smaller instruction set, it means that instructions are less complex and optimized to perform a more finite task. It basically means each instruction takes less cycles than what a CISC instruction would require, which might be much more “complex” in its execution.
It would be much easier for a RISC ISA to emulate a CISC ISA, because CISC instructions can be easily broken down into smaller instructions. In fact, Intel’s CPUs have RISC cores with a CISC front end to maintain compatibility. So even Intel takes their complex instructions and reduces them to a series of simpler instructions.
Intels boss has no clue about technology and can only utter manager speak.
When Apples libraries are translated in advance, code will run at native speed when within the library (this can be an significant part of the apps runtime) (think of Rosetta).
Its even possible to translate the app binary in advance which will improve performance even further.
Of course if the source code is available, a recompile will make the app run native.
Another way to run windows apps on Mac is to use Wine, its impressive to see what works nowadays.
I expect Wine to be running on ARM (because Linux runs on ARM), so you can try this.
Its also possible to ask the app developer to produce an ARM version of his software, why wouldn't he be willing to do that, especially because windows 10 runs on ARM now.
But no, it is not easier for a RISC ISA to emulate a CISC ISA. There are less instructions in RISC architectures vs CISC architectures. which - as I said before, is why Rosetta wasn't that slow. CISC CPUs also have deep pipelining, making emulation even more complex. Good luck with "easily broken down" CISC instructions. They're complex and instructions interact with eachother, which is exactly why they can't be easily broken down.
Yes Intel CPUs are RISC at the core with a CISC interpreter now, because RISC CPUs are much easier to design and optimise because they're much simpler than CISC CPUs. By your own admission, CISC is complex, and RISC is simpler. Ergo, RISC is easier to emulate.
The inflexibility with hardware logic blocks has absolutely nothing to do with the complexity of a translation scheme, or how difficult it is to implement in software. Hardware FPUs for example are complex but fast. And software emulation of a FPU is excruciatingly slow. Hardware inflexibility does not mean hardware has to be simple. Logic blocks can be as complex as required and will always be faster than software emulation.
"When Apples libraries are translated in advance, code will run at native speed when within the library (this can be an significant part of the apps runtime) (think of Rosetta)." It doesn't work like that. You can't link to libraries across different architectures.
If you think WINE could run on an ARM Mac that proves your limited understanding of the subject. WINE = Wine Is Not an Emulator. There is no emulation whatsoever. Despite your self proclaimed "Knowitall"... you don't.