So, this is going to be an incredibly stupid, uninformed question, but I'll ask anyways:
Does this have to do with the APIs are developed for developers, given that Apple knows all the ins and outs of the hardware? Or am I missing the boat entirely?
Thanks.
There's no such thing as stupid questions, only stupid answers. I hope mine is satisfying.
Apple has a long history in optimizing their OS for different hardware (PPC, Intel, ARM) by keeping it flexible for implementation of new hardware features and specialized chip units.
They use tools like Shark and Instruments for many years, which enable a transparent view on performance and runtime characteristics of executed code .
They share the gained knowledge in the form of documentation, presentations (WWDC), APIs and frameworks with 3rd party developers.
So yes, I'm sure they know "all the ins and outs" especially since they design their own, customized silicon. Apple is IMHO one of the few companies with the "full understanding".
I doubt Apple would try to make the switch to ARM on their own. If Apple switches to ARM in desktops, it will probably be a transition that a fair number of PC manufacturers take.
You think Apple cares about what other PC makers do?
The 12x12 mm quote is not the die size. It's the quoted package size. (see: Package on package). The die size of the OMAP4430 is likely on the order of 60 to 80 mm^2 based on the stated features of the device.
There's no doubt about it, the A5 SoC die is comparatively big. But then again, it's got two PowerVR SGX543 cores in it. If it implemented the NEON SIMD unit and pipeline FPU, that'll make the A9 cores 30% bigger (I hear). And who knows how and why Apple floor planned the A5 to be big. Ultimately, since Apple needs on the order of 60m to 80m of them, it probably all had to do with getting the best yield at the lowest cost.
Forgive me if this has been addressed already, but is the same nanometer process required for the entire package or could Apple be saving total package size in other areas that are simply not cost effective for their competition due to economics of scale?
Yes. Kind of weird to answer as it should be obvious from the word "package" or "package-on-package".
The "A5" as a package likely consists of 2 to 3 chips: the CPU-GPU-I/O chip (the SoC proper), and one or two DRAM chips. They are stacked on top of each other in the package. And they already use different vendors for the DRAM. And people suspect that Apple will farm out the CPU-GPU-IO chip to TSMC.
A 40nm version of the A5 would be around 86mm^2 (122/sqrt(2)) - although different foundries will have different transistor densities anyway, so you can't compare directly. A 32nm chip would be 61mm^2, a 28nm chip (most likely for A6) 43mm^2 (although scaling isn't perfect either!).
Hopefully, they'll move the A5 to 40 nm this year for iPhone and iPod touch. Because next year, they better move to a dual Cortex-A15 CPU and a PowerVR 545MP2/6-series GPU, and a CPU with those features needs a 32 nm process to fit inside a smartphone.
122 mm^2 is big enough such that they may not be able to physically fit it inside a smartphone platform. The package is some 20% bigger then the A4 package. Maybe they'll have an iPhone/iPod touch specific package design, but 240 mm^2 package is pretty big. They'll have to take the iPad 3G GSM and CDMA logic board and squeeze it down to iPhone size. That's got to be tough.
Quote:
Tegra 2 doesn't include Neon vector floating point. This is quite large, apparently. Tegra 3 will include it.
Anandtech quoted Nvidia says that it's a 30% penalty (to include the Neon SIMD unit)!
Quote:
Tegra 2 also doesn't have on-package memory, unlike the A5.
Actually, on the Atrix, it does. Not sure about the Xoom or other devices.
There's no such thing as stupid questions, only stupid answers. I hope mine is satisfying.
Apple has a long history in optimizing their OS for different hardware (PPC, Intel, ARM) by keeping it flexible for implementation of new hardware features and specialized chip units.
They use tools like Shark and Instruments for many years, which enable a transparent view on performance and runtime characteristics of executed code .
They share the gained knowledge in the form of documentation, presentations (WWDC), APIs and frameworks with 3rd party developers.
So yes, I'm sure they know "all the ins and outs" especially since they design their own, customized silicon. Apple is IMHO one of the few companies with the "full understanding".
Thank you very much.
One of the things I love about this site is that I learn something every day.
You think Apple cares about what other PC makers do?
Are you crazy? Of course Apple cares if the PC market changes CPU architecture. Apple has like 8% market share in desktop PCs. Unless Apple is willing to produce its own CPU, Apple better care what the other 92% of the market is doing. The point I was trying to make is that Apple isn't qualified to make its own CPUs for desktops and servers. And, it has very very little incentive to acquire that expertise.
Apple is VERY willing to do that. Stop giving them more ideas about it.
Quote:
And, it has very very little incentive to acquire that expertise.
It has tons of incentive.
P.A. Semi making desktop chips? Means obscenely low power, an architecture built the way Apple wants it, new proprietary programming languages that take advantage of these chips, and less heat output for even thinner machines.
I find number 3 to be quite persuasive. I agree that it wouldn't be good for Apple to support two architectures with the same OS for anything but a temporary transition period. Even though Apple is the expert in ARM with mobile, ARM in desktops and servers is a whole different ball game. Mobile users will readily accept functionality restrictions in exchange for ultra portability. There is absolutely no way a Mac Pro user is going to accept those compromises. (which is why I own an iPad and a Mac Pro). I doubt Apple would try to make the switch to ARM on their own. If Apple switches to ARM in desktops, it will probably be a transition that a fair number of PC manufacturers take....which means such a change is iffy and certainly not happening anytime soon. I know the ARM community is excited about competing with Intel in desktop and server. But until we see how Intel performs with GPU integration and increased power efficiency and what ARM can do to increase clock speeds and computing power, there is no way to predict what will happen. Should be interesting....
how is a 32 bit arm architecture supposed to compete with Intel in desktops and servers? I have 12 gigs of ram in my machine, and certainly couldn't do that if it was based on ARM.
how is a 32 bit arm architecture supposed to compete with Intel in desktops and servers? I have 12 gigs of ram in my machine, and certainly couldn't do that if it was based on ARM.
Sure you could, if the OS was written appropriately. There are lots of techniques that can paste over design constraints like that. The problems are that applications programmers often goon using the APIs and make a mess of it, and the techniques run in software which makes things a bit slower than you would like (See WindowsNT for all of the above).
If you want to make a judgement, at least make it based on correct facts rather than naive bullcrap.
Sure you could, if the OS was written appropriately. There are lots of techniques that can paste over design constraints like that. The problems are that applications programmers often goon using the APIs and make a mess of it, and the techniques run in software which makes things a bit slower than you would like (See WindowsNT for all of the above).
If you want to make a judgement, at least make it based on correct facts rather than naive bullcrap.
we're specifically talking about OS X, not some random OS. And we're talking about a low end mac that developers can target with a recompile, not something that introduces new programming rules. I don't recall a single instance, dating back to the original 680x0 based NeXT days, when OS X supported paged memory to allow more physical memory than the CPU could address. And I really don't see that changing.
we're specifically talking about OS X, not some random OS. And we're talking about a low end mac that developers can target with a recompile, not something that introduces new programming rules. I don't recall a single instance, dating back to the original 680x0 based NeXT days, when OS X supported paged memory to allow more physical memory than the CPU could address. And I really don't see that changing.
You made a general comment about some mythical future CPU architecture & OS combination. You don't get to say "I have invented a future CPU, but I restrict it to running on an unadapted OS". That's pure idiocy.
So even if you are talking about OS X, you weren't talking about 10.6, or 10.7, but some future version just as mythical as the hardware you were discussing. Once that mythological line is crossed, every counter-argument you possibly have trying to restrict it is as broken as a dick that won't respond to Viagra or Cialis. Face it, your above post is flaccid and impotent.
I don't see the hardware changing to your mythological composition either, which make your whinging about having to hold to consistent rules in your own mythology given some past reality even less relevant.
You made a general comment about some mythical future CPU architecture & OS combination. You don't get to say "I have invented a future CPU, but I restrict it to running on an unadapted OS". That's pure idiocy.
So even if you are talking about OS X, you weren't talking about 10.6, or 10.7, but some future version just as mythical as the hardware you were discussing. Once that mythological line is crossed, every counter-argument you possibly have trying to restrict it is as broken as a dick that won't respond to Viagra or Cialis. Face it, your above post is flaccid and impotent.
I don't see the hardware changing to your mythological composition either, which make your whinging about having to hold to consistent rules in your own mythology given some past reality even less relevant.
changing CPUs for the mac wasn't my idea, and is something I said is unlikely to happen. I was simply pointing out an obstacle in Apple doing something like that.
changing CPUs for the mac wasn't my idea, and is something I said is unlikely to happen. I was simply pointing out an obstacle in Apple doing something like that.
So your defense is "it wasn't my idea!" and you didn't think it through before you jumped into the thread? That's not much better...
So your defense is "it wasn't my idea!" and you didn't think it through before you jumped into the thread? That's not much better...
please read the thread. My first post on the topic said
Quote:
I'd be really surprised to see anything like that. Any gap between the current iPad and the 11" MacBook air will be filled with more powerful iPads, not less powerful Macs that require all new universal binaries.
It wasn't my idea, I wasn't in favor of it, I listed reasons why it would be a bad idea, you apparently agree with me, but spent your time arguing against one of my reasons against it.
It wasn't my idea, I wasn't in favor of it, I listed reasons why it would be a bad idea, you apparently agree with me, but spent your time arguing against one of my reasons against it.
No, one of your supposed reasons was broken, I pointed that out. Then you tried to paper over it by claiming the hardware would change and dismissing the possibility of OS changes because ~we are talking about OS X~. Then when called on that fictitious cherry pick you rolled to ~it wasn't my idea~.
I don't agree with you, the reasons for why things don't work are more important than blind misguided statements. We aren't saying the same things just because you pulled a blind squirrel. Someday as the tech world inexorably moves on, the reasons something didn't work very well will get fixed. But your broken reason can never get fixed, and potentially, incorrectly, leading some that don't understand deeply to believe something very possible isn't. That's not good.
I find your sloppiness in technical knowledge followed by attempted slipperiness to be of little value added, and don't see the need to let it sit without correction. Repeated excuses don't change anything, they just illustrate unwillingness to understand.
Apple is VERY willing to do that. Stop giving them more ideas about it.
It has tons of incentive.
P.A. Semi making desktop chips? Means obscenely low power, an architecture built the way Apple wants it, new proprietary programming languages that take advantage of these chips, and less heat output for even thinner machines.
changing CPUs for the mac wasn't my idea, and is something I said is unlikely to happen. I was simply pointing out an obstacle in Apple doing something like that.
There is something you should know about the Mach Kernel and the yellow box, Before being MacOS X and iOS, NeXTStep was created on a 68030 @ 33mHz, when NeXT stopped making their 68040 based Next Workstation, NeXTStep OS became OpenStep (the yellow box), which essentially was an application layer on top of Windows. Apple is still using the yellow box for porting their Objectives-C Apps like Safari and iTunes on Windows, and Apple could if they want port any Cocoa apps into native Windows apps . Mach-O app have hability to pack multiples CPU arch in the same executable. Beside, now Apple have all ready goes beyond NeXT with LLVM and JIT executables, making able to share the same apps on many system. The yellow box could really challenge JavaVM on his own turf.
I don't know Apple's long term plans, but they got all the technology to handle any platform the future will come with, Apple late OS effort have been put on exponential numbers of core and diversity with OpenCL and Grand Central. Think of the power of 25 x 1 watt A5 vs 1 x 25 watts core i7. I'm sure the iOS kernel and Frameworks are all ready using all optimization they can for the new mult-core GPU and A9 core. Something Google can't do on Android because they don't fully control his kernel, drivers and JavaVM. This is why Honeycomb is performing so badly and Google have been force to close the source code.. To give them some time to clean the big licensing mess they got in.
One day we shall see PCs has big clunky muscle cars.
Comments
http://www.windowsfordevices.com/c/a...unveils-OMAP4/
So, this is going to be an incredibly stupid, uninformed question, but I'll ask anyways:
Does this have to do with the APIs are developed for developers, given that Apple knows all the ins and outs of the hardware? Or am I missing the boat entirely?
Thanks.
There's no such thing as stupid questions, only stupid answers. I hope mine is satisfying.
Apple has a long history in optimizing their OS for different hardware (PPC, Intel, ARM) by keeping it flexible for implementation of new hardware features and specialized chip units.
They use tools like Shark and Instruments for many years, which enable a transparent view on performance and runtime characteristics of executed code .
They share the gained knowledge in the form of documentation, presentations (WWDC), APIs and frameworks with 3rd party developers.
So yes, I'm sure they know "all the ins and outs" especially since they design their own, customized silicon. Apple is IMHO one of the few companies with the "full understanding".
I doubt Apple would try to make the switch to ARM on their own. If Apple switches to ARM in desktops, it will probably be a transition that a fair number of PC manufacturers take.
You think Apple cares about what other PC makers do?
In terms of CPU size, I believe that the OMAP4430 (12mm x 12mm) is even larger than the Apple A5 (12mm x 10mm).
http://www.windowsfordevices.com/c/a...unveils-OMAP4/
The 12x12 mm quote is not the die size. It's the quoted package size. (see: Package on package). The die size of the OMAP4430 is likely on the order of 60 to 80 mm^2 based on the stated features of the device.
There's no doubt about it, the A5 SoC die is comparatively big. But then again, it's got two PowerVR SGX543 cores in it. If it implemented the NEON SIMD unit and pipeline FPU, that'll make the A9 cores 30% bigger (I hear). And who knows how and why Apple floor planned the A5 to be big. Ultimately, since Apple needs on the order of 60m to 80m of them, it probably all had to do with getting the best yield at the lowest cost.
Forgive me if this has been addressed already, but is the same nanometer process required for the entire package or could Apple be saving total package size in other areas that are simply not cost effective for their competition due to economics of scale?
Yes. Kind of weird to answer as it should be obvious from the word "package" or "package-on-package".
The "A5" as a package likely consists of 2 to 3 chips: the CPU-GPU-I/O chip (the SoC proper), and one or two DRAM chips. They are stacked on top of each other in the package. And they already use different vendors for the DRAM. And people suspect that Apple will farm out the CPU-GPU-IO chip to TSMC.
A 40nm version of the A5 would be around 86mm^2 (122/sqrt(2)) - although different foundries will have different transistor densities anyway, so you can't compare directly. A 32nm chip would be 61mm^2, a 28nm chip (most likely for A6) 43mm^2 (although scaling isn't perfect either!).
Hopefully, they'll move the A5 to 40 nm this year for iPhone and iPod touch. Because next year, they better move to a dual Cortex-A15 CPU and a PowerVR 545MP2/6-series GPU, and a CPU with those features needs a 32 nm process to fit inside a smartphone.
122 mm^2 is big enough such that they may not be able to physically fit it inside a smartphone platform. The package is some 20% bigger then the A4 package. Maybe they'll have an iPhone/iPod touch specific package design, but 240 mm^2 package is pretty big. They'll have to take the iPad 3G GSM and CDMA logic board and squeeze it down to iPhone size. That's got to be tough.
Tegra 2 doesn't include Neon vector floating point. This is quite large, apparently. Tegra 3 will include it.
Anandtech quoted Nvidia says that it's a 30% penalty (to include the Neon SIMD unit)!
Tegra 2 also doesn't have on-package memory, unlike the A5.
Actually, on the Atrix, it does. Not sure about the Xoom or other devices.
There's no such thing as stupid questions, only stupid answers. I hope mine is satisfying.
Apple has a long history in optimizing their OS for different hardware (PPC, Intel, ARM) by keeping it flexible for implementation of new hardware features and specialized chip units.
They use tools like Shark and Instruments for many years, which enable a transparent view on performance and runtime characteristics of executed code .
They share the gained knowledge in the form of documentation, presentations (WWDC), APIs and frameworks with 3rd party developers.
So yes, I'm sure they know "all the ins and outs" especially since they design their own, customized silicon. Apple is IMHO one of the few companies with the "full understanding".
Thank you very much.
One of the things I love about this site is that I learn something every day.
You think Apple cares about what other PC makers do?
Are you crazy?
Unless Apple is willing to produce its own CPU...
Apple is VERY willing to do that. Stop giving them more ideas about it.
And, it has very very little incentive to acquire that expertise.
It has tons of incentive.
P.A. Semi making desktop chips? Means obscenely low power, an architecture built the way Apple wants it, new proprietary programming languages that take advantage of these chips, and less heat output for even thinner machines.
That's just the superficial incentive.
I find number 3 to be quite persuasive. I agree that it wouldn't be good for Apple to support two architectures with the same OS for anything but a temporary transition period. Even though Apple is the expert in ARM with mobile, ARM in desktops and servers is a whole different ball game. Mobile users will readily accept functionality restrictions in exchange for ultra portability. There is absolutely no way a Mac Pro user is going to accept those compromises. (which is why I own an iPad and a Mac Pro). I doubt Apple would try to make the switch to ARM on their own. If Apple switches to ARM in desktops, it will probably be a transition that a fair number of PC manufacturers take....which means such a change is iffy and certainly not happening anytime soon. I know the ARM community is excited about competing with Intel in desktop and server. But until we see how Intel performs with GPU integration and increased power efficiency and what ARM can do to increase clock speeds and computing power, there is no way to predict what will happen. Should be interesting....
how is a 32 bit arm architecture supposed to compete with Intel in desktops and servers? I have 12 gigs of ram in my machine, and certainly couldn't do that if it was based on ARM.
how is a 32 bit arm architecture supposed to compete with Intel in desktops and servers? I have 12 gigs of ram in my machine, and certainly couldn't do that if it was based on ARM.
Sure you could, if the OS was written appropriately. There are lots of techniques that can paste over design constraints like that. The problems are that applications programmers often goon using the APIs and make a mess of it, and the techniques run in software which makes things a bit slower than you would like (See WindowsNT for all of the above).
If you want to make a judgement, at least make it based on correct facts rather than naive bullcrap.
i posted twice..don't know how to delete.
Welcome to the forum.
Sure you could, if the OS was written appropriately. There are lots of techniques that can paste over design constraints like that. The problems are that applications programmers often goon using the APIs and make a mess of it, and the techniques run in software which makes things a bit slower than you would like (See WindowsNT for all of the above).
If you want to make a judgement, at least make it based on correct facts rather than naive bullcrap.
we're specifically talking about OS X, not some random OS. And we're talking about a low end mac that developers can target with a recompile, not something that introduces new programming rules. I don't recall a single instance, dating back to the original 680x0 based NeXT days, when OS X supported paged memory to allow more physical memory than the CPU could address. And I really don't see that changing.
we're specifically talking about OS X, not some random OS. And we're talking about a low end mac that developers can target with a recompile, not something that introduces new programming rules. I don't recall a single instance, dating back to the original 680x0 based NeXT days, when OS X supported paged memory to allow more physical memory than the CPU could address. And I really don't see that changing.
You made a general comment about some mythical future CPU architecture & OS combination. You don't get to say "I have invented a future CPU, but I restrict it to running on an unadapted OS". That's pure idiocy.
So even if you are talking about OS X, you weren't talking about 10.6, or 10.7, but some future version just as mythical as the hardware you were discussing. Once that mythological line is crossed, every counter-argument you possibly have trying to restrict it is as broken as a dick that won't respond to Viagra or Cialis. Face it, your above post is flaccid and impotent.
I don't see the hardware changing to your mythological composition either, which make your whinging about having to hold to consistent rules in your own mythology given some past reality even less relevant.
You made a general comment about some mythical future CPU architecture & OS combination. You don't get to say "I have invented a future CPU, but I restrict it to running on an unadapted OS". That's pure idiocy.
So even if you are talking about OS X, you weren't talking about 10.6, or 10.7, but some future version just as mythical as the hardware you were discussing. Once that mythological line is crossed, every counter-argument you possibly have trying to restrict it is as broken as a dick that won't respond to Viagra or Cialis. Face it, your above post is flaccid and impotent.
I don't see the hardware changing to your mythological composition either, which make your whinging about having to hold to consistent rules in your own mythology given some past reality even less relevant.
changing CPUs for the mac wasn't my idea, and is something I said is unlikely to happen. I was simply pointing out an obstacle in Apple doing something like that.
changing CPUs for the mac wasn't my idea, and is something I said is unlikely to happen. I was simply pointing out an obstacle in Apple doing something like that.
So your defense is "it wasn't my idea!" and you didn't think it through before you jumped into the thread? That's not much better...
So your defense is "it wasn't my idea!" and you didn't think it through before you jumped into the thread? That's not much better...
please read the thread. My first post on the topic said
I'd be really surprised to see anything like that. Any gap between the current iPad and the 11" MacBook air will be filled with more powerful iPads, not less powerful Macs that require all new universal binaries.
It wasn't my idea, I wasn't in favor of it, I listed reasons why it would be a bad idea, you apparently agree with me, but spent your time arguing against one of my reasons against it.
It wasn't my idea, I wasn't in favor of it, I listed reasons why it would be a bad idea, you apparently agree with me, but spent your time arguing against one of my reasons against it.
No, one of your supposed reasons was broken, I pointed that out. Then you tried to paper over it by claiming the hardware would change and dismissing the possibility of OS changes because ~we are talking about OS X~. Then when called on that fictitious cherry pick you rolled to ~it wasn't my idea~.
I don't agree with you, the reasons for why things don't work are more important than blind misguided statements. We aren't saying the same things just because you pulled a blind squirrel. Someday as the tech world inexorably moves on, the reasons something didn't work very well will get fixed. But your broken reason can never get fixed, and potentially, incorrectly, leading some that don't understand deeply to believe something very possible isn't. That's not good.
I find your sloppiness in technical knowledge followed by attempted slipperiness to be of little value added, and don't see the need to let it sit without correction. Repeated excuses don't change anything, they just illustrate unwillingness to understand.
Apple is VERY willing to do that. Stop giving them more ideas about it.
It has tons of incentive.
P.A. Semi making desktop chips? Means obscenely low power, an architecture built the way Apple wants it, new proprietary programming languages that take advantage of these chips, and less heat output for even thinner machines.
That's just the superficial incentive.
You said it way better than I could've. Good job.
changing CPUs for the mac wasn't my idea, and is something I said is unlikely to happen. I was simply pointing out an obstacle in Apple doing something like that.
There is something you should know about the Mach Kernel and the yellow box, Before being MacOS X and iOS, NeXTStep was created on a 68030 @ 33mHz, when NeXT stopped making their 68040 based Next Workstation, NeXTStep OS became OpenStep (the yellow box), which essentially was an application layer on top of Windows. Apple is still using the yellow box for porting their Objectives-C Apps like Safari and iTunes on Windows, and Apple could if they want port any Cocoa apps into native Windows apps . Mach-O app have hability to pack multiples CPU arch in the same executable. Beside, now Apple have all ready goes beyond NeXT with LLVM and JIT executables, making able to share the same apps on many system. The yellow box could really challenge JavaVM on his own turf.
I don't know Apple's long term plans, but they got all the technology to handle any platform the future will come with, Apple late OS effort have been put on exponential numbers of core and diversity with OpenCL and Grand Central. Think of the power of 25 x 1 watt A5 vs 1 x 25 watts core i7. I'm sure the iOS kernel and Frameworks are all ready using all optimization they can for the new mult-core GPU and A9 core. Something Google can't do on Android because they don't fully control his kernel, drivers and JavaVM. This is why Honeycomb is performing so badly and Google have been force to close the source code.. To give them some time to clean the big licensing mess they got in.
One day we shall see PCs has big clunky muscle cars.