juanrga (nospam.delete@this.juanrga.com) on August 5, 2014 10:27 am wrote:
> Doug S (foo.delete@this.bar.bar) on August 4, 2014 8:01 am wrote:
> > juanrga (nospam.delete@this.juanrga.com) on August 4, 2014 2:05 am wrote:
> > > Yuhong Bao (yuhongbao_386.delete@this.hotmail.com) on August 3, 2014 2:24 pm wrote:
> > > > http://www.mondaynote.com/2014/08/03/macintel-the-end-is-nigh
> > >
> > > I expect Apple to switch about 2016 or so, when Xeon-class ARM SoC was
> > > ready; the mentioned 3GHz frequency for the 'A10' looks about right.
> >
> >
> > If they've been working on this for a few years, it could be ready tomorrow, so I don't know why
> > it would have to wait for the A10. It all depends on when the project would have started.
> >
> > I agree with those who are saying that Apple could design a much faster ARM if they were designing it
> > for running at up to 30 watts or so than the current one which is of course targeted at the iPhone where
> > they make most of their profit. I don't think they could get full x86 performance, but getting say
> > 75% of it (at the same power envelope) which is basically where AMD is should be attainable.
> >
> > However, I don't think the ability to run Windows can be so easily dismissed as Maynard Handley does in the
> > comments. I think they'd need to keep a real x86 CPU in the "Pro" line for business users. Especially now
> > with their deal with IBM that might help them finally penetrate the Fortune 500 market they shouldn't wish
> > to immediately rule out the Mac from consideration. The IBM deal is mainly focused on mobile devices, but
> > surely the hope is that it might lead to Macs used in the enterprise, but there is no way any large company
> > will go Windows free, so any Macs used there would have to be capable of running Windows applications. The
> > rest of the non-Pro line could go ARM only and run x86
> > via emulation. Yes, that's slow, but consumers would
> > generally have little need to run x86 apps, and those that they run would not be performance sensitive.
> >
> > How hard would it be for Apple to include a ARM and a x86 CPU in the same product, and have
> > them capable of running at the same time? The x86 would operate alone if you booted Windows
> > directly, but when booted into OS X the OS would run on ARM but Windows VMs or other x86 apps
> > would run on the x86 CPU. Is this feasible? Being able to run processes on two different CPUs
> > at the same time won't be easy, but perhaps the fact OS X uses the Mach microkernel would make
> > this slightly easier than it would be for Linux or Windows to attempt such a thing.
> >
> > The cost difference adding the ARM CPU could be made up by using a slightly less expensive x86 CPU, since
> > it wouldn't have the overhead of running OS X and could devote 100% of its resources to running x86 apps.
>
> They would wait to foundries 16/14FF high-performance nodes.
>
> I was considering a 100W SoC, when I mentioned "Xeon-class". Several companies have announced
> 90W ARM SoCs with throughput superior to 140W Xeons.

On paper. Somehow, no one of those "several companies" published industry standard benchmark results supporting their claims. SPECpower_ssj2008 would be the simplest and cheapest to setup, but I somehow don't expect that any of "several companies" will submit the score in the next year or 3. Claiming superior energy efficiency on paper is so much more convenient!

> Apple CPU division looks strong,
> I see no reason why they couldn't design a high-frequency version of Cyclone.
>
> I see no reason for using two ISAs. This would do the design very complex,
> and would be a waste of space just for running some legacy apps.
>
> I see Apple designing a Xeon-class SoC and using the extra-performance for running a x86 emulator for those
> brought to legacy x86 apps. Most of Apple customers would use native ARM apps by that time span.
>
> I read in some part about a new emulator providing about 80% of native x86 performance or something as that.
>

I wonder in what world you are living. Does not look like in ours.