Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Developers who are coding to current frameworks and APIs will likely just need to push out a recompile, one would think they'll make it very easy for devs to do this. Apple can handle the heavy work under the hood, and likely have been staying on top of this for ages, just like they were doing for x86 in secret well ahead of that transition.

But there is lots of software that won't get recompiled for a long time. Maybe not everybody uses BootCamp, but I'd be screwed!

You also can't count on some of the most complicated and expensive OSX software being recompiled immediately. I think you are thinking only for users who do iPad type of work where applications are recompiled yearly.
 
It isn't wiped. Just re-tested it on my 7.x rMini with both switching to another tab and completely backgrounding (minimizing) Safari. Not even the password fields were wiped, not even with https sites with strict caching / user credential saving metadata (e.g., banking sites).

That sounds more like a bug (which could be memory related) I haven't encountered it - Can you give me a reference URL to try out on my Air?

----------

> iOS 7, A7 and 1 gig of "RAM bottlenecks" on iPad Air & iPad Mini Retina ? ... Ask Safari among other apps ... it's a Crash festival!


64-bit A7 processor indeed is a "marketing gimmick", there is no use for 1 gig of ram in a 64 - bit architecture.


> iOS 6, A6X and 1 gig of ram where flawless on iPad 4 delivering way better and reliable performance on safari and other power user apps


It's a shame ! There wasn't an upgrade this last years fall, it was more like a down grade ! A no show up !


What could have been that wasn't ? 2 gig of damn ram, it might have done justice to an A7, but margins, those damn margins ...

Whats next ?


iOS 8 ( a rebranded iOS 7.X beta without RAM management issues), A7 (X) and 2 gig of ram ? Well now, finally ... Last year expectations met this time around ...


Hi, I have an Air and no crash festival on iOS 7.0.4, 7.0.6. I beta tested 7.1 and still no crash festival...

If you're gonna troll, please tell us which iPad you own and where it's crashing and how.

P.S. Regardless of poor applications, this thread is about the A7s architecture so you may find other threads better for trolling :p
 
Can we stop with this 'only point of 64 bit is more RAM'. That is 64-bit memory addressing, 64-bit processing is separate and has huge benefits in computation depending on what you are doing.

What app's performance derives "huge benefits" from the iPhone's 64 bit processor? Most of the improvements in the A7 come from architecture changes in ARMv8, not the 64-bit nature of it. Most apps aren't that computationally intensive in 64-bit arithmetic operations that they will benefit from a 64-bit processor.
 
Last edited:
I have not encountered the page reloading thing so many other posters in this thread bring up. Not in Safari, not in Chrome. Not even with 20 other background (suspended) applications on the 128 GB iPad Air, which ought to be the most constrained! I am completely baffled by this discussion. :confused:

That being said, kudos to Anand Lai Shimpi for so thoroughly picking apart the A7 and showing the rest of us why it's so forward looking compared to other ARM chips released at a similar time. What impressed me the most was that the A7 can match a Haswell Core i3 at the same frequency, albeit with the i3's Turbo Boost function disabled, at least according to benchmarks.
 
I have not encountered the page reloading thing so many other posters in this thread bring up. Not in Safari, not in Chrome. Not even with 20 other background (suspended) applications on the 128 GB iPad Air, which ought to be the most constrained! I am completely baffled by this discussion. :confused:

That being said, kudos to Anand Lai Shimpi for so thoroughly picking apart the A7 and showing the rest of us why it's so forward looking compared to other ARM chips released at a similar time. What impressed me the most was that the A7 can match a Haswell Core i3 at the same frequency, albeit with the i3's Turbo Boost function disabled, at least according to benchmarks.

You are the first person I have heard who hasn't had this happen. It happens to most of us with anywhere from 1-5 tabs open. When you spend a few minutes on one page and switch tabs, the tab reloads. It has happened to me every time I've ever used my Air and it has happened to every Air I've checked at the Apple store. It sure doesn't appear to be a random issue.
 
What app's performance derives "huge benefits" from the iPhone's 64 bit processor? Most of the improvements in the A7 come from architecture changes in ARMv8, not the 64-bit nature of it. Most apps aren't that computationally intensive in 64-bit arithmetic operations that they will benefit from a 64-bit processor.

http://appleinsider.com/articles/13...ed-new-audio-video-features-in-apps-and-games

While the new ARMv8 definitely contributes, you can't simply write off the shift to 64 bit in the amount of data that the chip can now push through. These developers make it very clear that this chip is a huge advancement.
 
The problem is that while everyone else has been focused on performance ARM has been focused on low power with a compromise in the area of things like branch prediction, speculative execution, etc. Those things take lots of transistors and it was not the focus of ARM.

Cache performance and multiprocessor cache coherency are not things that ARM has been focusing on. ARM just got to 64 Bit. Multiple threads, shadow registers for fast context switching, etc....

Intel and even AMD are way ahead of ARM in the performance area.
Also trying to compete with Intel in processor development has put many a company out of business.

While it makes sense for Apple to use ARM in a mobile device it makes almost no sense for them to do it in a desktop processor.

I agree, but on the other hand Alpha was also a pretty simple processor but it was a stonking fast one. There are things you can do with a pure 64 bit design with multiple instruction pipelines, out of order execution and so on which make for a very fast CPU. Intel went down a serious dead end with the likes of Netburst for a while just chasing high clock speeds and ended up with deep instruction pipelines which caused terrible performance per clock particularly when there was a cache miss.

I see no reason why the lessons learned from other 64 bit architectures like Alpha couldn't be applied to ARM to give a full desktop class processor. It is just a matter of there being a market need. If anyone can do it, then Apple can because the idea of a true all day MacBook Air running OS X on ARM would be tempting. You would lose some nice features that x86 brought such as virtualisation of Windows but Windows is becoming less of a requirement these days as people move away from the platform and there are remote desktop solutions which can fill in. At some point, I expect Apple will see a benefit of a full OS X on ARM implementation, and surely they're already compiling the code on the platform anyway. The real question is whether pulling transitive back in to run x86 on ARM is likely now they've dropped Rosetta? They won't do it if there aren't real positive benefits over the modern low power x86 variants going into the MBA of course.
 
I agree, but on the other hand Alpha was also a pretty simple processor but it was a stonking fast one. There are things you can do with a pure 64 bit design with multiple instruction pipelines, out of order execution and so on which make for a very fast CPU. Intel went down a serious dead end with the likes of Netburst for a while just chasing high clock speeds and ended up with deep instruction pipelines which caused terrible performance per clock particularly when there was a cache miss.

I see no reason why the lessons learned from other 64 bit architectures like Alpha couldn't be applied to ARM to give a full desktop class processor. It is just a matter of there being a market need. If anyone can do it, then Apple can because the idea of a true all day MacBook Air running OS X on ARM would be tempting. You would lose some nice features that x86 brought such as virtualisation of Windows but Windows is becoming less of a requirement these days as people move away from the platform and there are remote desktop solutions which can fill in. At some point, I expect Apple will see a benefit of a full OS X on ARM implementation, and surely they're already compiling the code on the platform anyway. The real question is whether pulling transitive back in to run x86 on ARM is likely now they've dropped Rosetta? They won't do it if there aren't real positive benefits over the modern low power x86 variants going into the MBA of course.

You make some excellent points.

But the current MBA already has pretty great battery life -- all day in my book for sure. I'm not sure I'd be willing to make the windows sacrifice for battery life improvements that would be marginally useful to me at best.

Additionally, I'm not knowledgeable enough to comment on what will happen to existing x86 software on an ARM-based computer. Is there an easy way to ensure compatability?
 
http://appleinsider.com/articles/13...ed-new-audio-video-features-in-apps-and-games

While the new ARMv8 definitely contributes, you can't simply write off the shift to 64 bit in the amount of data that the chip can now push through. These developers make it very clear that this chip is a huge advancement.

This article doesn't really support many of the claims that it makes. From what I can see, none of the examples it puts forward actually distinguishes performance gains from the new architecture and the "64-bit-ness" of it.

"Chandrasekher's opinion is particularly suspect because the A7 is already known to enable key features of iPhone 5s, including its advanced camera features (powered by the A7's Image Signal Processor, using an architecture similar to dedicated point-and-shoot cameras) and Touch ID (which relies on what Apple calls the A7's Secure Enclave Processor). Both are integrated into the A7."

Ok ... assuming that that is actually true, all this talks about is how all of this is relying on the enhanced capabilities of the A7, not its ability to perform 64-bit arithmetic operations natively...

On the iPhone 5s, the new 64-bit architecture of the A7 provides immediate benefits to developers thanks to its "modern instruction set," known as ARMv8...

Once again ... ARMv8 architecture.

Then here's the part I'm most intrigued with:

There is a marked increase in performance observed in moving from 32-bit to 64-bit benchmarks on the same hardware, in addition to the baseline improvement of the A7 over the A6 seen in 32-bit benchmarks.

Then I looked for these benchmarks in the article and I couldn't find anything!

A7.64bit.apps.100413.001.jpg


The only "benchmarks" provided compare A6 (and other 32-bit ARM variants) to A7. Not exactly the comparison we were looking for.

Once again, they could be right, they just haven't actually demonstrated it!

Karim Morsy of Germany's Algoriddim noted that "optimizing djay 2 for the 64-bit A7 chip has allowed us to bring desktop-class power to our iPhone app.

Morsy added that "djay's audio processing and analysis is up to 2x faster, which not only makes the whole UI and animations run smoother but also allowed us to introduce new features and effects that weren't possible before.

Essentially: "We can do more stuff on A7 than we could on A6". Once again, what part about that is exclusive to 64 bit? What kind of performance gains are we talking about that can be attributed to its ability to perform 64-bit arithmetic operations natively?

"With the unmatched power of the iPhone 5s and its A7 chip, we can now combine fullscreen rendering effects, tons of polygons, and advanced gameplay processing in one smooth package.

I'm pretty sure this is more due to the beefed up GPU (based on IP from Imagination Technologies) on the A7, rather than the 64-bit CPU, no?

According to Anand, "There’s more graphics horsepower under the hood of the iPhone 5s than there is in the iPad 4. While I don’t doubt the iPad 5 will once again widen that gap, keep in mind that the iPhone 5s has less than 1/4 the number of pixels as the iPad 4."

Read more about it here: http://www.anandtech.com/show/7335/the-iphone-5s-review/7



All in all, nothing really in the article points specifically to the move to 64-bit as a huge performance gain. Rather, it speaks of general performance gains moving from A6 to A7.

Anand:

"In the ARM world, the move to 64-bit is motivated primarily by the same factor: a desire for more memory. Remember that ARM and its partners have high hopes of eating into Intel’s high margin server business, and you really can’t play there without 64-bit support. ARM has already announced its first two 64-bit architectures: the Cortex A57 and Cortex A53. The ISA itself is referred to as ARMv8, a logical successor to the present day 32-bit ARMv7.

The motivation for Apple to go 64-bit isn’t necessarily one of needing more address space immediately. A look at Apple’s historical scaling of memory capacity tells us everything we need to know:

The soonest Apple would need 64-bit from a memory addressability standpoint in an iOS device would be 2015, and the latest would be 2016. Moving to 64-bit now preempts Apple’s hardware needs by 2 full years.

The more I think about it, the more the timing actually makes a lot of sense. The latest Xcode beta and LLVM compiler are both ARMv8 aware. Presumably all apps built starting with the official iOS 7 release and going forward could be built 64-bit aware. By the time 2015/2016 rolls around and Apple starts bumping into 32-bit addressability concerns, not only will it have navigated the OS transition but a huge number of apps will already be built for 64-bit. Apple tends to do well with these sorts of transitions, so starting early like this isn’t unusual. The rest of the ARM ecosystem is expected to begin moving to ARMv8 next year."

See: http://www.anandtech.com/show/7335/the-iphone-5s-review/4



edit: I stand corrected. I did some more digging here, and actually came up with some quantitative charts from Anand's review that detail performance gains due exclusively to the 64 bit transition. He compares 64 bit and 32 bit processes on the same hardware. I'd link the charts, but they're not in image format, so I'm not sure how to post them. But the conclusion is here:

The DGEMM operations aren't vectorized under ARMv7, but they are under ARMv8 thanks to DP SIMD support so you get huge speedups there from the recompile. The SFFT workload benefits handsomely from the increased register space, significantly reducing the number of loads and stores (there's something like a 30% reduction in instructions for the A64 codepath compared to the A32 codepath here). The conclusion? There are definitely reasons outside of needing more memory to go 64-bit.
 
Last edited:
But there is lots of software that won't get recompiled for a long time. Maybe not everybody uses BootCamp, but I'd be screwed!

You also can't count on some of the most complicated and expensive OSX software being recompiled immediately. I think you are thinking only for users who do iPad type of work where applications are recompiled yearly.

You mean like the majority of users on MacBook Air and Mac mini, as I was talking about...? ;)
 
edit: I stand corrected. I did some more digging here, and actually came up with some quantitative charts from Anand's review that detail performance gains due exclusively to the 64 bit transition.

It's a pointless distinction to make though because you don't get to pick, the 64bit nature is part of the new instruction set. And as far as addressing goes, part of the 64 bits are used for the Obj-C ISA pointer currently, so it's not like it's unused.
 
This is one painful thread to read through, with mostly non-relevant arguments.

My question would be whether there's a specific reason for Apple's aggressive move through the microarchitecture. We mostly expected the Swift to have another year and the A6 chip to make through to devices like the iPad Mini Retina but they have been relegated to a lesser status much quicker than expected.

After the long reign of the A5, it's almost shocking to me how quickly Apple moved everything to Cyclone and the A7. I thought they might introduce an iPad or an iPod Touch using the A6 chip but that never materialized either.

Also how logical for a mobile is Apple's move toward a "Desktop Class" which I guess refers to a wide design with a low clock speed. Is this a clear indication that Apple really have an ulterior motive i.e. something more than just mobile ambition with the CPUs? Was the process made much faster with PA Semi's experience, I mean does the A7 share any characteristics with the PWRFficient chips, and does that give us any hint as to where the A8 is headed to. I don't know if we can expect another "tock" like move is in the store. But if they do, can a Macbook Air with an ARM chip be that far away?
 
I wonder which current apps come the closest to maximizing the performance of the A7.

My guess would be games of some sort.

----------

Additionally, I'm not knowledgeable enough to comment on what will happen to existing x86 software on an ARM-based computer. Is there an easy way to ensure compatability?

That all depends on your definition of easy! :D
 
You are the first person I have heard who hasn't had this happen. It happens to most of us with anywhere from 1-5 tabs open. When you spend a few minutes on one page and switch tabs, the tab reloads. It has happened to me every time I've ever used my Air and it has happened to every Air I've checked at the Apple store. It sure doesn't appear to be a random issue.

It sure isn't a random issue. In the Hacks and iOS7 forums here, I've published several memory usage & tab reload benchmarks for both the iPhone (32-bit) and the iPad (both 32- and 64-bit), all both running 7.0.6 and 7.1.

For example, if you load http://nin.com on an iPad (any configuration of the above: 7.0.x vs. 7.1, 32 vs. 64 bit) and, then, switch to another tab and load even a small webpage, the previous nin.com tab WILL be unloaded.

Note: nin.com is a representative of a long, heavy page with tons of high-res images and inline videos. This is why loading it takes between 100 and 300 Mbytes of memory, depending on the model. Obviously, as I've explained many times in this thread, on lower-screen res devices (on iPhones, as opposed to iPads), much less RAM is allocated for loading it.

----------

My guess would be games of some sort.

Yup... too bad the currently best and prolly most hardware-taxing 3D game, XCOM: Enemy unknown, wasn't (as of the current, 1.6 version) compiled for 64-bit (I've checked this myself with "file"), only for armv7. (That is, it hasn't been even compiled for armv7s to allow for, say, hardware dividing in the A6. Division is done in software even on A6 CPU's because of the lack of the armv7s binary.)

Given that 99,99% of other games are a joke and have far more moderate HW requirements, I don't think any of them has been specifically compiled for 64-bit.

Let me also point out that compiling for 64-bit, if you haven't developed your app right from the start for 64-bit compliance, isn't very easy, particularly if you use third-party libs. No wonder many devs don't provide 64-bit binaries (neither do I - it'd require a lot of work to "64-bitize" my AppStore apps. It's simply not worth my time.)
 
That sounds more like a bug (which could be memory related) I haven't encountered it - Can you give me a reference URL to try out on my Air?

----------




Hi, I have an Air and no crash festival on iOS 7.0.4, 7.0.6. I beta tested 7.1 and still no crash festival...

If you're gonna troll, please tell us which iPad you own and where it's crashing and how.

P.S. Regardless of poor applications, this thread is about the A7s architecture so you may find other threads better for trolling :p
I have an iPad4 and iPhone5S both on iOS 7.1
Mail and Safari crash REGULARLY/intermittently, which are Apps that are developed by Apple.
You would think their Apps would at least be stable.
I've had the Safari & Mail crashing issues on my iPad1 and iPhone4 as well.

What ever is causing the issue, Apple doesn't know or doesn't care.
 
Developers who are coding to current frameworks and APIs will likely just need to push out a recompile, one would think they'll make it very easy for devs to do this. Apple can handle the heavy work under the hood, and likely have been staying on top of this for ages, just like they were doing for x86 in secret well ahead of that transition.

But there is lots of software that won't get recompiled for a long time. Maybe not everybody uses BootCamp, but I'd be screwed!

You also can't count on some of the most complicated and expensive OSX software being recompiled immediately. I think you are thinking only for users who do iPad type of work where applications are recompiled yearly.

You mean like the majority of users on MacBook Air and Mac mini, as I was talking about...? ;)

I don't know about the mini -- I've seen a lot of more complex software packages running on it. People are using the mini in rackmount kits as a substitute for the Xserve.

The Air, on the other hand-- I bet most people install Apple/appstore apps almost exclusively. ARM apps would be easy to distribute through the appstore. After the progression from ppc 32 to ppc 64 to intel 32 to intel 64, and, variants of nvidia, amd, and intel graphics, any non-graphics-intensive app should be be trivial to recompile.

I actually can't think of a reason why you wouldn't want to use the 64-bit ARM on the Air.
 
Doubt it.

It will be awhile before Macs go to ARM-powered chips. At least ... if you believe the guy who you're citing in the article.

Additionally, having a non- x86 MBA would be such a PITA, in terms of software compatibility.

I doubt Apple would fragment the Mac lineup like that. It's OK for iPad, since the entire app ecosystem is different. But it won't fly on a laptop anytime soon.
There would be no fragmentation involved. The MacBook would be brought back with an ARM processor while the MacBook Air and MacBook Pro would continue to use processors from Intel.

Software compatibility will also not be a problem. Apple's iWork and iLife already have feature parity across hardware (Intel/ARM) and operating systems (OS X/iOS). It will not take long for iOS developers to get their apps running in OS X on ARM. I also expect Apple to release a version of Xcode that will run on ARM.

Software like Final Cut Pro X, CAD, Premiere, etc., will not get ported to ARM, but every iOS app has the potential to get ported to OS X because it will be using the same hardware.
 
I actually can't think of a reason why you wouldn't want to use the 64-bit ARM on the Air.

As i've explained above, making legacy apps 64bit-compliant is sometimes very hard. This is why i haven't done it in my AppStore apps either - the performance gain over the armv7s binary would not have been worth the effort.
 
You make some excellent points.

But the current MBA already has pretty great battery life -- all day in my book for sure. I'm not sure I'd be willing to make the windows sacrifice for battery life improvements that would be marginally useful to me at best.

Additionally, I'm not knowledgeable enough to comment on what will happen to existing x86 software on an ARM-based computer. Is there an easy way to ensure compatability?

I've got a slightly older MacBook Air and it gets around 7 hours on a single charge which is very close to all day. However, I would be interested in a machine which could do say 24 hours on a charge which is double what the current MBA can do.

I rarely use Windows directly on my hardware these days. It used to be more important to have Windows tools available but our office switched to largely using Google Docs so MS Office tools aren't needed and nothing else on Windows matters to us as we're entirely cross platform. I can imagine that other sites are less flexible but there has been a sea change in recent years driven by the moves away from Internet Explorer and towards portable platforms like iOS and Android. That makes it more important to have documents stored on the network and accessible from a browser and all of that makes Windows irrelevant.

With that said, I was around for the transition from PPC to x86 and that was handled very well. Sure, the PPC apps on x86 didn't run at native speeds but they weren't unusable because all the GUI code was native and Rosetta translated the rest pretty quickly so once it was running it worked well. I ran MS Office 2004 side by side on my 1GHz G4 and 2Ghz x86 and I would say the x86 ran the program at about the same speed as a 500Mhz PPC would which isn't bad. On the other hand, when the Intel native version of Office came out, that ran slower than the PPC version under Rosetta and still does. I've got Office 2011 and it sucks. It is slow, crashy and unpleasant. I would rather keep running 2004 but since Lion I've lost Rosetta so I'm stuck. That was just another thing which drove me away from MS Office. The other day I had to use it because I was collaborating with someone who insisted on using it and the damn thing locked up suddenly losing about 30 mins of edits. Once I force quit it, the file came back missing those edits so I said stuff it, loaded the doc into Google Docs and shared it with my colleague. He hadn't really used GD at that point but once we got into it and chatting away, both working on the same doc, it was great. His last step once we were happy with the content was to grab the file in Office format and fix up the formatting for the final form and that's where Office sits now. It isn't an all day tool for us, it is a final finishing tool, and it can just as easily be replaced by OpenOffice for us. I moved an ongoing document from Office to OpenOffice a while back and that's fine too.

Anyway, can x86 apps run on ARM using transitive/rosetta style technology? Absolutely. I used an Acorn RiscPC about 20+ years back which was able to emulate a full PC in software and run Windows 3.1 because it was so much more powerful than any x86 on the market at the time. Move forwards to today and with on the fly recompilation of x86 code on an ARM native version of OS X you wouldn't really know which apps were x86 or ARM just as was the case for Snow Leopard running PPC and x86 apps. It can be done and Apple will do it seamlessly if there is a market benefit to having OS X on ARM. The transition from PPC to x86 was a technological and marketing feat and yet very nearly seamless, and any move to ARM for OS X will be too.
 
...and yet the fact(s) that these claims are indeed valid are there for all to see.

Yes the facts are there to see: desktop class CPUs, be they Intel or AMD, grind any ARM to dust.

FX8350 vs A7? It's not the same class. i7 4770 vs A7? It's not the same class.

Even FX4300 and i3 3220 crush the A7. Crush.
 
Yes the facts are there to see: desktop class CPUs, be they Intel or AMD, grind any ARM to dust.

FX8350 vs A7? It's not the same class. i7 4770 vs A7? It's not the same class.

Even FX4300 and i3 3220 crush the A7. Crush.

Sure, lets make ridiculous comparisons to justify prejudiced opinions. Because that's logical and fun...NOT.
 
I'm going to get blasted for this because its a criticism but here it goes.

A7 is a very wide core which is why it has a high theoretical performance. It therefore has a lot of power that is untapped.

However, extracting that power massively increases power consumption.

We can look at anand's power test to see this.

http://images.anandtech.com/reviews/tablets/apple/ipadair/krakenpowersm.png

maxpower2sm.png


Easily see that under heavy load the A7 power use (there is no GPU running) is more than twice that of the a6X at around 7-8W. Under lighter loads (the massively wide core is not utilized) power drops down to ~ 3W. So while its possible to extract performance you cannot do that without increasing power consumption. If you add the GPU (at least ~3W under heavy load) you are looking at 10-11W power draw.

For comparison the A7 is using clock for clock way more power than Haswell (Incidentally they are also a very similar size-the A7 dual core uses the same die space as a quad core A15 cluster). ULV Haswell will run prime 95 at 2.6 Ghz and that is 2 cores + HT in a 15W envelope. (Not counting the igp which will cause the chip to throttle but I'm not looking at the gpu in the A7). That is of course under full load, under light load.

55644.png


11 hours on a 54W battery

Ipad Air gets 10 hours on a similar test with a 32.4W battery

There isn't a whole lot going for the A7 (due to platform power consumption). Sure the ipad has better efficiency but (smaller high PPI ipad screen probably consumes the same amount of power as a 13" MBA screen) its rocking less RAM, much lower power storage (not a full SSD), and doesn't have to do with a lot of the I/O that Haswell has.

Don't get me wrong the fact that you can even compare Apple and Intel is impressive but there are quite a few caveats.

The other thing to note is that as Apple designs the CPU and software for the browser benchmarks and thus is able to get crazy optimization levels out of it. Look at Mantle performance gains (up to 100% in some cases). Just look at the efficiency Apple can get out of battery life on its macbooks.
 
I think you are mixing a few things.

First, yes, desktop CPUs are at a speed where year-over-year incremental improvements are hardly noticeable. That wasn't the case five or ten years ago, but it certainly is now. You have to specifically look to notice the performance difference most of the time.

But, "desktop class CPU" does not equal "desktop class system". This is a phone. The A7 CPU may well be able to compete with Intel's chips in terms of raw performance. But, the rest of the system around it is nowhere near what you will want to be using 3-5 years from now. The memory constraints have been talked to death on this board, but that's not the end of the compromises put in place to get this system to fit into a little slab of aluminum and glass that in turn fits intone the palm of your hand. All those other compromises are seeing rapid advancement, and so year over year the raw overall performance of the device can and will improve.

Putting the A7 into a desktop would be an interesting experiment. I suspect someone is already carrying it out (or has already done it and drawn conclusions based on it). I would expect performance to degrade slightly, but power consumption to improve significantly. The real problem is that this wouldn't be competing with i5s and i7s, but with Intel's low-power lines, where performance might be comparable (or better) and power consumption might be comparable (or better), but who today would look at the i5 and i7 and an Atom-based machine side by side and think, "Yeah, I'll go with the Atom"?

I had an iPad 3. You don't have to tell me about stuff like RAM. Heck, this iMac came with I think 4GB of RAM, which is nowhere near enough now if you keep a lot of stuff open and especially at how cheap throwing in another 8GB was.

One benefit these devices have is they aren't slowed down by disk drives. I keep waiting for the day when flash storage gets price competitive enough to kill disks for internal use on desktops and notebooks. At least mobile devices are around to keep pushing, although at some point I would really love to see that baseline model jump to 32GB on iPhones and iPads -- or at least start with 16 and then go to 64.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.