If you remember back to the mid 2000's when Apple switched from PowerPC to (Intel) x86, the higher end machines still ran with PowerPC chips in them while the mid-low end products had x86 chips. All of the old applications that weren't yet ported to x86 had to use "Rosetta." It wasn't until a little while later, presumably once most of the professional software companies had good working x86 versions of their software - that the high end mac pro systems started seeing Intel chips in them.
> It wasn't until a little while later, presumably once most of the professional software companies had good working x86 versions of their software - that the high end mac pro systems started seeing Intel chips in them.
The switch to Intel started six months [correction: seven months] from the announcement, and took seven months to complete.
June 5th, 2005: Intel switch announced at WWDC
January 10th, 2006: First Intel Macs (MacBook Pro and iMac) released
August 7th, 2006: Mac Pro and Intel Xserve released, last PowerPC Macs discontinued
There's two problems with that story: first, the famous switch from PowerPC to Intel happened when the desktop was the king, and app developers had strong incentive to recompile programs to the new platform. Right now? Not so much.
Second, while Apple's mobile processors are currently the best in ARM world, for "pro" desktop computers Apple needs desktop-grade processor. Making something comparable to i7 isn't such an easy and cheap job.
Adobe for one is making a boatload of money from CC subscriptions, record numbers, so I wouldn't worry too much about that (I imagine MS is equally happy with Office 365 on the desktop).
Besides, there's no Carbon to Cocoa or CodeWarrior to Xcode port, so aside from a very small percentage of optimized assembly code, it shouldn't be nearly as hard.
>Second, while Apple's mobile processors are currently the best in ARM world, for "pro" desktop computers Apple needs desktop-grade processor. Making something comparable to i7 isn't such an easy and cheap job.
It's quite impressive how many people in the comments can so easily come up with big show-stoppers that Apple never thought about. Must be why Apple is struggling financially and can't get anyone to buy their products.
> Second, while Apple's mobile processors are currently the best in ARM world, for "pro" desktop computers Apple needs desktop-grade processor. Making something comparable to i7 isn't such an easy and cheap job.
Qualcomm, NVIDIA, and Cavium have created very powerful ARM chips for non-mobile application. Apple definitely has the chip architects, the money, and the experience to do such a thing.
It matters to Apple, CPUs are a very big expense for them, and the performance of their computers are very important to them.
I'm specifically worried about the performance workstation/gaming cpu market, which Broadcom Marvell, Cavium, and IBM are not major players in. It's currently AMD and Intel. Apple would need to sell a lot of macs with the new CPUs to make the R&D cost worth it and the new CPUs would have to be very fast or they won't sell macs.
I remember all the way back to the early 90s and the original x86 emulator running on ARM. Admittedly that was before optimizations like JIT, and a lot of research has gone into binary translation since then, but it was a painful experience at the time. I wonder how much performance would be lost these days.
If they’re making their own CPUs, they can presumably add whatever additional functionality and/or instructions are necessary to make emulation or JIT translation work effectively.
But even if flat-out performance isn’t as good, what about if it proves cheap and easy to scale to more cores? Like, what if you get twice as many cores as the Intel equivalent has threads, albeit at 2/3 the speed (maybe worse or better for some workloads) but no hyperthreading-style contention? This wouldn’t be useless.
And GPU-accelerated functionality will be mostly unaffected.
the x86/x64 applications in the hypervisor would be super slow, as the x86 ones are with Windows 10 for ARM (Windows 10 for Arm doesn't support x64 emulation)
I see an article that is not congruent with actual tech facts. They can warn all they want, because the precedent says otherwise. Even if you wanted to make the argument that Intel is against emulation on non-x86 systems, that’s not true - see Virtual PC for Mac, FX!32, qemu, bochs and countless 8086 emulators to run VGA ROMs on various legacy free systems (either in OS or firmware). If you wanted to make the case that efficient emulation on non-x86 is is disallowed, well, FX!32, qemu and Virtual PC all used and use JIT.
Intel’s position amounts to cage rattling and vague insinuations that efficient execution of x86 code is impossible without hardware support. That’s nice, and their ham-fisted approach already hurt customer choice in the past (Transmeta and nVidia Denver, before the later implemented the Arm ISA) but the Windows on Arm solution is completely software and not coupled to any specific Arm chip implementation.
There's not really any real precedent other than people not being sued. That's more the complete lack of precedent rather than precedent that it's legal.
You know, the article refers to Windows ARM emulation, but I now see the Intel post as a warning to Apple, as patent licensing discussions may have started about that time last year.
It usually takes 4-5 years to design a chip, and if Apple planned on releasing the Mac CPU in 2020, well...
Microsoft started down that path last year with Windows 10 on ARM, and Intel had some legal issues with that - https://arstechnica.com/information-technology/2017/06/intel... It will be interesting to see how Apple handles this.