As I hinted at during our interview with Krisztián Flautner, ARM was quite pleased with how things went with our Peter Greenhalgh ATE that it's going to be giving us access to more key folks over the coming weeks/months. I want to thank all of you for your questions for Krisztián in our last Ask the Experts post, and I want to thank Krisztián for taking the time to respond to you all directly. If you haven't read through the Q&A I'd recommend doing so.

Today I'll be doing a live Google Hangout with Mike Muller, ARM's Chief Technology Officer. Mike Muller was one of the original founders of ARM. We originally scheduled this hangout for late June but had some technical issues with the stream and had to reschedule. 

The Hangout will happen today, Wednesday, July 2, 2014 at 1PM ET. I'll update this post with an embedded feed when we get started. If you've got any questions you want to ask ARM's CTO, give them some thought - we may be able to get them answered live tomorrow.

Update: Here's the feed, we will be starting in 15 minutes:

POST A COMMENT

23 Comments

View All Comments

  • chrone - Friday, June 20, 2014 - link

    I have been waiting for Intel to come to the rescue since 2008. Hope it will deliver. :D Reply
  • name99 - Thursday, July 03, 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.)
    Reply
  • darkich - Sunday, July 06, 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.
    Reply
  • 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. Reply
  • BMNify - Wednesday, July 02, 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 see

    it just takes "Having the Courage to Design in 3D TSVs" as Francoise von Trapp says...
    Reply
  • Drazick - Friday, June 20, 2014 - link

    It seems you do use Google Hangout.
    Why don't you put effort into your Google+ Page?
    Reply
  • chrone - Friday, June 20, 2014 - link

    +1 on this. Would to interact more on G+ thesedays. :D Reply
  • pilgrim@beart.org.uk - Wednesday, July 02, 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. Reply
  • BMNify - Wednesday, July 02, 2014 - link

    actually i say that VLC Visible light communication http://visiblelightcomm.com/ is the right way to interconnect tour person aria network Mike Reply
  • tipoo - Wednesday, July 02, 2014 - link

    Could we get some timestamps per subject? Reply

Log in

Don't have an account? Sign up now