Mr. Flautner didn't reply to my question, maybe he was not in charge of it. I repeat: ------------------------------------------------------------------------------------------------------------------------ What security measures does ARM have against industrial espionage and the now infamous NSA meddling with firmwares, software and anything computing related? Have ARM HQ been infiltrated? Are ARM designs safe, or contain some hardware "backdoors" for i.e. elevating rights (userspace to kernel, TrustZone, etc.) ? Are sources of ARM processors open to security audits? Does ARM do security audit on its own? Are sources versioned in a way that would detect "hacks" - changes(backdoors) to the sources ?
And vice versa, does ARM have access to partners' IP that means third party ARM processors sources, or modified commodity ARM designs? To review them for security purposes?
These are all questions I've always wished to ask.
+1, too. I think this is important, and shouldn't be easily dismissed by ARM, as it can only foster distrust. We're already seeing countries trying to avoid US software and hardware because of all the insane spying, and it's probably a matter of time before they start focusing on UK/GCHQ, too.
Obviously, they're going to answer "No." to that, regardless of what's happening, but hopefully they can offer further proof and transparency for their chips.
Will ARM pursue higher single thread cpu performance and overall gpu performance to smoother the user experience on Android device especially on the transition animation?
Hope you guys will targeting lesser soc throttling due to SOC IPC improvement in lower clock speed frequency. :)
It's usually more power efficient to scale performance through IPC than clock speed. So much so that major companies are willing to drop clock speeds, despite the advertising advantage of scaling frequency.
Well, I think there is some degree of truth to it, I mean look at the Apple A7. I think the issue is that it is really difficult to manage power consumption in a wide design. So, while, making a wide design may not be that difficult, making a wide and highly efficient design is probably quite difficult.
Yeah, and it takes a lot of die area to get that performance. Silvermont performs similarly and takes far less space, and that's without an "L3" cache.
WTF are you talking about? The total A7 package is about 100mm^2, the CPU part is about 17mm^2. That does not include the "L3", but the "L3" on the A7 is not especially high performance (150 cycles to load from as opposed to 250 cycles from RAM), is far from the CPU, and appears to be primarily for more efficient communication with the GPU.
Meanwhile for Merrifield, the only information I have seen is that the PACKAGE size is 144mm^2. This obviously does not give us the CPU size, or even the SoC size; but it does suggest that the CPU is substantially larger than Cyclone, given that Apple fits quite a bit more stuff onto a (probably) smaller SoC; and using a larger process.
More generally there are two issues. There is the historical issue that we have a fair amount of experience regarding wide vs fast designs (including a few examples within the same ISA, eg Intel pushing P4 as a fast design, IBM pushing the POWER5 as a fast design). Pretty uniformly, after the dust has settled, the decision has been to revert to wide designs after the fast design. It may be hard to make a wider design low power, but it appears to be even HARDER to make a fast design lower power.
Secondly there is a theoretical point. If, at some point, we actually move to kilo-instruction-processing designs, there will be a substantially better reason to increase width. Right now Power8 is 8-wide, but feeds that with 8-wide SMT. A KIP which stored memory dependent instructions in multiple dependency strings and fed those strings back through the CPU after the memory load was resolved would effectively have two or three or four independent instruction "nano-threads" running at any one time, constructed on the fly from a single OS thread.
Intel appears to be terrified to implement a KIP in x86 because verifying their existing micro-architecture is so horrifying, and a KIP adds a whole new level of complexity. IBM appear to be in a place where they don't need it --- their particular target workloads mostly appear to be quite happy to run as zillions of threads. Apple, however is in a very interesting place. They obviously want higher per-thread performance and (at least so far) are unconvinced of the value of many threads. Moreover their macroscalar patent from a few years ago describes something very similar to the same machinery underlying a KIP. Finally they (especially once they drop the 32-bit subset of AArch64) are in a position where they can very easily "opportunistically" widen their CPU. Fetch to 8-wide, and decode to say 6-wide are easy with ARM-64, whereas Intel has a vastly more difficult time widening decode. Point is, there are plenty of reasons to believe that Apple will continue pushing for a wider CPU, and more aggressively than Intel. (Though not with A8; A8 I suspect will have a largely unchanged core, just a higher frequency from better process, and the interesting changes for A8 will largely be in the uncore.)
I believe that Performance = IPC x Clock Speed. Qualcomm keeps pushing the clock speed race where in tropical country, the SOC most of the time throttles 1-1.2GHz range when in use which translates slower performance. Just my two cents though as I only feel slight performance bump going from Nexus 4 to Nexus 5 devices due to the moist heat here, 28-33C.
i lost confidence in Qualcomm the day they said octacore is no good, the fact is multicore and slower, wider data path's are the obvious path to take now,in the case of cortex that includes using WideIO2/HMC,even wider CoreLink CCN interconnect with a generic SiPotonic's etc, will Mike and Co provide it to the end consumer in a real medium term, we shall see
it just takes "Having the Courage to Design in 3D TSVs" as Francoise von Trapp says...
Mike's rightly describing a layered model, with open interop needed at each level, and in each part of the infrastructure. The open IETF protocols that Sensinode helped create help get the internet right to the edge (so are more about IoT devices). Meanwhile, in another part of the infrastructure, initiatives like HyperCat (http://wiki.1248.io) are starting to help create open interop between IoT services and apps (so more about IoT data) which is perhaps more at the level that Anand is asking about.
He makes a great point of chips diverging to serve different niches, which is exactly where ARM's strength is, compared to Intel. Intel doesn't do well in serving 100 different markets with different chips, each chip selling in low volumes. Intel has high cost structures, especially since it's making its own chips, so it can't make 100 different chips, in 10,000 unit each.
But ARM can just design the IP, and then whatever chip maker pops up and thinks they can profitably sell it, can take it, and dominate that market, on the cheap.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
23 Comments
Back to Article
lada - Wednesday, June 18, 2014 - link
Mr. Flautner didn't reply to my question, maybe he was not in charge of it. I repeat:------------------------------------------------------------------------------------------------------------------------
What security measures does ARM have against industrial espionage and the now infamous NSA meddling with firmwares, software and anything computing related? Have ARM HQ been infiltrated? Are ARM designs safe, or contain some hardware "backdoors" for i.e. elevating rights (userspace to kernel, TrustZone, etc.) ? Are sources of ARM processors open to security audits? Does ARM do security audit on its own? Are sources versioned in a way that would detect "hacks" - changes(backdoors) to the sources ?
And vice versa, does ARM have access to partners' IP that means third party ARM processors sources, or modified commodity ARM designs? To review them for security purposes?
These are all questions I've always wished to ask.
ddriver - Thursday, June 19, 2014 - link
+1This is the billion dollar question, everything else is relative drivel.
Krysto - Wednesday, July 2, 2014 - link
+1, too. I think this is important, and shouldn't be easily dismissed by ARM, as it can only foster distrust. We're already seeing countries trying to avoid US software and hardware because of all the insane spying, and it's probably a matter of time before they start focusing on UK/GCHQ, too.Obviously, they're going to answer "No." to that, regardless of what's happening, but hopefully they can offer further proof and transparency for their chips.
ddriver - Thursday, July 3, 2014 - link
My expectations were confirmed, the question was not even vaguely mentioned... AT afraid to ask questions of actual significance...chrone - Thursday, June 19, 2014 - link
Will ARM pursue higher single thread cpu performance and overall gpu performance to smoother the user experience on Android device especially on the transition animation?Hope you guys will targeting lesser soc throttling due to SOC IPC improvement in lower clock speed frequency. :)
Homeles - Thursday, June 19, 2014 - link
Why does everyone think IPC is a magic bullet?Soulwager - Thursday, June 19, 2014 - link
It's usually more power efficient to scale performance through IPC than clock speed. So much so that major companies are willing to drop clock speeds, despite the advertising advantage of scaling frequency.Homeles - Thursday, June 19, 2014 - link
This is far too simplistic to be true. If it were true, we'd see extremely wide designs everywhere.extide - Thursday, June 19, 2014 - link
Well, I think there is some degree of truth to it, I mean look at the Apple A7. I think the issue is that it is really difficult to manage power consumption in a wide design. So, while, making a wide design may not be that difficult, making a wide and highly efficient design is probably quite difficult.Homeles - Thursday, June 19, 2014 - link
Yeah, and it takes a lot of die area to get that performance. Silvermont performs similarly and takes far less space, and that's without an "L3" cache.chrone - Friday, June 20, 2014 - link
I have been waiting for Intel to come to the rescue since 2008. Hope it will deliver. :Dname99 - Thursday, July 3, 2014 - link
WTF are you talking about?The total A7 package is about 100mm^2, the CPU part is about 17mm^2. That does not include the "L3", but the "L3" on the A7 is not especially high performance (150 cycles to load from as opposed to 250 cycles from RAM), is far from the CPU, and appears to be primarily for more efficient communication with the GPU.
Meanwhile for Merrifield, the only information I have seen is that the PACKAGE size is 144mm^2.
This obviously does not give us the CPU size, or even the SoC size; but it does suggest that the CPU is substantially larger than Cyclone, given that Apple fits quite a bit more stuff onto a (probably) smaller SoC; and using a larger process.
More generally there are two issues.
There is the historical issue that we have a fair amount of experience regarding wide vs fast designs (including a few examples within the same ISA, eg Intel pushing P4 as a fast design, IBM pushing the POWER5 as a fast design). Pretty uniformly, after the dust has settled, the decision has been to revert to wide designs after the fast design. It may be hard to make a wider design low power, but it appears to be even HARDER to make a fast design lower power.
Secondly there is a theoretical point. If, at some point, we actually move to kilo-instruction-processing designs, there will be a substantially better reason to increase width. Right now Power8 is 8-wide, but feeds that with 8-wide SMT. A KIP which stored memory dependent instructions in multiple dependency strings and fed those strings back through the CPU after the memory load was resolved would effectively have two or three or four independent instruction "nano-threads" running at any one time, constructed on the fly from a single OS thread.
Intel appears to be terrified to implement a KIP in x86 because verifying their existing micro-architecture is so horrifying, and a KIP adds a whole new level of complexity. IBM appear to be in a place where they don't need it --- their particular target workloads mostly appear to be quite happy to run as zillions of threads.
Apple, however is in a very interesting place. They obviously want higher per-thread performance and (at least so far) are unconvinced of the value of many threads. Moreover their macroscalar patent from a few years ago describes something very similar to the same machinery underlying a KIP. Finally they (especially once they drop the 32-bit subset of AArch64) are in a position where they can very easily "opportunistically" widen their CPU. Fetch to 8-wide, and decode to say 6-wide are easy with ARM-64, whereas Intel has a vastly more difficult time widening decode.
Point is, there are plenty of reasons to believe that Apple will continue pushing for a wider CPU, and more aggressively than Intel. (Though not with A8; A8 I suspect will have a largely unchanged core, just a higher frequency from better process, and the interesting changes for A8 will largely be in the uncore.)
darkich - Sunday, July 6, 2014 - link
Funniest part is the one you haven't addressed: "silvermont performs similarly". Horsesh!t.Silvermont core is nowhere near the Cyclone, it barely trades blows with the Krait and A15 actually.
chrone - Friday, June 20, 2014 - link
I believe that Performance = IPC x Clock Speed. Qualcomm keeps pushing the clock speed race where in tropical country, the SOC most of the time throttles 1-1.2GHz range when in use which translates slower performance. Just my two cents though as I only feel slight performance bump going from Nexus 4 to Nexus 5 devices due to the moist heat here, 28-33C.BMNify - Wednesday, July 2, 2014 - link
i lost confidence in Qualcomm the day they said octacore is no good, the fact is multicore and slower, wider data path's are the obvious path to take now,in the case of cortex that includes using WideIO2/HMC,even wider CoreLink CCN interconnect with a generic SiPotonic's etc, will Mike and Co provide it to the end consumer in a real medium term, we shall seeit just takes "Having the Courage to Design in 3D TSVs" as Francoise von Trapp says...
Drazick - Friday, June 20, 2014 - link
It seems you do use Google Hangout.Why don't you put effort into your Google+ Page?
chrone - Friday, June 20, 2014 - link
+1 on this. Would to interact more on G+ thesedays. :D[email protected] - Wednesday, July 2, 2014 - link
Mike's rightly describing a layered model, with open interop needed at each level, and in each part of the infrastructure. The open IETF protocols that Sensinode helped create help get the internet right to the edge (so are more about IoT devices). Meanwhile, in another part of the infrastructure, initiatives like HyperCat (http://wiki.1248.io) are starting to help create open interop between IoT services and apps (so more about IoT data) which is perhaps more at the level that Anand is asking about.BMNify - Wednesday, July 2, 2014 - link
actually i say that VLC Visible light communication http://visiblelightcomm.com/ is the right way to interconnect tour person aria network Miketipoo - Wednesday, July 2, 2014 - link
Could we get some timestamps per subject?victorson - Thursday, July 3, 2014 - link
+1Krysto - Thursday, July 3, 2014 - link
He makes a great point of chips diverging to serve different niches, which is exactly where ARM's strength is, compared to Intel. Intel doesn't do well in serving 100 different markets with different chips, each chip selling in low volumes. Intel has high cost structures, especially since it's making its own chips, so it can't make 100 different chips, in 10,000 unit each.But ARM can just design the IP, and then whatever chip maker pops up and thinks they can profitably sell it, can take it, and dominate that market, on the cheap.
Krysto - Thursday, July 3, 2014 - link
Intel can't fight that. It's death by a thousand cuts. It's like the lion fighting 1 million ants.