Hacker News Reader

Anand stated in a previous article that Chinese customers were basically demanding 64-bit 4 or 8-core SoCs, just to tick checkboxes on a spec sheet.

Of course it's pretty well established that 2 fast/wide cores (like Apple and Qualcomm's in-house designs) are better for current mobile software than 4 or 8 slower ones. And Android doesn't take any advantage of ARMv8 right now.

Another sad example of marketing trumping engineering reality.

I think games that use take advantage of high parallelism would do better on the 8 core devices. We just don't see much of that kind of game in the mobile market.

We don't see that on the _desktop_ market.

We also don't see many 8 core chips on the desktop market. Chicken and egg problem.

Very few people have the incentive or funds to get either the hyperthreaded i7s (which don't really have 4 cores), the 8 core Xeons or the 8 core AMD high end parts.

Very few games can even use two threads to full capacity.

Aren't games of all stripes typically GPU bound rather than CPU bound these days, if they're complicated enough to be limited by the hardware at all? If so, dedicating more area to GPU cores would be better for them.

Depends on the game really; but generally yeah, the GPU will be the bottleneck. Games with a large number of calculations will be CPU bound though; StarCraft 2 is a good example of that.

Because both CPU and GPU are generally on the same bus in mobile devices, maybe you could use those extra CPU cores as fragment/pixel shaders, if memory and cache architecture doesn't prevent it.

On PCs that is not feasible, because of bandwidth and latency issues over PCIe. On mobile SoCs, who knows, maybe it'd work.

Just like in current PS3 titles, that offload shading from GPU to SPUs.

PS3 games don't offload fragment shading to the SPUs, that would be too slow and leave the pixel shading hardware on the GPU idle. Remember that the PS3 has separate vertex and pixel shaders. What they usually offload is post-processing, mostly for anti-aliasing.

I was talking about a technique where deferred rendering, GPU is used in modern PS3 games to render surface normals, material index, Z-buffer, texture color, etc. in a buffer. Typically 128 bits per pixel.

This buffer is then DMA transferred to SPUs, where final lighting and fragment shading is performed.

Final step is to transfer 32-bit RGB data back to GPU's frame buffer for displaying.

Here's a link about one implementation: http://www.slideshare.net/DICEStudio/spubased-deferred-shadi...

Do you have any sources for that? Not the Chinese part, but the processor benchmarks.

I'd be very interested in reading them!

There's real value in having ARMv8 chips as soon as possible. First off, the architecture is significantly improved over ARMv7. It's not just the 64-bit support. Second, the transition to 64-bit is going to take 3-4 years after it begins anyway, which just means developers are going to have to support both 32-bit and 64-bit (and ARMv7 and ARMv8) for 3-4 more years, instead of just dumping ARMv7 as soon as possible, and supporting only ARMv8. The sooner everyone is moving to ARMv8, the better.

The 8-core thing is indeed mainly a gimmick, and I don't know if Anand has real data on "Asians wanting 64-bit", or he just lumped it together with the "Asians want 8-cores" (where there is some data to support that). But I think almost everyone wants 64-bit as soon as possible, because 32-bit chips are on their last legs, and especially if you only upgrade every 2-3 years, it wouldn't be wise to buy a 32-bit one right now, or you'll see some (not all) apps start dropping support for ARMv7 mid-life of your phone.

No one was caught off guard by Apple (ARM was previewing 64-bit ARMv8 designs over a year before the A7), nor has Apple's move to 64-bit even really mattered at all: Realistically Apple could have iterated their existing core and they'd be exactly where they are now. There is absolutely no reason for Qualcomm to need to respond to Apple, as it isn't like Apple is going to get some design wins with Qualcomm customers.

Qualcomm has the ability to modify ARM designs. That doesn't mean they should do so, especially given some of the metrics that show the A57 to be a stellar design. We'll see how it performs in practice, and sure Qualcomm will then start iterating, but ARM's own literature show it as being a much more significant performance boost than was seen from the A6 to the A7.

EDIT: To indirectly respond to mrpippy (given that HN can penalize if you reply more than once) - two fast cores are better than four slow cores. But four fast cores are even better than two fast cores. The A57 is, on paper at least, an absolutely formidable design, which is exactly why Qualcomm didn't foolishly pursue a NIH agenda. It will, if ARM promises come to pass, yield significantly better performance than the Apple A7, which is a part of the reason most other vendors waited on 64-bit. I'm fairly certainly Google will have the 64-bits ready when the market needs them.

The technical aspects don't matter. (Although ObjC is getting significant benefit from 64-bit pointer tricks.) Now that 64-bit exists, many customers demand 64-bit. https://www.youtube.com/watch?v=UAOtC9QfXac

> No one was caught off guard by Apple

Bull. I've seen numerous comments in articles that they were caught flat footed. The end of the Anandtech article notes that Samsungs has been shipping 64 bit chips for a few months now but their roadmap from right before Apple shipped didn't even mention 64 bit this year.

Samsung shouldn't need to chase specs, but that's what their customers want so that's what they do. They bump chip speeds, miscounted cores (sadly Apple did this too), add extra cores, etc. They need checkbox features so they make them. If they had 64 bit earlier they would have shipped it for the PR/spec value.

> Qualcomm has the ability to modify ARM designs. That doesn't mean they should do so [...]

If they don't modify the cores, then they're just a fab house. That makes them easier to replace. They need differentiation.

> I'm fairly certainly Google will have the 64-bits ready when the market needs them.

The benefit of what Apple did is that when the market needs 64 bit it will have been deployed for years. Transition issues are already sorted out.

Furthermore, Apple isn't going to start shipping new 32 bit devices. What they've got left is probably the last of them. That means developers can count on going 64 bit only sooner.

Given Android OEMs' histories of shipping ancient versions it wouldn't surprise me if brand new 32 bit Android phones were selling in the millions two years from now.

Bull. I've seen numerous comments in articles that they were caught flat footed.

Oh, I'm sure you've seen lurid tales of mysterious, unnamed sources who will regale about how flat-footed Qualcomm -- one of the largest ARM processor makers in the world, closely intertwined with ARM's 64-bit efforts -- was with Apple's introduction. Might you also be in the market for a bridge?

If Qualcomm is "responding" to anyone it is other chip vendors (such as MediaTek), because those are who Qualcomm competes with. Qualcomm does not compete with Apple. Again, Apple could have come out with a new, improved A6 and they would have gotten as many iPhone 5s sales, and they would have taken exactly the same number of deign wins from Qualcomm (0).

If they don't modify the cores, then they're just a fab house.

So they should change things just because? The A57 is a fantastic design, and is poised to offer incredible power to power consumption (and, if preliminary analysis is correct, Apple will have gone down the wrong path jumping the gun on ARMv8, having effectively put themselves a lap behind). Qualcomm will likely offer their own take on things later, but right now they might just go with what gets them a great design with little risk.

Given Android OEMs' histories of shipping ancient versions it wouldn't surprise me if brand new 32 bit Android phones were selling in the millions two years from now.

I would not be surprised at all. And it doesn't matter at all. Why should it matter? That is a complete non-problem.

If Qualcomm is "responding" to anyone it is other chip vendors (such as MediaTek)

MTK is one of the vendors that seems to have little (or even negative) reputation in the West, but their turnkey reference designs are extremely popular in southeast Asia. They're not (currently) competing on performance, but value, although that may start changing soon. I also have a feeling that their "officially proprietary/confidential but unofficially semi-open" stance - see http://www.bunniestudios.com/blog/?p=3040 - may be helping their popularity. It's true that they're not so GPL-friendly with Android sources and such, but when I found over 1GB of very detailed register-level documentation... the decision was pretty easy.

I would not be surprised at all. And it doesn't matter at all. Why should it matter? That is a complete non-problem.

Agreed, as long as they're 4GB of RAM or less (which is probably still plenty for many applications).

You don't need ARMv8 to address 4GB. That is a red herring.

ARMv8 redid the instruction set and registers with significant performance benefits.

Previous 32-bit ARM designs, such as Cortex A7 and Cortex A15 could address up to 1TB of RAM just fine.

I think it's time to put a stop on this misinformation that 64-bit is needed for more than 4GB of RAM. It is not true.

That's with PAE, you're still limited to 4GB of virtual address space, or rather 3GB with the default Linux configuration.

3GB per process. Or in Android context, 3GB RAM per app. Currently very few apps consume over 100MB RAM.

Are you calling Anandtech a mysterious, unnamed source?

"What's interesting to me is just how quickly Qualcomm has shifted from not having any 64-bit silicon on its roadmap to a nearly complete product stack. Qualcomm appeared to stumble a bit after Apple's unexpected 64-bit Cyclone announcement last fall. Leaked roadmaps pointed to a 32-bit only future in 2014 prior to the introduction of Apple's A7"

- The Fine Article

Are you calling Anandtech a mysterious, unnamed source?

No, I was referring to the general claim by articles that "sources" from "inside Qualcomm" gave them such information.

However Anand's comment was...dubious. Qualcomm doesn't generally publish a roadmap, and there was a single leak of uncertain origin that actually showed Qualcomm's own 64-bit IP (their own designed cores) in Q4 of 2014. So not only was Anand wrong about what the supposed roadmap contained, the roadmap itself has absolutely no credibility to begin with (even if it were made within Qualcomm, it could easily have been made by a division such as marketing that is going on the most certain of facts, while engineering may very well have had such a plan to adopt ARM's design for iteration 1, and then customize for iteration 2).

Making any broad claims about Qualcomm from that is ill-informed rumor mongering, which Anand is not always above.

The benefit of what Apple did is that when the market needs 64 bit it will have been deployed for years. Transition issues are already sorted out.

But iOS apps are also more likely to have issues on a 64-bit CPU, since they are written in (Objective-)C. Since nearly all Android apps are written in Java, the transition will likely be far less eventful.

Be sure to normalize the TDP when looking at Nvidia SoCs; it's not fair to compare a 10W chip against a 2W chip.