Cortex A72-Powered Snapdragon 618, 620 Renamed To Snapdragon 650, 652

Status
Not open for further replies.

bit_user

Polypheme
Ambassador
According to another news site (gsmarena), the 650 core config will be: 4x A53 + 2x A72. The 652 core config will be: 4x A53 + 4x A72. A72's to be clocked at 1.8 GHz and A53's clocked at 1.2. Seems kinda low, for the A72's, but then I guess Qualcomm needs to leave a gap between that and their Kryo-based SoCs. Also, might let OEMs use smaller batteries.

I wonder if anyone will pair A35's with A72's, of if they're in too far different performance leagues.

Also, I don't understand the 4+2 pairings, which Qualcomm has also done in previous Snapdragons. Is there much benefit over 2+2, or is it just done that way for manufacturing or marketing reasons?
 

Marius Cirsta

Reputable
May 6, 2014
17
0
4,510
Also, I don't understand the 4+2 pairings, which Qualcomm has also done in previous Snapdragons. Is there much benefit over 2+2, or is it just done that way for manufacturing or marketing reasons?
Well you have to remember that the 4 are A53s or maybe A35s in the future. These are very small, low power cores. They don't take much space on the chip ( not much increase in cost ) and also don't use a lot of power so 2 more of these isn't really an issue.
It gives you a nicer figure for marketing ( 6 cores vs 2 ) and is theory well optimized apps could be made to limit themselves to these 4 low power cores. Given the number of processes running in the background that shouldn't need lots of compute power this makes sense, 4 of these will limit the usage of those high power A72 that you probably want to keep idle and not using power.
This of course all depends on the quality of your apps and scheduler but anyway 2 A53s cores are really cheap these days.
 

bit_user

Polypheme
Ambassador
Thanks, but I didn't mean 6 vs. 2, I meant 6 (2+4) vs. 4 (2+2). It seems to me that, for a few apps & OS functions running in the background, 2x A53's should be plenty. I wonder how often more than two A53's are used while both A57's remain idle. Anyway, I just now read, in the 820 Preview article, that the 820 is exactly this - 2 fast cores and 2 slow ones. But, in that case, the slow Kryo's probably cost the same amount of die (except for L2 cache).

My guess is that the 4+2 chips are binned parts where at least one of the faster cores has a defect. Because they're so small, it's probably much less common that the A53's have a defect. Then, the reason they don't disable 2x A53's is because it wouldn't cost them anything and they could sell it as a 6-core instead of 4-core.

Something else I've been wondering is whether the latest Android kernels can simultaneously utilize all cores. I remember when the first BIG.Little SoCs hit the market, the two clusters were mutually exclusive. I think it wouldn't be too hard to schedule - just throw something on a low power core if the high power ones are occupied. Beyond that, CPU-bound jobs (i.e. those which use the most % of their timeslices) should have priority for running on the fast cores. That way, most of the I/O would end up on the slow cores, leaving the fast ones available for number crunching.
 

Marius Cirsta

Reputable
May 6, 2014
17
0
4,510
I just wanted to say that I'm not sure if the 6 cores are 8 cores with 2 disabled, they could be but it depends on how many are needed. If there's a lot of demand for 6 cores then it makes sense to produce them separately.
Anyways 4 A53s still make sens because you can have the cores remain in their low frequency range if everything goes OK.
Today's SOCs cand indeed use all their 8 or 6 or whatever cores at the same time but they I doubt they can run like that for a long time because of thermal issue. They can still run on all 8 cores enough to get a good Antutu score though :)
 

bit_user

Polypheme
Ambassador
Thanks for the info. I guess one advantage of Apple's approach is simplified thread scheduling. If you have only two identical cores, then there's no risk of putting a big job on a little core.
 
Status
Not open for further replies.