Slashdot Mirror
Qualcomm Announces Next-Gen Snapdragon 808 and 810 SoCs
MojoKid (1002251) writes "Qualcomm has announced two fundamentally new chips today with updated CPU cores as well as Qualcomm's new Adreno 400-class GPU. The Snapdragon 808 and the Snapdragon 810 have been unveiled with a host of new architectural enhancements. The Snapdragon 810 will be the highest-end solution, with a quad-core ARM Cortex-A57 paired alongside four low-power Cortex-A53 cores.
The Snapdragon 808 will also use a big.Little design, but the core layouts will be asymmetric — two Cortex-A57's paired with four Cortex-A53's. The Cortex-A57 is, by all accounts, an extremely capable processor — which means a pair of them in a dual-core configuration should be more than capable of driving a high-end smartphone. Both SoC's will use a 20nm radio and a 28nm RF transceiver. That's a major step forward for Qualcomm (most RF today is built on 40nm). RF circuits typically lag behind digital logic by at least one process node. Given that RF currently accounts for some 15% of the total area and 30-40% of the PCB, the benefits of moving to a smaller manufacturing process for the RF circuit are significant." To clarify, the 810 can use a combination of the Cortex-A57 and Cortex-A53 cores so a single task that needs a lot of power won't cause as large of a power jump. All of the chips are 64-bit ARM too.
The Snapdragon 808 will also use a big.Little design, but the core layouts will be asymmetric — two Cortex-A57's paired with four Cortex-A53's. The Cortex-A57 is, by all accounts, an extremely capable processor — which means a pair of them in a dual-core configuration should be more than capable of driving a high-end smartphone. Both SoC's will use a 20nm radio and a 28nm RF transceiver. That's a major step forward for Qualcomm (most RF today is built on 40nm). RF circuits typically lag behind digital logic by at least one process node. Given that RF currently accounts for some 15% of the total area and 30-40% of the PCB, the benefits of moving to a smaller manufacturing process for the RF circuit are significant." To clarify, the 810 can use a combination of the Cortex-A57 and Cortex-A53 cores so a single task that needs a lot of power won't cause as large of a power jump. All of the chips are 64-bit ARM too.
but the modem revelations seem good. Qualcomm seems to be the top soc manufacturer (outside maybe apples a7). 20nm/28nm analog might be what is required to push that envelope :)
So does this finally mean we'll get Simultaneous voice and LTE/SVDO back? Because all the current generation Qualcomm processors lack dual radio paths for some reason, this despite the fact that the previous generation had it. I have to assume it's because they used so much power/transistor budget on 'more cores!!!!' that they didn't have room for an RF design to accommodate features that are actually useful.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
"I know there's a lot of noise because Apple did [64-bit] on their A7. I think they are doing a marketing gimmick. There's zero benefit a consumer gets from that," -Anand Chandrasekher, former Qualcomm CMO
I can't see how wasting cycles on implanting an x86/x64 instruction set would be of much use commercially. I don't get the impression that many ARM manufacturers have any interest in trying to beat Intel on its own platform.
The world's burning. Moped Jesus spotted on I50. Details at 11.
It's true. I'm a developer, and I was just thinking that to myself. I don't plan on supporting this architecture anytime soon (thankfully it's backward compatible). Hell, I'm still compiling my code as 16-bit thumb code. At some point, I'm going to want 64-bit, sure. But I really doubt that I'm going to need a 64-bit CPU at any point in the near future on a mobile device.
Qualcomm is somewhat forced to go with 64-bit though, because Apple has taken the genie out of the bottle. Now that one person is doing it, everyone is going to have to do it. It's going to be difficult selling a 32-bit processor when the guy across the street is selling a 64-bit one.
The A57 has a first generation branch predictor and extremely low IPC. Fully custom is really the only game in town unless you are content to relive the Intel Netburst fiasco yet again with A57.
Why are you designing your drone for x86? Are you writing it in assembly code?
Now that one person is doing it, everyone is going to have to do it. It's going to be difficult selling a 32-bit processor when the guy across the street is selling a 64-bit one.
There's a lot more reason to go 64 bit than that. The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM. Yeah, there are all sorts of workarounds you can use to access larger amounts of RAM with 32-bit pointers, but it's much nicer to have a flat address space, including plenty of address space for memory-mapped devices. Granted that we're probably a couple of years away from needing 64 bits, but it's coming, fast.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Why are you designing your drone for x86? Are you writing it in assembly code?
He's running Windows on it, duh.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Aww, you little ARM guys are so cute arguing over which toy-architecture CPU is the latest greatest! Watch what happens over the next 2 years...
Did Qualcom also announce their commitment to binary only drivers and refusal to work with the free and open source software communtiy ?
Qualcom are just another greedy corp trying to take everyones stuff.
The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM.
That was my thought. Chips that are being announced now are still going to be on the market when 3 or 4 gigs of RAM is normal, so not having 64-bit support is starting to be a problem.
Now that one person is doing it, everyone is going to have to do it. It's going to be difficult selling a 32-bit processor when the guy across the street is selling a 64-bit one.
There's a lot more reason to go 64 bit than that. The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM. Yeah, there are all sorts of workarounds you can use to access larger amounts of RAM with 32-bit pointers, but it's much nicer to have a flat address space, including plenty of address space for memory-mapped devices. Granted that we're probably a couple of years away from needing 64 bits, but it's coming, fast.
32-bit ARM already addresses more than 32 bits: recent 32 bit ARM architectures have a 48 bit address space, and several chips support 36 or 40 bits. The problem of individual applications addressing at most 32 bits is minor, at this stage, but sooner or later we will have big graphics editing applications on Tablets, and larger address spaces help.
The main advantage that Aarch64 has at this very moment is that it offers a more streamlined instruction set (that makes instructions easier to reorder) and more registers. Even just compiling 32 bit code in the new model you can get impressive performance gains.
Roberto
32-bit ARM already addresses more than 32 bits: recent 32 bit ARM architectures have a 48 bit address space, and several chips support 36 or 40 bits. The problem of individual applications addressing at most 32 bits is minor, at this stage, but sooner or later we will have big graphics editing applications on Tablets, and larger address spaces help.
It can, but it's not really fun that way. Realistically, using high memory (that is not within the directly mapped part accessible to the kernel) eventually causes headaches. The default configuration on arm32 (and x86-32, for that matter) is to have only 768MB of lowmem, if you go beyond that you get into trouble because a lot of the kernel's data structures (page tables, inodes, socket buffers, ...) have to be in lowmem. You can push that limit to 2 or 3 GB at the expense of limiting user address space, but the higher you go, the sillier it gets. If you have 4GB or more on any architecture, you definitely want a 64 bit CPU.
I think this may not be enough for a smartphone. After all, it's not for making phone calls. Right? It's for viewing ads. The more the better for all of us.
they need to build in an x86 emulation layer to make these more attractive to gp programmers ... if they had that I may be able to make them work with the drone I'm designing for i/o and avionics control but I do not feel like rewriting the whole damn code base to run on these frankenchips.
You're programming your drone in assembler language?
I really don't 100% get this big.little architecture.
The idea of having a weak but low power core capable of running all the basic functions and driving the GPU is reasonably obvious. I get that. I get the idea of having it backed by 4 big fast cores which can be switched on when a task overloads the little CPU.
But why have 4 little CPUs?
SJW n. One who posts facts.
Watch what happens over the next 2 years...
Do you have a prediction that you wish to share with us?
Also, just compiling 32 bit code can make it slower due to not fitting in whatever cache, requiring more memory and bandwidth. There are two sides to the coin.
"it's not going to be long before smartphones and tablets have > 3 GiB RAM"
You mean like the MS Surface Pro (4 GiB and 8 GiB models?), the Acer Iconias, Fujitsu Stylistic tablets etc.?
even Windows programs (ie created with visual studio) can recompile to ARM instructions. I guess he just can't install Windows itself on it.
Moral: don't lock yourself in to anything!
which of course have 64-bit x86 CPUs and run a 64-bit Windows.
Dat abacus
I think you meant "compiling 64-bit code." 32-bit code is usually smaller due to smaller pointers.
There's a reasonable argument for moving to 64-bit on security grounds too. The increase in virtual address space makes ASLR far more effective since there are many more options for positioning compared to 32-bit code. On top of that, any attacks are more likely to hit a unallocated page as opposed to anything useful (with some limitations of course).
"which of course have 64-bit x86 CPUs and run a 64-bit Windows."
So, problem solved. Excellent.
Which is a pretty poor argument, IMHO. Beyond other things, (1) ASLR has been repeatedly defeated on 64-bit Windows systems (and presumably could be on Linux systems) because rarely is 100% of the address space random and attacks often can manage to scrape out enough details for relative addressing to make ASLR moot and (2) ASLR is meant to be at best a stopgap for not all (server) applications to be immediately attacked when a vulnerability is discovered by making more attack attempts a DoS rather than a full compromise, except that depending on the circumstance a DoS is more than bad enough to make the difference mostly a moot point (especially if other security practices are in place and said (server) application has no private information to compromise).
I mean, yes, it might be the icing on the cake to have a greater address space for such things. But, it's hard to call it any sort of a driving force.
"I know there's a lot of noise because Apple did [64-bit] on their A7. I think they are doing a marketing gimmick. There's zero benefit a consumer gets from that," -Anand Chandrasekher, former Qualcomm CMO
According to Anandtech ( http://www.anandtech.com/show/... )
"Integer performance: The AES and SHA1 gains are a direct result of the new cryptographic instructions that are a part of ARMv8. The AES test in particular shows nearly an order of magnitude performance improvement. This is similar to what we saw in the PC space with the introduction of Intel's AES-NI support in Westmere. The Dijkstra workload is the only real regression. That test in particular appears to be very pointer heavy, and the increase in pointer size from 32 to 64-bit increases cache pressure and causes the reduction in performance. The rest of the gains are much smaller, but still fairly significant if you take into account the fact that we're just looking at what you get from a recompile. Add these gains to the ones you're about to see over Apple's A6 SoC and A7 is looking really good from a performance standpoint.
If the integer results looked good, the FP results are even better: The DGEMM operations aren't vectorized under ARMv7, but they are under ARMv8 thanks to DP SIMD support so you get huge speedups there from the recompile. The SFFT workload benefits handsomely from the increased register space, significantly reducing the number of loads and stores (there's something like a 30% reduction in instructions for the A64 codepath compared to the A32 codepath here).
The conclusion? There are definitely reasons outside of needing more memory to go 64-bit."
and a handfull of other things. But all of the above aren't really benefits of 64 bitness, just the improvements to the architecture. The real benefit of a 64 bit architecture is the larger virtual address space... processes with >2-3 GB of memory. Every other improvement is usually just improvements that could have been added in 32-bit mode but they threw into 64 bit arch. Similar with x86-64.
-- Erich
Slashdot reader since 1997
32-bit ARM already addresses more than 32 bits:[...]
It can, but it's not really fun that way. /p>
It can be outright painful, I agree. A 64-bit address space is better. I think that the point of the poster you are replying to is there are other advantages of Aarch64, and everybody seems to focus on the 64-bit address space, either to praise it or to label is at irrelevant. The situation, as it happens, is a bit more complex than that.
"Qualcomm is somewhat forced to go with 64-bit though, because Apple has taken the genie out of the bottle."
The Qualcomm part was already near completion by the time anyone knew anything about the A7.Going 64-bit as a "response" in ~6 months is not plausible.
My point was to poke fun at Qualcomm naysaying 64-bit at the same time they were developing 64-bit.
Don't tell it to me, tell it to Anand Chandrasekher.