Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 13 submissions in the queue.
posted by martyb on Thursday December 07, @10:22AM   Printer-friendly
from the is-that-a-Cray-in-your-pocket? dept.

Snapdragon 845 is a newly announced Qualcomm ARM system-on-a-chip (SoC) built on a 10nm "Low Power Plus" process. It is the first SoC to implement ARM's new DynamiQ clustering scheme:

The Snapdragon 845 is a large step in terms of SoC architectures as it's the first to employ ARM's DynamiQ CPU cluster organization. Quickly explained, DynamIQ enables the various different CPU cores within an SoC to be hosted within the same cluster and cache hierarchy, as opposed to having separate discrete clusters with no shared cache between them (with coherency instead happening over an interconnect such as ARM's CCI). This major transition is probably the largest to date that we've seen in modern mobile smartphone ARM consumer SoCs.

[...] The Kryo 385 gold/performance cluster runs at up to 2.8GHz, which is a 14% frequency increase over the 2.45GHz of the Snapdragon 835's CPU core. But we also have to remember that given that the new CPU cores are likely based on A75's we should be expecting IPC gains of up to 22-34% based on use-cases, bringing the overall expected performance improvement to 25-39%. Qualcomm promises a 25-30% increase so we're not far off from ARM's projections.

The silver/efficiency cluster is running at 1.8GHz, this is clocked slightly slower than the A53's on the Snapdragon 835 however the maximum clocks of the efficiency cluster is mainly determined by where the efficiency curve of the performance cluster intersects. Nevertheless the efficiency cores promise 15% boost in performance compared to its predecessor.

The Adreno 630 GPU should provide up to 30% better performance than the Snapdragon 835's Adreno 540 at the same level of power consumption. Snapdragon 845 devices can record (encode) 2160p60 10-bit H.265 video, compared to 2160p30 for Snapdragon 835.

Also at The Verge, CNET, TechCrunch, BGR, and 9to5Google.

Previously: Qualcomm's Snapdragon 835 Detailed: 3 Billion Transistors on a 10nm Process


Original Submission

Related Stories

Qualcomm's Snapdragon 835 Detailed: 3 Billion Transistors on a 10nm Process 8 comments

From Anandtech.com:

Qualcomm previously revealed the name of its new high-end SoC, but today at CES 2017 it discussed the Snapdragon 835 in greater detail. Replacing the Snapdragon 820/821 as the pinnacle processor in its lineup, the 835 is the first commercial SoC to use Samsung's 10nm "10LPE" FinFET manufacturing node. Qualcomm did not disclose die size, but it said the overall package size is 35% smaller than the Snapdragon 820 and contains more than 3 billion transistors. Samsung says its third-generation FinFET node "allows up to a 30% increase in area efficiency with 27% higher performance or up to 40% lower power consumption" relative to its first-generation 14nm 14LPE node at the same frequency, so Snapdragon 835's process advantage over the 820, which uses Samsung's second-generation 14LPP node, will be a bit less.

[...] Qualcomm finds itself in a much different position today compared to one year ago when it launched the Snapdragon 820. Back then, it was on the hot seat after its previous flagship products, the Snapdragon 808 and 810, failed to meet expectations. Qualcomm's implementation of ARM's Cortex-A57 CPU core and TSMC's last 20nm planar process were not a good combination, resulting in a generation of flagship phones that struggled to meet or exceed the performance of older models and exhibited higher than normal skin temperatures. The success of Snapdragon 820 would be crucial to regaining its partner's trust and restoring its image with consumers. The 820 was pivotal for another reason too: It introduced Qualcomm's first custom 64-bit CPU core, Kryo. Creating a custom CPU (or GPU/DSP/ISP) is one way for SoC vendors to differentiate their products and establish themselves as innovators. Snapdragon 810's use of stock ARM cores could be construed as a step backwards then after previous Snapdragon SoCs used Qualcomm's custom Krait CPUs. Apple's prior introduction of a custom 64-bit CPU, which caught everyone by surprise, only added fuel to the fire.


Original Submission

ARM's DynamIQ Introduces Variable Core-Configuration Clusters 20 comments

ARM will replace the big.LITTLE cluster design with a new one that allows up to 8 CPU cores per cluster, different types of cores within a cluster, and anywhere from one to many (unlimited?) clusters:

The first stage of DynamIQ is a larger cluster paradigm - which means up to eight cores per cluster. But in a twist, there can be a variable core design within a cluster. Those eight cores could be different cores entirely, from different ARM Cortex-A families in different configurations.

Many questions come up here, such as how the cache hierarchy will allow threads to migrate between cores within a cluster (perhaps similar to how threads migrate between clusters on big.Little today), even when cores have different cache arrangements. ARM did not yet go into that level of detail, however we were told that more information will be provided in the coming months.

Each variable core-configuration cluster will be a part of a new fabric, with uses additional power saving modes and aims to provide much lower latency. The underlying design also allows each core to be controlled independently for voltage and frequency, as well as sleep states. Based on the slide diagrams, various other IP blocks, such as accelerators, should be able to be plugged into this fabric and benefit from that low latency. ARM quoted elements such as safety critical automotive decisions can benefit from this.

A tri-cluster smartphone design using 2 high-end cores, 2 mid-level cores, and 4 low-power cores could be replaced by one that uses all three types of core in the same single cluster. The advantage of that approach remains to be seen.

More about ARM big.LITTLE.


Original Submission

Display Options Threshold/Breakthrough

Reply to Article

Mark All as Read

Mark All as Unread

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Touché) by FatPhil on Thursday December 07, @02:47PM (4 children)

    by FatPhil (863) <reversethis-{if.fdsa} {ta} {tnelyos-cp}> on Thursday December 07, @02:47PM (#606801) Homepage
    Having noticed the department line - which is such a massive understatement it's shocking - let us not forget that the first Cray was from 1976, clocked at 80MHz, and could do 160 MFLOPS. Cranking it up would drain over 100kW.

    This little sucker can do 100x the GFLOPS just on its CPUs, without using any of the graphics coprocessors. So it literally is as powerful as a beowolf cluster of Crays. All hail Moore's Law, long may it desperately put off screeching to a sudden halt!
    --
    I was worried about my command. I was the scientist of the Holy Ghost.
    • (Score: 2) by JoeMerchant on Thursday December 07, @05:08PM (3 children)

      by JoeMerchant (3937) on Thursday December 07, @05:08PM (#606868)

      I have a "modular" collection of ~8 programs running to accomplish a variety of loosely coordinated tasks.

      The "task" code in each program runs about 20K. Then they have a widgets based GUI that runs more like 200K - because it's more convenient for human operators than CLI (speaking of the broader human race, not "metacyborgs" that can get things done faster on CLI). Then, the "lightweight" coordination code runs another 300K or so, or, if they tap in to the broader communication matrix that's about 3500K. And, I just can't get past meh for caring whether we use the lightweight coordination code or the whole enchilada communication matrix. Full up, one of these things runs about 4MB executable size - OMFG, my first computer (35 years ago) only had 16K of RAM and used half of that for OS stuff, leaving 8K of available program space, and it's BLOATING the CODE to 8x its trimmed size!!!

      4M is 500x what fit in that 1982 computer, and it's also 1/500th of 2GB - anybody get excited about having 2GB of RAM available for program execution anymore? I think our current plans are for 8GB of system RAM, so 8 of these programs, full up would amount to 0.4% of the available RAM, or if we wring our hands about which ones get the full comm matrix and which ones get a limited set, we might trim that to 0.1% - I just can't get past meh.

      • (Score: 2) by takyon on Thursday December 07, @06:11PM

        by takyon (881) <{takyon} {at} {soylentnews.org}> on Thursday December 07, @06:11PM (#606909) Journal

        I can eat up the remainder of my 8 GB RAM by running calculations or something. Although much is already taken by web browsers with multiple windows and many open tabs. So I will probably shoot for a minimum of 16 GB for the next system.

        --
        [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 4, Insightful) by frojack on Thursday December 07, @06:52PM (1 child)

        by frojack (1554) Subscriber Badge on Thursday December 07, @06:52PM (#606937) Journal

        Your ancestors lived in random caves, smokey, damp, and pest ridden. It cost them three rocks and a scratch on the arm evicting the prior animal occupants when moving in. Running water is a quarter mile to the stream (in the wet season), food is 100 yards away in mid summer and two day's walk to the migration path for meat. Other than the predators about, they had not a care in the world.

        Your current apartment building ....

        See where I'm going here? Your lament is stupid. And old.

        We've spent a centuries getting to this point by baby steps. The distance covered in this particular baby step exceeds the distance from an IBM 1401 to a Cray by orders of magnitude. Yet you bemoan bloated code. Code is condensed, preserved, harnessed human intelligence. Some of it contains errors. (I said "human", remember). But it does in a blink what you couldn't in your entire remaining lifetime.

        Time to put the elitist rant aside. Know-it-alls have been singing this tune for 50 years and its not helping. Every enhancement in processing power has gone mostly to "look and feel". So what? That's what we want and need.

        Yeah, the "overall expected performance improvement to 25-39%" will barely be noticeable. Humans tend to need these things to double in order to be noticeable. If that bothers you, sit this generation out and wait for the next two or three to arrive.

        --
        No, you are mistaken. I've always had this sig.
        • (Score: 2) by JoeMerchant on Thursday December 07, @09:04PM

          by JoeMerchant (3937) on Thursday December 07, @09:04PM (#606987)

          Nice rant, but your sarcasm detector is broken again - I'm not lamenting bloated code, I'm saying that it's hard to even begin to care about it anymore.

          Moore's law has taken something that might have been 500x too big to work in a "top of the line" desktop machine 35-40 years ago, and made it 1/500th of the available capacity on a "bottom of the line" portable today.

          And, for many in the world, their current apartment is just as hazardous to their health and well being as a good cave was 4000 years ago. But, we do have tens of millions as many apartments, huts, and houses as we did caves back then, probably another Moore's law in that - but not nearly as counterintuitive as the processing speed and storage space one.

  • (Score: -1, Offtopic) by Anonymous Coward on Thursday December 07, @06:18PM

    by Anonymous Coward on Thursday December 07, @06:18PM (#606915)

    qualcom and arm? sounds like slaveware to me. i can't spare a click to RTFA.

(1)