S|A: (rumour) Apple dumps Intel from laptop lines

[Voo]

What is it about the iPad that generates such ignorance?

Why don't you people just go play with one at an apple store? You quite obviously have no idea what it does or what it is for.

You completely missed the point. This discussion is not about tablets or what amount of performance is enough for average joe in particular. It's about the advantages/disadvantages of different ISAs.
And at the moment about your claim that an ARM cpu magically will lead to much more even battery drain which is simply wrong. The only reason why the current ARM cpus are so power efficient is because they're several leagues lower in performance AND a lot of stuff is done with fixed function hardware.

As soon as you produce a ARM CPU with comparative performance to a modern x86 CPU and give it a similar work load, it will at best be a few percentage more efficient - a HUGE difference from your claim of about the same battery life independent of the work load, which is just physically impossible (although in the long run with static power consumption becoming more and more important on smaller process nodes we're getting in that direction, but then Intel's not the only one working on minimizing that)

 

[drizek]

ARM doesn't have to be comaprable in performance to modern X86 CPUs to be used on a laptop.

The iPad 1 now has iMovie and GarageBand ported to it, and GB on the iPad 2 was very smooth for me. There is a performance threshold that you need to reach where after that it doesn't matter any more. You don't need Sandy Bridge to run Excel, it works just fine on a Pentium from 1995. Are you doing more complex stuff than 90% of people? Don't buy a mac laptop then.

 

[IceRedwing]

The purpose of a tablet is consumption not media editing/creation.

that is stupidly short sighted

 

[Voo]

ARM doesn't have to be comaprable in performance to modern X86 CPUs to be used on a laptop.

Soo. After all your other claims were refuted we're now down to "An ARM cpu will be much more powerefficient than a x86 one if it doesn't do the same amount of work"? Well doh, really? Who'd have thought that. How you want to generalize that statement to other devices (notebooks, desktops,..) where they'd have to do similar work loads, I'd love to hear. And how this would exclude Intel or whomever from releasing a low power x86 CPU also isn't clear at all.

 

[drizek]

I don't think we will see arm on desktops any time soon.

It doesn't exclude intel from trying.

The only thing that matters is that arm will continue to get better idle battery life than intel. I wasn't saying that an arm chip necessarily will give more consistent battery life, but that a low power chip in a large system will, and used the iPad as an example of that.

The MacBook air could easily handle a 1.5GHz quad core arm. And no, you wont be running physics simulations on it.

 

[Voo]

The only thing that matters is that arm will continue to get better idle battery life than intel.

And here we go again. No idea where you get that notion. If ARM built a similarly complex CPU as a modern x86 it wouldn't be much more power efficient idle - actually with Intel having the most experience with power gating and the fact that with something like the SB opcode cache the decoder (and that's where most of the additional power inefficiency lies) can also be shut down in such a situation, that's quite unlikely.

If you want to argue that low power chips are fine for lots of situations - fine, that's something completely different and for devices such as smartphones or tablets many people would agree (although for many notebook usage scenarios the situation looks different). But don't bring the ISA into play except if you have some good arguments for your assumptions..

 

[drizek]

No, I don't know very much about the architecture in detail, but even the most superficial observation will tell you that Arm devices idle a lot longer than x86 ones do. Most ARM systems don't even have a readily available off position at all. Back in the day, PDAs would even store data in volatile memory. They are designed to remain on for weeks at a time when idle.

Why would ARM want to build a CPU like X86? They quite obviously have something that works already. You mention complexity as an advantage of X86, but nobody cares about complexity, it's about actually doing what people need it to do. My Atom netbook can't decode 720p .mkv video. My iPad 2 can (and 1080p as well, I think) and so can my Galaxy S phone.

 

[Voo]

Sigh, I think the only thing that would help here would be an introductory EE course. But well one last try.

Why would ARM want to build a CPU like X86? They quite obviously have something that works already. You mention complexity as an advantage of X86, but nobody cares about complexity, it's about actually doing what people need it to do. My Atom netbook can't decode 720p .mkv video. My iPad 2 can (and 1080p as well, I think) and so can my Galaxy S phone.

Your ARM cpu ISN'T decoding the 720p video stream and would fail just as miserably as a first gen atom. And no I don't mention complexity as an advantage of x86, I'm mentioning PERFORMANCE as an advantage. Sadly with higher performance comes higher complexity. Just look at ARMs first cache implementations and compare them to x86 or newer ARM CPUs (well probably read up on virtually/phyiscally indexed/tagged caches beforehand if you're interested otherwise you'll have to believe me there)

Sure if you don't need more performance than a simpler ARM CPU can offer, then there's no reason to use something more powerful - but then the same is generally true. All your statements can't be generalized to "ARM CPUs are better than x86s at XYZ" only to "For those specific usage scenarios where we only need this much performance a simple CPU will need less power and still get the work done".
Which doubtlessly is true, but from a computer scientists position that's hardly interesting. Now having a good estimate how much more efficient an ARM cpu could be compared to a similar powerful x86 CPU on a similar node - well, that'd be something else.

 

[drizek]

I know that he cortex core is not decoding the video, but the SOC is. If you want to do the same on Atom, you need a dedicated broadcom chip(that probably uses more power than an entire SOC).

I'm not a computer scientist, I'm a consumer, and, to me, ARM is very interesting. ARM SOCs enable form factors that X86 can't compete with, regardless of performance. You won't deny that the upcoming ARM quads are at least competitive with Intel Pentium Ms, right? But Intel simply cannot manufacture a 1.7ghz dothan, on any node, that can fit inside an iPad and idle for a month. Maybe the Cortex architecture itself isn't all that special, but is there such a thing as an X86 SOC that can compete?

I think that, for Apple, using ARM SOCs on some of their laptops is viable in the near future. It will allow them to ship products that they can't ship with X86. You make a lot of sacrifices with ARM, particularly in terms of performance as well as upgradability, but if there is one company that couldn't give half a damn about either of these things, it's Apple.

 

[Cerb]

What happens if the Atom runs at 100MHz, and implements aggressive power-gating? What about allowing the CPU to entirely turn off, until needed by some other unit? Give the networking, storage, etc., controllers, their own teeny processors to manage what they do when idle, so that the CPU can turn on for seconds at a time, but have only a 1-2% duty cycle when idle.

I don't think there are any easy solutions, but this is Intel, and they seem to be willing to get into the mobile market at any price, to make sure they don't get stuck outside of it, if/when it gets to be too late. They could bank on dynamic power consumption becoming so small that ARM has no real advantage, anymore; but that is a big risk, if someone can find a good way to mitigate that future.

And, most people deal with phones that idle for a week or two, and get by just fine. Intel can manage with higher idle power, but not orders of magnitude higher idle power.

Finally, can Intel, on their fabs, give others the ability to make their own SoCs? Without the process advantage, ARM's idle power is just too good, but with their process, it's also their fabs, and so they would need to either open them up, at least to some degree. Their success would be guaranteed to be limited, if market targeted SoCs could not be made to spec by/for 3rd parties, when 3rd parties can do that with ARM (for 3rd parties would be interesting).

You make a lot of sacrifices with ARM, particularly in terms of performance as well as upgradability

Not upgradability. That is a legacy computer feature, and not something common on mobile devices. If Apple were looking to use x86, in otherwise the same system, you have just as little room to upgrade, or just as much.

 

[Blitzvogel]

x86 is stuck in legacy design for compatibility, though I hear cutting out the legacy bullshit and go with x64 only CPUs could help cut some of the fat.

 

[drizek]

I think it's telling that the only thing people seem to think Intel brings to the table is their process.

I'd like to think that competition between TSMC and GloFlo makes both companies much more aggressive in terms of their R&D and process roadmaps.

Think about it, the first 1GHz phone, the first dual core phone, the fist quad core phone, etc. is a huge marketing win. GloFlo and TSMC would both love to be able to offer that to their customers, and they will hopefully both keep trying to leapfrog each other.

If they can catch up to Intel, and it is not inconceivable, what actual benefit does X86 have? It's a desktop platform that Intel is trying to shrink. I have a netbook-sized Pentium III-based Thinkpad 240, that was from the year 1999. Granted, it cost around an order of magnitude more than a low end atom-based netbook, but the reality is that X86 hasn't really moved too far in the past decade. The netbook form factor has been possible for a very long time. The price is cheaper, but it came at a huge penalty in terms of build quality and relative performance. I don't think my Dell Mini from 2008 will last as long as the 240, which is still ticking BTW(last I checked, anyway), and has a better keyboard than any netbook ever made. Just look at CULV systems, you can get a huge amount of power in something that is only larger than a netbook for the sake of practicality.

So Atom doesn't enable smaller devices, just cheaper ones. I think this is kind of the point, that an Atom even at 100MHz wouldn't be good enough for these form factors. A netbook is possible because it can be turned off or put into standby, the use case for a phone or tablet is different. Apple is trying to make their computers more iPad-like, and I'm not sure it is possible to achieve that with X86.

Every time Intel(or transmeta or VIA) has tried to shoehorn an X86 chip into something smaller than a netbook, it has failed. It has been failing over and over now for a decade. ARM on the other hand has done extremely well. The first modern tablet, the Nokia N770, had just a 4" display and got reasonable battery life and days of standby time. The OQO was the X86 competition, and it was a far less useful device, never mind the fact that it also cost nearly an order of magnitude more than the often-deeply-discounted N-series tablets.

So if Apple is having a hard time getting X86 to scale down for cheaper, lighter, more "connected", longer-lasting systems, it would make sense for them to be going with ARM. I think the idea of having my laptop be "on" all the time and downloading emails is useful. Not just that, but it would make doing something like streaming content from a laptop to an AirPlay Apple TV practical as well. With 1080p decode/encode it enables HD Facetime(the current Air has terrible webcam quality). nVidia is talking about Core2Duo level performance from ARM by August. Obviously, nvidia is full of shit, but even just better-than-atom performance in the 11" Air and with "PS3-level" graphics with 5 hours of runtime would be amazing. If they do this, the $1000 11" Air would be superior to the XPS M1710 from 2005 with a 7800GTX and a 2GHz Pentium M for $2000. Incredibly more battery life, 2.3 pounds instead of 8, equal performance in games and across the board, better performance for certain tasks(2GHz Pentium M is just barely too slow to play DRMd 1080p video). Browsing and typing on the XPS at moderate brightness would have 2 hours of battery life. Playing games on battery(at reduced clocks) would kill it in 45 minutes. Getting the same thing in a package that is literally less than a third the size, for half the price, and with consistent 5 hour battery would be pretty compelling. I can say for sure that Apple wants this. Can Intel deliver it?

I guess we will know more about Atoms future next week according to Anand.

 

[Cogman]

x86 is stuck in legacy design for compatibility, though I hear cutting out the legacy bullshit and go with x64 only CPUs could help cut some of the fat.

Intel essentially tried that with Itanium, it didn't work so well. In pretty much all respects the Itanium processor is superior to x86, except running legacy code.

It isn't just the fact the x86-64 CPUs today support x32 bit instructions, it is the fact that they support 16bit, 8 bit, 4 bit, and who knows how many obsolete instructions and registers that nobody ever uses today. (MMX, the enter instruction, etc).

Heck, x86 cpus even have to support different operating modes because someone, somewhere, still uses them for DOS applications. (Real and protected mode).

 

[Cerb]

Intel essentially tried that with Itanium, it didn't work so well. In pretty much all respects the Itanium processor is superior to x86, except running legacy code.

If, by legacy code, you mean all code not specifically tweaked for the processor, then yes. Intel did not try to make a good replacement for x86 with the Itanium, regardless of an attempt to replace x86 being certain to fail at the time (Intel could have made a great ISA, with implementations that whooped x86 CPUs, and at best, they would have been able to better compete against Power and SPARC).

A good replacement for x86 would run code straight from a common compiler just fine, and do so within a reasonable transistor and power budget. ARM, MIPS, PPC, and SPARC, off the top of my head, have all been far more capable of this than Itanium. With COTS code, Itanium has typically loses to cheap x86 desktop CPUs. It was and is a big server chip, has been a pretty good one of those, and has never had much promise outside of that realm.

For awhile there, Intel's management was plain loonie, until the Opteron sobered them up.

It isn't just the fact the x86-64 CPUs today support x32 bit instructions, it is the fact that they support 16bit, 8 bit, 4 bit, and who knows how many obsolete instructions and registers that nobody ever uses today. (MMX, the enter instruction, etc).

Heck, x86 cpus even have to support different operating modes because someone, somewhere, still uses them for DOS applications. (Real and protected mode).

Which has limited x86 exactly how much? Intel removing legacy features will mean removing things like PCI and ISA, SMB, etc., in favor of basic peripherals and maybe 4-8 PCI-e lanes. All those legacy instructions will be touted as a strength, and removing them would only do a negligible amount of good, anyway, as a cleaner x86_64 would have almost all the same power problems, but would not have the market strength of being x86.

ARM can keep vast swaths of the chip not doing much of anything most of the time, while still running, in ways x86 won't be able to, no matter how you streamline it. x86 is not load-store, and ARM represents a long history of top-to-bottom design for efficiency. Brute force by Intel, and gradually reducing differences between static and dynamic power consumption will get x86 into mobile, but if they want low power like ARM has(and there's a chance they don't care about this, either, and will be happy to let ARM keep the lower end of mobile devices), they'll need to try a truly novel approach, not cutting out a few instructions, registers, and memory modes.