You missed my point. I know that most normal day to day apps don't break down into nice neat pieces that you can spread amongst cores. But when you have lots of cores, you can do other things like put each app on its own core. The app only runs on the one core but it is not sharing that core with any (or many) other apps. And the underlying OS can be made to utilize lots of cores, and high end apps will be made to utilize the cores. So speaking about 32 or 64 cores is reasonable, because the cores are not equal to the cores we have on the desktop today.
I have an older Mac Pro with dual multi core Xeon chips, btw, as well as a quadcore i7 based MBP.
No, 32 to 64 cores does not sound reasonable for a machine targeted at mass consumer usage. You can have your apps spread out across lots of cores, but most of those apps and their threads are essentially waiting on user input. Most usage involves a single dominant thread, maybe 2 or 3 if some of the apps are actually doing something.
My current machine has something like 300+ threads right now spread across lots of apps and system services, and my CPU usage is at around 3%, with momentary spikes in the 10% to 20% range for the foreground app. So, the smoothness of the UI really depends on how well designed the CPU scheduler is, as there is ample CPU cycles available.
Somewhere between 2 to 5 CPU cores is likely the sweet spot for mass market usage. The CPU designer should definitely be trading for a smaller amount of brainiac cores with the highest performance memory and I/O as possible. The best thing people should do for their PC these days is to have a good SSD, but unfortunately, it's also the most expensive option.
If Apple does an ARM laptop running OS X, it's going to be 2 to 4 cores with as good or better IPC as Haswell/Broadwell. Actually, it better have faster performance than Intel's offering at the same TDP as their will be an emulation penalty for the inevitable amount of legacy software.
Oh I tend to disagree, I think it'll be a dog. We'll see though; perhaps the chips that come around in a few generations tailored for desktop use will be more powerful then I imagine them to be. I'm not personally expecting them to be much better than the equivalent of an Atom. If this story is true, however, I hope you're right and I'm wrong!
Having a single Atom would suck. Having 12 or 18 of them -- maybe not.
A 32 or 64 core ARM would work very well in a desktop. Power hungry apps are already parallelized, but even ones that aren't can run on their own core so you don't have to share your CPU with other apps, or with as many other apps. On my desktop I have 12 apps currently marked as "running". If they were each in their own core, plus the OS processes used a few cores, then your average desktop app itself would not have to be optimized for many cores in order to get a boost from having lots of cores. Spreading the normal work of many apps across many cores is a benefit. None of my running apps, except maybe Xcode and a mysql access app need multiple cores themselves.
This is where we get a problem. Few apps are optimized for more than two cores. That will remain true for some time. Remember that there are still a lot of two core CPU's out there. Perhaps half of the current pc's have two core chips. Developers are finding it hard to parallel most apps meaningfully past two cores.
There are apps such as rendering apps, video editing apps, and a few others that do use numerous cores efficiently. But most don't.
A problem in assuming that 32 or more cores would be a great thing is in assuming that so many cores would be good for multitasking, but even there, it's questionable, for most users. I have a Mac Pro with two Xeon chips, each with four cores, and eight virtual cores. Since it's easy to monitor how many cores are working, and by how much, I do that fairly often.
Even during the most arduous tasks, I rarely find most cores are busy, even to the slightest extent. And as for all sixteen cores, well, that almost never happens, and when it does, most of them are running at very low levels.
So having eight cores would be more than enough for most people.
That sounds reasonable!
Here's a what if:
What if Apple decides it needs, say, 32 cores for a so-called power user machine ... because the normal power user needs 4-8 cores ... but Apple needs the other cores to provide Intel virtualization in a very-specific, customized to the ARM hardware, VM?
Right now, an Intel chip virtualizes x86 CISC instructions in real-time and then runs them as RISC code. Do you think that 24 A9X ARM cores could do the equivalent?
No, 32 to 64 cores does not sound reasonable for a machine targeted at mass consumer usage. You can have your apps spread out across lots of cores, but most of those apps and their threads are essentially waiting on user input. Most usage involves a single dominant thread, maybe 2 or 3 if some of the apps are actually doing something.
My current machine has something like 300+ threads right now spread across lots of apps and system services, and my CPU usage is at around 3%, with momentary spikes in the 10% to 20% range for the foreground app. So, the smoothness of the UI really depends on how well designed the CPU scheduler is, as there is ample CPU cycles available.
32 or 64 smaller cores may be the same as say 8 of your high powered cores in terms of CPU cycles. We'll see, but I foresee that a lot of small cores may be a way in the future to achieving better results than trying to high power your cores and just have a few. Context switching wastes your cache, time, etc in general terms. With lots of smaller cores your CPU scheduler needs to be more efficient and can be less efficient at the same time. It needs to keep the cores busy, but it doesn't have to deal with all the context switching.
Anyway, we'll see. And 32 cores is only 8 quad core chips.
2. Windows compatibility isn't a big deal for most users. It matters a great deal for a vocal minority, but for most users it's a non-issue. I can see Apple deciding that losing that niche is an acceptable loss. Also, emulation can be a solution for some of those users.
It seems to have been important to somebody:
Also, look at the sales numbers for Parallels Desktop and VMWare Fusion. If emulation of Windows weren't important to people, those products wouldn't be selling nearly as well as they are.
Every time I see a story like this, all you need to do is look at the use-case, and it falls flat on it's face.
1) Existing A-series and ARM based parts are still Pentium 3-era speeds on comparable workloads
2) Intel's Atom parts are barely faster than Pentium 3-era parts
3) Intel's onboard video has always been a joke, but mobile isn't much better.
I could see Apple eventually producing a CPU/GPU that is more capable than Intel's weak mobile offerings, but Apple is unlikely to create an environment where they have to produce two versions of software for any extended period of time (see Motorola vs PPC, and PPC vs Intel.) Also look at how Microsoft fell on it's face with the Surface. Even if Apple produced a full version of OS X for an ARM based iMac or MacBook, the lack of being unable to just run every previous version of software will be felt and it will fail. Apple had an advantage earlier on when it switched from PPC to Intel because it was switching from a platform that only it was really using for desktops, so it could effectively push everyone off it. Not true with switching from x86 (look again at Microsoft, who also produced ARM, MIPS and ALPHA versions of Windows NT or CE at previous points in time.)
It's extremely unlikely that Apple would produce a part that is anywhere performance parity of the Xeon series in the Mac Pro.
There's also been some grumbling lately that OS X is getting too dumbed down that even people who normally like Apple are considering alternatives. Apple might be at a point in it's life where it might be more arrogant than Microsoft in making unnecessary changes to the operating system.
Firstly, Apple isn't arrogant for deciding what their products should/shouldn't do. Arrogance would be better defined as a blogger believing they know better.
The reasons a switch from Intel would make sense are:
Control of their own product: as they should. without being at the mercy of Intel.
Performance: A8X has near parity with the i5-4260u on Geekbench.
Power: MacBooks (the vast majority of Mac sales) are power-critical & Ax processors deliver better performance per watt.
Cost: way lower.
They can: unlike MicroSoft, Apple have done the silicon switch very well thanks to Universal Apps & emulation. The move away from Windows natives and prevalence of iOS versions makes x86 more of a marketing gimmick/safety net than an actual benefit (as it always was).
The real thing holding Apple back is Apple. The big question should be; why do they need anyone else's instruction set at all? They should be at a point where their hardware is fully optimised for their software with the insane performance & efficiency that delivers.
Correct me if I'm wrong but doesn't Apple generate nearly all the profits from the $1,000+ category of PC sales? If Apple were to move to their own in-house Ax chip, that would drastically change the dynamics in that market. As Apple lowered their prices, significant pressure would be put on margins for all the other top players in the PC market. They would be up against the wall unless Intel significantly lowered their prices.
My guess is Intel couldn't match Apple's pricing advantage, given Apple's dominant position across several product lines that give it a market measured in the 100s of millions. And those 100s of millions of units generate healthy profits that fortify Apple's ability to invest in capital and R&D. One could easily imagine a future where Apple decides to compete with Intel and PC makers move over to ARM (running a more robust Windows RT, or Chrome) in search of margins.
It's no secret that Apple likes to control all the parts of the recipe that goes into making their gear. I think it's just a matter of time before they cross that performance threshold. As someone mentioned earlier, they are also attacking this from the software side with Swift and Metal.
This is the last big step for Apple in truly controlling their destiny. Apple has made their intentions clear.
Removing Intel from the equation would allow Apple to better control the launch timing of the Mac line, he believes.
And it's about god damned time. The last major technical barrier was removed when the AX chip got its 64-bit instruction set and data path. Now it's just a matter of multi-core performance. Cross-compiling may or may not be much of an issue since the code base originally ran on RISC (PowerPC) anyway.
What's that? You say OS X won't be ported to AX because of all those "pro" apps that are Intel-only?
Well how many MacBook Air users are going to be using non-Apple "pro" apps anyway?
Apple might just leave Intel chips in the MacBook Pro for the "pro" market.
+1 completely agree, especially about Apple playing the MS game with dumbing down OS X. One of MS's big mistakes a decade ago was trying to shunt a desktop OS into a mobile device. Now Apple is doing the exact same thing, trying to shunt a mobile OS into a desktop environment. Apple was smart to realize, a decade ago, that mobile had its own use case. Now they are too arrogant with their mobile success, and are destroying the completely different use case of the desktop. Perhaps they want to get out of the computer business and rebirth the luggable form factor, a la iOS KayPro?
The whole post-PC fad is perhaps just how Apple perceives themselves. The reality is that general purpose computing devices (iMac, Mac Pro, PCs) with keyboards will be around forever, and require more sophisticated user interactions.
32 or 64 smaller cores may be the same as say 8 of your high powered cores in terms of CPU cycles. We'll see, but I foresee that a lot of small cores may be a way in the future to achieving better results than trying to high power your cores and just have a few. Context switching wastes your cache, time, etc in general terms. With lots of smaller cores your CPU scheduler needs to be more efficient and can be less efficient at the same time. It needs to keep the cores busy, but it doesn't have to deal with all the context switching.
Anyway, we'll see. And 32 cores is only 8 quad core chips.
It just doesn't work like that. You cannot just add CPU cycles and equal. There are more single threaded tasks than you think. You can have a 1 million small cores but if the task you need to do (which so many everyday tasks are) then you are limited to a slow core.
Want proof of this? Look at the very CPU you so desire. Why do you think it has 2 powerful (for a smartphone) cores instead of the 8 slower cores samsung likes to use.
Also, look at the sales numbers for Parallels Desktop and VMWare Fusion. If emulation of Windows weren't important to people, those products wouldn't be selling nearly as well as they are.
Using that chart to prove your point is such a huge logical fallacy that I'm sure you already know that you are reading the results to fit your argument, so I won't belabour that point.
It just doesn't work like that. You cannot just add CPU cycles and equal. There are more single threaded tasks than you think. You can have a 1 million small cores but if the task you need to do (which so many everyday tasks are) then you are limited to a slow core.
Want proof of this? Look at the very CPU you so desire. Why do you think it has 2 powerful (for a smartphone) cores instead of the 8 slower cores samsung likes to use.
I am not missing anything. The average mail, messaging, web client, etc. would work well on these "slower cores." They are fast enough to run mail, web browsing, text edit, and all the other mundane stuff that these single cores make up.
The very fact that there are single threaded tasks makes the lot of smaller cores more ideal as each core can run a more limited set of single threaded cores, but also be available for the massively parallel tasks that come down the pipe. No one said the system would not be able to spread tasks across cores if needed.
And, at least up to now, the Samsung ones are really 4 core processors that tag team depending on need, they are not really 8 core processors, if I understand that correctly. Just like Apple went to 3 cores in the A8X.
OK, so let's say the A10X is equivalent of somewhere between an Atom and an i3 chip (now). Right now, all MBPs and MBAs have either i5 or i7 processors. An i5 processor is significantly more powerful than an i3 processor, and has at least 2x the processing power of an Atom.
So in 2015... the MBA will have a 2015 i5 processor, and in 2016 the MBA will have an A10X, which is be half as powerful as an i5 processor from two years prior.
Aint gonna happen... I think some people are grossly over-estimating the general computing capability of ARM chips. Graphics and video, sure... general purpose compute? Not so much.
Genuine question- doesn't Grand Central and the new Swift programming language do a lot of the multi-core juggling for developers?
Here's an interesting read:
Apple describes Metal as: “Metal provides the lowest-overhead access to the GPU, enabling you to maximize the graphics and compute potential of your iOS 8 app. With a streamlined API, precompiled shaders, and support for efficient multi-threading, Metal can take your game or graphics app to the next level of performance and capability.” – source: https://developer.apple.com/metal/
1. Example of Metal and Swift for calculating the Sigmoid Function
Metal is an alternative to OpenGL for graphics processing, but for general data-parallel programming for GPUs it is an alternative to OpenCL and Cuda.This (simple) example shows how to use Metal with Swift for calculating the Sigmoid function (Sigmoid function is frequently occurring in machine learning settings, e.g. for Deep Learning and Kernel Methods/Support Vector Machines).
If you want to read up on Metal I recommend having a look at https://developer.apple.com/metal/ (Metal Programming Guide, Metal Shading Language and Metal Framework Reference)
I don't know how applicable this approach would be for most apps -- but with relative ease, the author was able to use Swift and Metal to exploit the CPUs and GPUs for a specific task. In a link he reports that this scales from 20x faster to 75x than other approaches.
4. Conclusion
Metal combined with Swift can give bang for the bucks in terms of performance for also non-graphical processing, when it is set up it is easier to use than accelerate and can give significant speedup (e.g. up to 20 in this example). If comparing it to CPU-based processing (i.e. pure Swift-code) the performance gains can be even higher (up to 75 times faster on iPhone 6).
The point of Grand Central Dispatch was to take the complexity of task (thread) scheduling out of the developer's hands. Developers can simply create a queue and submit tasks to it... the system then handles which processing units to send the tasks to. This happens at run-time, so, yes, software will automatically see the benefits of having more cores, but only if their apps were designed to be multi-threaded (use GCD) in the first place.
I know all apps would need to be recompiled against a new set of ARM-based api's but how many apps do you believe have NOT been designed to be multi-threaded? I'm sure there are programmers from major vendors that have been lazy when writing code and didn't add GCD but is GCD something that most programmers would simply use as a default or does it require a totally different programming environment to start with?
I'm just trying to get an idea of how complex this would be. I thought Xcode was able to handle a lot of conversions in the background, making wholesale changes easier than editing code line by line. I know programmers complained when Apple "forced" them to get rid of old PPC code. Would an ARM conversion be easier or more difficult than the PPC to Intel conversion?
Yes, this will happen sooner than later. Apple will be the first company to truly merge phone, watch, desktop, and laptop both on hardware and software. No new laptop for me until this comes out.
"Well-connected" means well connected to AppleInsider's inbox. Getting a press release from Ming touting his latest "research note" is like Christmas. Factual or not, it's sure to get an article. Or so I've noticed. Why not just let Ming post articles directly? Wouldn't that be simpler?
Using that chart to prove your point is such a huge logical fallacy that I'm sure you already know that you are reading the results to fit your argument, so I won't belabour that point.
Translation: I've got nothing, so I'll just make a lame attack with no substance instead and hope nobody notices.
It is a well-known fact that the transition to Intel increased Apple's Mac sales dramatically. Also, Parallels and VMWare are high-selling products on the Mac platform. I don't think Apple will drop the Intel architecture on their main lineup any time soon. They could conceivably do it on an ultra-low-end chromebook-type e-mail reader, if that's what this new 12" one-USB thing turns out to be, but even that is fraught with danger — just look at how Microsoft's low-end Surface model, being slow and incompatible with everything, destroyed the perception of that line.
I am not missing anything. The average mail, messaging, web client, etc. would work well on these "slower cores." They are fast enough to run mail, web browsing, text edit, and all the other mundane stuff that these single cores make up.
The very fact that there are single threaded tasks makes the lot of smaller cores more ideal as each core can run a more limited set of single threaded cores, but also be available for the massively parallel tasks that come down the pipe. No one said the system would not be able to spread tasks across cores if needed.
And, at least up to now, the Samsung ones are really 4 core processors that tag team depending on need, they are not really 8 core processors, if I understand that correctly. Just like Apple went to 3 cores in the A8X.
Let me clarify. You cannot spread a thread across cores. The reason servers have many cores is because they run many threads at once, thats why they are fast. All of those mail apps and web browsers run single threaded and would benefit from a faster single thread.
As for the samsung chips, you are not understanding it correctly. What it has is 4 high performance and high power usage cores and 4 low power and low performance cores. It is supposed to use any combination as it sees fit. We both know how well that works.
Comments
You missed my point. I know that most normal day to day apps don't break down into nice neat pieces that you can spread amongst cores. But when you have lots of cores, you can do other things like put each app on its own core. The app only runs on the one core but it is not sharing that core with any (or many) other apps. And the underlying OS can be made to utilize lots of cores, and high end apps will be made to utilize the cores. So speaking about 32 or 64 cores is reasonable, because the cores are not equal to the cores we have on the desktop today.
I have an older Mac Pro with dual multi core Xeon chips, btw, as well as a quadcore i7 based MBP.
No, 32 to 64 cores does not sound reasonable for a machine targeted at mass consumer usage. You can have your apps spread out across lots of cores, but most of those apps and their threads are essentially waiting on user input. Most usage involves a single dominant thread, maybe 2 or 3 if some of the apps are actually doing something.
My current machine has something like 300+ threads right now spread across lots of apps and system services, and my CPU usage is at around 3%, with momentary spikes in the 10% to 20% range for the foreground app. So, the smoothness of the UI really depends on how well designed the CPU scheduler is, as there is ample CPU cycles available.
Somewhere between 2 to 5 CPU cores is likely the sweet spot for mass market usage. The CPU designer should definitely be trading for a smaller amount of brainiac cores with the highest performance memory and I/O as possible. The best thing people should do for their PC these days is to have a good SSD, but unfortunately, it's also the most expensive option.
If Apple does an ARM laptop running OS X, it's going to be 2 to 4 cores with as good or better IPC as Haswell/Broadwell. Actually, it better have faster performance than Intel's offering at the same TDP as their will be an emulation penalty for the inevitable amount of legacy software.
Oh I tend to disagree, I think it'll be a dog. We'll see though; perhaps the chips that come around in a few generations tailored for desktop use will be more powerful then I imagine them to be. I'm not personally expecting them to be much better than the equivalent of an Atom. If this story is true, however, I hope you're right and I'm wrong!
Having a single Atom would suck. Having 12 or 18 of them -- maybe not.
That sounds reasonable!
Here's a what if:
What if Apple decides it needs, say, 32 cores for a so-called power user machine ... because the normal power user needs 4-8 cores ... but Apple needs the other cores to provide Intel virtualization in a very-specific, customized to the ARM hardware, VM?
Right now, an Intel chip virtualizes x86 CISC instructions in real-time and then runs them as RISC code. Do you think that 24 A9X ARM cores could do the equivalent?
No, 32 to 64 cores does not sound reasonable for a machine targeted at mass consumer usage. You can have your apps spread out across lots of cores, but most of those apps and their threads are essentially waiting on user input. Most usage involves a single dominant thread, maybe 2 or 3 if some of the apps are actually doing something.
My current machine has something like 300+ threads right now spread across lots of apps and system services, and my CPU usage is at around 3%, with momentary spikes in the 10% to 20% range for the foreground app. So, the smoothness of the UI really depends on how well designed the CPU scheduler is, as there is ample CPU cycles available.
32 or 64 smaller cores may be the same as say 8 of your high powered cores in terms of CPU cycles. We'll see, but I foresee that a lot of small cores may be a way in the future to achieving better results than trying to high power your cores and just have a few. Context switching wastes your cache, time, etc in general terms. With lots of smaller cores your CPU scheduler needs to be more efficient and can be less efficient at the same time. It needs to keep the cores busy, but it doesn't have to deal with all the context switching.
Anyway, we'll see. And 32 cores is only 8 quad core chips.
Also, look at the sales numbers for Parallels Desktop and VMWare Fusion. If emulation of Windows weren't important to people, those products wouldn't be selling nearly as well as they are.
Firstly, Apple isn't arrogant for deciding what their products should/shouldn't do. Arrogance would be better defined as a blogger believing they know better.
The reasons a switch from Intel would make sense are:
Control of their own product: as they should. without being at the mercy of Intel.
Performance: A8X has near parity with the i5-4260u on Geekbench.
Power: MacBooks (the vast majority of Mac sales) are power-critical & Ax processors deliver better performance per watt.
Cost: way lower.
They can: unlike MicroSoft, Apple have done the silicon switch very well thanks to Universal Apps & emulation. The move away from Windows natives and prevalence of iOS versions makes x86 more of a marketing gimmick/safety net than an actual benefit (as it always was).
The real thing holding Apple back is Apple. The big question should be; why do they need anyone else's instruction set at all? They should be at a point where their hardware is fully optimised for their software with the insane performance & efficiency that delivers.
Correct me if I'm wrong but doesn't Apple generate nearly all the profits from the $1,000+ category of PC sales? If Apple were to move to their own in-house Ax chip, that would drastically change the dynamics in that market. As Apple lowered their prices, significant pressure would be put on margins for all the other top players in the PC market. They would be up against the wall unless Intel significantly lowered their prices.
My guess is Intel couldn't match Apple's pricing advantage, given Apple's dominant position across several product lines that give it a market measured in the 100s of millions. And those 100s of millions of units generate healthy profits that fortify Apple's ability to invest in capital and R&D. One could easily imagine a future where Apple decides to compete with Intel and PC makers move over to ARM (running a more robust Windows RT, or Chrome) in search of margins.
It's no secret that Apple likes to control all the parts of the recipe that goes into making their gear. I think it's just a matter of time before they cross that performance threshold. As someone mentioned earlier, they are also attacking this from the software side with Swift and Metal.
This is the last big step for Apple in truly controlling their destiny. Apple has made their intentions clear.
Removing Intel from the equation would allow Apple to better control the launch timing of the Mac line, he believes.
And it's about god damned time. The last major technical barrier was removed when the AX chip got its 64-bit instruction set and data path. Now it's just a matter of multi-core performance. Cross-compiling may or may not be much of an issue since the code base originally ran on RISC (PowerPC) anyway.
What's that? You say OS X won't be ported to AX because of all those "pro" apps that are Intel-only?
Well how many MacBook Air users are going to be using non-Apple "pro" apps anyway?
Apple might just leave Intel chips in the MacBook Pro for the "pro" market.
How does Thunderbolt work on ARM?
The whole post-PC fad is perhaps just how Apple perceives themselves. The reality is that general purpose computing devices (iMac, Mac Pro, PCs) with keyboards will be around forever, and require more sophisticated user interactions.
32 or 64 smaller cores may be the same as say 8 of your high powered cores in terms of CPU cycles. We'll see, but I foresee that a lot of small cores may be a way in the future to achieving better results than trying to high power your cores and just have a few. Context switching wastes your cache, time, etc in general terms. With lots of smaller cores your CPU scheduler needs to be more efficient and can be less efficient at the same time. It needs to keep the cores busy, but it doesn't have to deal with all the context switching.
Anyway, we'll see. And 32 cores is only 8 quad core chips.
It just doesn't work like that. You cannot just add CPU cycles and equal. There are more single threaded tasks than you think. You can have a 1 million small cores but if the task you need to do (which so many everyday tasks are) then you are limited to a slow core.
Want proof of this? Look at the very CPU you so desire. Why do you think it has 2 powerful (for a smartphone) cores instead of the 8 slower cores samsung likes to use.
It seems to have been important to somebody:
Also, look at the sales numbers for Parallels Desktop and VMWare Fusion. If emulation of Windows weren't important to people, those products wouldn't be selling nearly as well as they are.
Using that chart to prove your point is such a huge logical fallacy that I'm sure you already know that you are reading the results to fit your argument, so I won't belabour that point.
It just doesn't work like that. You cannot just add CPU cycles and equal. There are more single threaded tasks than you think. You can have a 1 million small cores but if the task you need to do (which so many everyday tasks are) then you are limited to a slow core.
Want proof of this? Look at the very CPU you so desire. Why do you think it has 2 powerful (for a smartphone) cores instead of the 8 slower cores samsung likes to use.
I am not missing anything. The average mail, messaging, web client, etc. would work well on these "slower cores." They are fast enough to run mail, web browsing, text edit, and all the other mundane stuff that these single cores make up.
The very fact that there are single threaded tasks makes the lot of smaller cores more ideal as each core can run a more limited set of single threaded cores, but also be available for the massively parallel tasks that come down the pipe. No one said the system would not be able to spread tasks across cores if needed.
And, at least up to now, the Samsung ones are really 4 core processors that tag team depending on need, they are not really 8 core processors, if I understand that correctly. Just like Apple went to 3 cores in the A8X.
This isn't going to happen.
OK, so let's say the A10X is equivalent of somewhere between an Atom and an i3 chip (now). Right now, all MBPs and MBAs have either i5 or i7 processors. An i5 processor is significantly more powerful than an i3 processor, and has at least 2x the processing power of an Atom.
So in 2015... the MBA will have a 2015 i5 processor, and in 2016 the MBA will have an A10X, which is be half as powerful as an i5 processor from two years prior.
Aint gonna happen... I think some people are grossly over-estimating the general computing capability of ARM chips. Graphics and video, sure... general purpose compute? Not so much.
Here's an interesting read:
http://memkite.com/blog/2014/12/15/data-parallel-programming-with-metal-and-swift-for-iphoneipad-gpu/
I don't know how applicable this approach would be for most apps -- but with relative ease, the author was able to use Swift and Metal to exploit the CPUs and GPUs for a specific task. In a link he reports that this scales from 20x faster to 75x than other approaches.
http://memkite.com/blog/2014/12/15/data-parallel-programming-with-metal-and-swift-for-iphoneipad-gpu/
The point of Grand Central Dispatch was to take the complexity of task (thread) scheduling out of the developer's hands. Developers can simply create a queue and submit tasks to it... the system then handles which processing units to send the tasks to. This happens at run-time, so, yes, software will automatically see the benefits of having more cores, but only if their apps were designed to be multi-threaded (use GCD) in the first place.
I know all apps would need to be recompiled against a new set of ARM-based api's but how many apps do you believe have NOT been designed to be multi-threaded? I'm sure there are programmers from major vendors that have been lazy when writing code and didn't add GCD but is GCD something that most programmers would simply use as a default or does it require a totally different programming environment to start with?
I'm just trying to get an idea of how complex this would be. I thought Xcode was able to handle a lot of conversions in the background, making wholesale changes easier than editing code line by line. I know programmers complained when Apple "forced" them to get rid of old PPC code. Would an ARM conversion be easier or more difficult than the PPC to Intel conversion?
It is a well-known fact that the transition to Intel increased Apple's Mac sales dramatically. Also, Parallels and VMWare are high-selling products on the Mac platform. I don't think Apple will drop the Intel architecture on their main lineup any time soon. They could conceivably do it on an ultra-low-end chromebook-type e-mail reader, if that's what this new 12" one-USB thing turns out to be, but even that is fraught with danger — just look at how Microsoft's low-end Surface model, being slow and incompatible with everything, destroyed the perception of that line.
I am not missing anything. The average mail, messaging, web client, etc. would work well on these "slower cores." They are fast enough to run mail, web browsing, text edit, and all the other mundane stuff that these single cores make up.
The very fact that there are single threaded tasks makes the lot of smaller cores more ideal as each core can run a more limited set of single threaded cores, but also be available for the massively parallel tasks that come down the pipe. No one said the system would not be able to spread tasks across cores if needed.
And, at least up to now, the Samsung ones are really 4 core processors that tag team depending on need, they are not really 8 core processors, if I understand that correctly. Just like Apple went to 3 cores in the A8X.
Let me clarify. You cannot spread a thread across cores. The reason servers have many cores is because they run many threads at once, thats why they are fast. All of those mail apps and web browsers run single threaded and would benefit from a faster single thread.
As for the samsung chips, you are not understanding it correctly. What it has is 4 high performance and high power usage cores and 4 low power and low performance cores. It is supposed to use any combination as it sees fit. We both know how well that works.