Also in true 64bit mode, cuz a lot of the perf improvements in v8 are not available in legacy 32bit mode.
It is a shame really, samsung decided the uArch improvements would be enough to barely pass this chip as "incremental", they didn't bother to feed a higher throughput chip with a wider memory bus. As much as it pains me, apple did better in that aspect by not crippling their A7 chip, even if only because they needed it for a "wow factor" after so many generations of mediocre hardware, especially given the many exclusive initial shipment deals they secured to stay relevant.
But if they don't sell it to anyone else, it doesn't really matter does it?
Apple doesn't compete with Samsung or Qualcomm when it comes to selling SoCs because they don't sell SoCs to other companies. A slight lead in CPU performance is not going to get people to buy an iPhone over and Android, if that's what they're set on buying.
It does matter insofar as to be a benchmark of what is possible (as long as they are ahead). And let’s not pretend Apple’s CPUs sucking wouldn’t invite the same kind of comments—just like every situation where 2 competing technologies are compared.
Platform/fanboy trolling aside, that’s something Android users benefit from as well. Apple being "stubborn" about 2 core CPUs, for example, is a nice counterweight to the 8 cores and 8 mini-cores and 8 quasi-cores trend that some CPU vendors seem to have a hard-on for, and it gives a nice real-world example of how such an approach to mobile CPU design works out, no?
If Apple stays ahead in the mobile CPU game, the people using non-Apple phones will always have a target to point to and demand equality with. Otherwise they’d just have to live with whatever Qualcomm et al feed them.
The Tegra K1 64 bit is faster, core per core, versus the A8 (you do realize that the K1-64 has only 2 cores, right? I'm going to have to guess no, or you just are completely unable to read a chart). The A8x offers marginal per core performance advantages over the A8, and the primary benefit is the third core. The K1 64 is a A57 derivative, *exactly like the A8*.
Your comments can only be construed as trolling. Can't match the A7? Give me a break.
Ergo, you're completely off. The Denver K1 is a VLIW code morphing architecture - it has nothing to do with the Cortex A57, nor does the Apple Cyclone, they're both custom architectures.
The K1 offers better performance in benchmarks, but as a result of code morphing, it can be hit or miss in real world, causing jank.
I don't know how one can read AT and think this. Read the Nvidia Denver (k1 64) architecture detail. Read the Apple A7 analysis, and by extension that's also the A8. They're not "a57 derivative", they're completely custom.
Oh save the noise. Both nvidia and Apple are design partners of ARM, and have a long history of deriving from ARM designs. The Apple design (which you seem certain of, despite having zero possible authority to be so) is almost certainly derived from earlier revision A57 designs. Yes, just like Snapdragon they modify and heavily, but a big benefit of being ARM partners is that they don't have to do all of the work themselves.
I don't know how you can read Anandtech and not have any rational knowledge of how the semi world works.
They are ISA compatible... but that doesn't mean they're direct derivatives. The custom cores are often quite different in terms of underlying architecture from the reference ARM designs. If it was a simple tweaked ARM design, Qualcomm wouldn't be deploying a reference core in their upcoming flagship - their next-gen custom core isn't ready yet because it takes time.
Hide your wrongness in anger, why don't you. They are ISA compatible, nothing more. Apple doesn't even hold an A57 licence, they only licence the ISA now. And Nvidias architecture is very clearly completely different, if you knew what code morphing and VLIW were you would not be arguing this. Save your own noise.
Note that the A9 will soon be coming out this year. This means Apple will be 2 generations ahead of the pack when it comes to 64-bit processors. And unlike the Tegra, it is also going into the iPhone, not just a tablet.
I'm very sure that the Exynos is not the only 14nm processors in the world. And you know that making it a smaller process doesn't make it better right? Just take a look at Chip-gate on the new iPhones. TSMC's 16nm is better than Samsung's 14nm. And apply to their own Exynos processors. Maybe they would do better if they were 16nm too huh?
Why do you say that? This seems highly comparable in benchmarks, and it's not even running a 64bit OS yet. I'd guess that after they update it to Lollipop it's equal to the A8 overall, which is really impressive given they're generic cores from ARM.
But it does take them twice as many cores, higher clock speed, and triple the ram to match the A8. I am not sure Apple is years ahead, but they certainly have an edge, which is most likely a result of designing the software that runs on the hardware. They are able to make efficiency improvement android handset makers just aren't able to do.
That's called optimising and that was actually something derided by the author in the article (browser optimisations for the platform are apparently a bad thing now - talk about throwing out the baby with the bathwater)
I think you misunderstood my point of view, I'm all for optimizations and hope vendors continue it, and even encourage it. I was just pointing out that it negatively affects our benchmarking methodology as Chrome continues to fall behind.
Chrome isn't falling behind in real-world load times.
Only in tampered with benchmark results like Samsung's "optimized" Stock Browser. Benchmarks show performance gains for Samsung's browser vs Chrome on the order of twice the performance? It makes me chuckle to see Samsung also only cheats the results enough to equal the iPhone 6.
Give me a break. Anyone with half-a-brain knows whats up here.
Bigstrudel, how big is your brain? A quarter? Browser optimization is cheating? So hilarious. Did you spend a little bit of time to read the Browser benchmark part? Or just your brain cannot process?
Samsung's custom browser is a tweaked version of chrome. It's just optimizing for the platform. Not only commendable but something that should be the norm.
Agreed, it was a little shocking to see that even the Cortex A57 is stomped on by the A8/Cyclone R2. And that with two cores and sane clock speeds.
I would say this is what everyone else would be doing, ideally, but the cost here is die size. Instead they shoot for smaller higher clocked designs to save some die size and cost, since other companies aren't willing to pay as much for the SoC in the BoM as Apple is.
to be fair, the basic minimum performance Cyclone R2 have had to achieve was beat A57, since that was the reference design available from ARM for everyone. So I don't think it's that surprising.
On the other hand, them and Nvidia alone have parts better than the A57 per-core out, and even from those two the 64 bit Denver K1 is too high in power draw and chokes on some tasks due to its code morphing engine bottlenecking the process.
So it is still remarkable, to me, how early and how long Apples lead has lasted.
Why do we need octa cores in phones/tablets? Marketing says we do, plain and simple. It's bragging rights. No real benefit but it sounds cool. Apple is doing it wider and smarter.
But unfortunately people are getting dumb-er and stupid-er (XD). Falling into marketing ploys. I feel like Apple is the one who is not marketing crazy now. Its all numbers with the Android people :/ Apple cares about user experience more than any other companies and they spend a lot more money on it.
I have. It wins some benchmarks, but is less consistent in the real world because it's a code morphing design that can get choked up by unpredictable code. It's also more power hungry, though that's partly the fab.
bigstrudel, you are either Apple fanboy or a troll. For your own sake I hope it's the former and you understand that what you posted is pure nonsense. The only tests where iPhone dominates Samsung phones are specint and basemark tests. But the reason for that is not what you probably think it is. Specint benchmarks use only one core. Sure, A8 core is faster but then iPhone has just two of them. The total power of four cores is higher than that of two A8s. And it's not like the two A8 cores consume twice less power than four Samsung cores. A8 is a very BIG core. Each A8 core uses more power than a single Samsung core. And basemark scores... Those depend on screen resolution and iPhone has a very low resolution compared to Note 4. In short, both approaches (two large cores or big.LITTLE architecture) have pros and cons. There is no magic here. It is not clear to me why would you say that A8 "stands light years ahead" when the phone based on this SOC (iPhone 6) lags high end Android phones in synthetic benchmarks like Geekbench.
1. The CPU and resolution has almost nothing in which you can compare with 2. If you do a little research and stop drinking that Samsung marketing soup, you would realize that not all the Samsung cores are not the same. They vary in power...
Apple A series is already eclipsed by Exynos 5433 as seen by sub-test scores in Geekbench. (how does Geekbench calculate aggregate score? I have no idea) A8 will also be crushed and humiliated by soon-to-arrive Exynos 7420.
Dual-core is the best configuration? My ass. That is why they added another core in the new iPad. Oh, if you look at the die shot there is a space for a 4th core there, too.
They added another core in the new iPad for a totally different reason. Its like having a laptop and a desktop.
And there are several reasons why having dual cores in the iPhone is better and having dual cores in the iPad would be a worse idea.
1. The cores in the iPad would get so big and inefficient that it would be pointless to make them bigger. The battery would be wasted. However on the iPhone, the 2 cores are the best size as it is not too small to be slow and too big to be too power hungry.
2. The 3 cores on the iPad is there because they have more space. If they went full Samsun retard style with 4 or 8 cores, you would see 4 or 8 cores with high clock speeds but very low processing power. And therefore inefficient wast of resources and space. Not to mention that most apps only use 1 or 2 cores to run.
Only thing I'm worried is that writes of such pieces are "Hot Shit" in employment market and I fear our technical writers could yet again disappear to better paying tech-companies...
Wonderful article, loved the detailed analysis done. I wonder if there are any improvements in software stack in 7420 compared to 5433 specially since 7420 will be shipped worldwide.
I'm looking forward to analysing those changes. There should be a considerable amount of change given the new AArch64 kernel platform, but we won't know till it's out.
I'm really impressed by some of the fiddly things you've managed to measure here. What was your source for the die area measurements (Chipworks hasn't done a 5433 tear-down yet), and did you set up the detailed power-monitoring hardware yourself?
"The overall increase in cache helps to improve performance, though perhaps more importantly the larger instruction cache helps to offset the larger size of the 64-bit ARM instructions."
This is incorrect. AArch64 has a 32bit instruction length just like ARMv7. Unless of course you were comparing to 16bit Thumb instructions. Vague in either case.
Wish you would have included power numbers for A15 and A7 on 28nm since that's the more common process for A15/A7 and it's unlikely we'll see them much on 20nm and bellow (to be clear, not saying that you should have excluded the numbers on 20nm). Said this before, very curious about the encryption gains in actual use for both power and perf so maybe you guys look at that at some point. And maybe include https sites in the web browsing battery tests- tests that are kinda fuzzy on the methodology, maybe you've detailed it somewhere and i just don't remember. The process scaling is surprising, maybe TSMC did better,we'll have to see. Any clue how A53 power scales at much higher clocks, obviously not from this testing. Wondering how it would perform at very high clocks vs a lower clocked A57. At.1.3GHz the A53 seems to use some 3 times less power than A57 and given it's die size if it could go to 2.5Ghz on 20nm it would be interesting, at least from a cost perspective.
I only have a S4 with an 5410 at disposition, and that is running cluster migration and it's a very old chip by now. The only other candidates would have been the 5422 S5 variant which I don't posses, or to have to destroy the unibody shells of my Huawei devices to be able to do a proper power measurement.
I did overclock the A53, but above 1.5GHz it's not worth running the little cores as the voltage rise is too high and the A57's at low frequency are more efficient. This is highly dependent on the core implementation, I imagine MediaTek's SoCs with high clocked "little" cores are much better optimized in such scenarios.
Thanks for the reply. I kinda like the A53 perf at 1.5GHz and above ,nice little core and nice boost for the market it's addressing. In this SoC it does seem that above 900MHz the power goes up a lot.
Interesting to see the PCMark numbers, and how Lollipop seems to help. Given that Lollipop overall "feels" smoother, it makes sense there would be something that would allow that to be somewhat measurable.
Running an early build of CM12 on my Snapdragon Note 3, and I'm seeing numbers nearly on-par with the Nexus 5 shown here.
Yup! Teamasek 7.5.1 as of today for me (was on 7.4 when I wrote that post). Absolutely loving it now, and feel comfortable using it as my daily driver.
Excellent article, I really appreciate the in-depth analyses on the differences between the Exynos and SnapDragon SOCs. I'm shaking my head at Samsung's mad product line though. They seem to make a different variant for each region with so many SOC/modem/RF combinations.
Wouldn't it be better to have just one or two variants supporting most of the LTE frequencies out there? I would hate to be the person at Samsung in charge of software updates for these phones. You would need a huge developer team to keep track of per-device changes and fixing bugs while keeping the code consistent along the same model line.
I decided to go for the Snapdragon version for the Gear VR support, I think it was Carmack who posted recently saying the Exynos version was still lagging. Plus the Snapdragon version is officially supported in my territory which should make warranty calls less hassle, I've used the Exynos version but didn't really notice any difference in day to day use and was quite happy with the Snapdragon 800 in the Sony Z Ultra.
Also the Snapdragon Note 4's are much better supported for custom roms compared to the Exynos versions.
And when the S6 comes out, in three months or so Andrei will have wired it up, connected it to data loggers, and run the experiments to work out what it does. If you want content-free reviews of products as they come out, I would recommend somewhere other than Anandtech.
It should happen much faster than that, this article fell victim to the same problems as the Nexus 9. Luckily Ryan is healthy again and any future mobile content should be able to be handled by me and Josh.
i appreciate the reviews, and from the first part of tom's comment i thought he was going to say that yeah in 3 months after that there will be another exnyos (a72)?
i actually like the low # of reviews. i don't want this site to become gsmarena. explore the arch ( i hope once the flex 2 comes out, you do so for S810) and perform normalized benchmarks that show not oooo lookie high score!, but the real improvements in the design and dies. sure, do a review of each flagship, so people can decide, but not much more as it becomes too taxing on the writer.
From this (http://browser.primatelabs.com/geekbench3/compare/... we can see that the 7420 is significantly faster under Lollipop that the 5433, the Lua multicore score seems to be fixed, and the significantly higher memory scores suggests LPDDR4 or 128-bit memory.
You can't - A53 has too many gate delays per pipe stage.
If you want to go 3 GHz then you have to spread the total work required to execute an instruction over more stages (less work per stage ~= fewer gate delays per stage). That's one reason why the A57 has a 16-stage pipe (minimum for a simple integer op) whereas the A53 has an 8-stage pipe.
Excellent article as always. It looks like you guys are going to review the Galaxy alpha, looking forward to that review. Have you guys manage to get A Sony Xperia Z3 Compact? It will be very interesting to see how it compare against Alpha.
I'm not sure we'll be actually reviewing the Alpha due to the device being discontinued. I still have the MX4 Pro in the pipeline and after that things will get busy due to MWC.
Great article but I can't help but feel like this is 4 months old. Wouldn't it have been more relevant and better from a clicks point of view to apply most of this research and work to the 7240 and just release this in March?
I'm just not seeing this huge trouncing of the 805. Where is it? It is ahead slightly, but its battary life suffers by what appears to be a roughly equal amount. So it is basically the same as an overclocked 805. But the 805 is an older more straightforward, proven design and it is probably quite a bit cheaper at this point.
Power draw increases *more* than proportionally with clock speed, so an overclocked S805 matched to the performance of these would likely draw more power than them.
But yes, I do agree that the tradeoff is less than exciting. Denver also draws too much power, so we really don't have much in the Android SoC space.
All these phone reviews are overkill IMO the first one of any giving technology or OS is relevant the rest not so much, there are only a few things important with a phone(smart or other).
This one is slightly more relevant since it looks at 2 phones marketed as the same device (however since both versions are not available in the same region it is a mute point)
Can you make phone calls without it dropping the call Can you send and receive text messages Does opening email, or any applications happen in a timely fashion Does it work without crashing
If 1 phone renders a web page a few MS faster than another, it does not matter If 1 phone can run a game at a few more FPS it does not matter if the slower phone offers acceptable performance. If a photo is slightly better on phone a compared to phone B it doesn't matter since it is not good enough to print anyway (unless they start putting proper sensors at least 1/2.3, on phones you will never take acceptable photos). As long as it is good enough to view on the 4/5/6" screen to capture the moment it is good enough.
But this isn't a review of a phone. If you want a review of a phone, many specialised phone-reviewing sites which look at stupid details to do with phone calls and text messages are available.
This is a review of a processor and a GPU; quite plausibly the people at ODROID will make the processor and GPU available on a convenient mini-ITX-sized board with an HDMI connector before Christmas, at which point knowing the cache configuration of the computer is quite handy.
I was worried about AnandTech without Anand and Brian's insanely thorough testing and writing style. I'm feeling a lot better after reading this article. Great job Andrei/Ryan, great article.
in fact the opposite is true. With Anand and Brian, Apple products always were praised beyond the reason. Not the case here (although it's primarily a comparison between non-Apple products). Just pure technical stuff as is.
Excellent work, guys! But let me point out something:
1. Your Geekbench numbers show spectacular gains for the A53. They're actually so good that the multi-threading speed-up almost always exceeds the number of cores (judging by eye, have not run the numbers). For A7 the speedup factor is a bit less than 4, right where it should be. It certainly looks like the big cores were kicking in, at least partly.
2. You wonder that power scales sub-linearly with more cores being used. Actually this is just what one would expect in the case of non-ideal multi-thread scaling (as the A7 shows in Geekbench). The load of all ccores may be the same, percentage-wise, but when running many threads these are competing for L2 cache and memory bandwidth. There will be additional wait times under full load (otherwise the memory subsystem is vastly oversized), so each core is busy but working a little less hard.
3. The lower performance per W of the A53: this may well be true. But if the big cores did interfere, it could certainly explain the significantly increased power draw.
4. You hope for A53 at 1.5 - 1.7 GHz. I agree for CPUs which use only A53's. But as little cores this is not necessary. If you push a design to higher frequencies at the same technology node you always pay in terms of power efficiency (unless you start bad / unoptimized). Better let the little cores do what they're best at: be efficient.
Regarding your concerns on the big cores turning on: They did not. I made sure that they're always offline in the little testing. As to why GeekBench scaled like that, I can't answer.
Geekbanch scales like that sometimes, TR looked at this phone last week and they notice the Shield tab scaling better than 4x in some tests. For the A53 better scaling over A7 maybe it's the memory subsystem? No clue how heavy GB is on it but the A53 does have more memory BW and maybe faster NAND (you don't have storage tests for the Alpha ).
Sometimes one gets such results if the MT code path uses newer libraries to get multi threading, but also introduce other optimizations the tester is not aware of. Or they have to rewrite code/algorithm to make it multi-threaded and thereby create a more efficient version "by accident". I don't know if any of this applies to GB, though.
Excellent article, thanks a lot for that. I'd like to dig deeper about why Samsung is ruining the wonderful Wolfson DAC, I remember that even the legendary François Simond shared the issue with Samsung Developers without getting a response, maybe You will be able to have a response :) Also, I remember an audio quality test suite, why didn't You use it in this review? Thanks a lot.
We realized testing audio without having the proper equipment is a futile exercise and does not really portray audio quality of a device. Only Chris has the professional equipment to objectively test audio, such as done in the iPhone6 review: http://www.anandtech.com/show/8554/the-iphone-6-re...
I know you are trying to be nice to your colleague and give them a benefit of doubt, but to mercilessly critical eyes of mine your colleagues (Joshua Ho & Brandon Chester) have shown and time and time again they are not qualified to review Android products. I hope Mr. Frumusanu and Mr. Smith will take charge of this area in the future and limit those two to Apple product reviews.
I would love to read quality reviews and analysis like this instead of their tamper tantrum.
[Q]The increase in brightness for AMOLEDs at 80% APL rather than 100% APL is not very significant, and changing testing to accommodate AMOLED's idiosyncrasies doesn't seem like a good idea either. To put it in perspective, even if I had tested the Nexus 6 at 80% APL in the review my conclusion about the brightness being sub-par would have been exactly the same.[/Q]
That is what Brandon Chest had to say about brightness of the Nexus 6's screen. So arrogant, so biased. But according to the scientific data provided by this article (pg. 10), APL can indeed make a huge difference in AMOLED screen's brightness, given power target. For example, at display power target is 1W, 70% APL will raise the brightness by approximately 40%. At 50% APL, max brightness practically doubles.
I was appalled by the disparaging and arrogant attitude by Brandon Chester when it comes to correctly evaluating Android devices. He also made similarly nonsensical "arguments" in his tablet recommendation article for the holidays.
To me it is clear why arm has a new core coming. The a57 was not designed to do 64bit well. If the system uses only 64bit apps it might get bottlenecked.
BaseMark OS II Energy Efficiency test makes no sense to me. I get that perf/watt factor looks worse on the 5433, but why does the test consume more energy when run on big cores only, compared to when run on all 8 cores?
You have explained the performance degration part, but I am not sure whether you mentioned the reduced energy consumption part running 8 cores compared to 4 (big) cores. Running on 8 cores consume a little more than running on 4 LITTLE cores.
Read through it again. They do comment on that and claim that the switching between big and little cores is likely adding so much overhead they're better off just staying on the big cores.
If only there was an edit option... My original comment referred to reduced perf/watt in "8 core" mode rather than just the energy consumption.
As to why running on all 8 uses less than only the big 4? It doesn't use them simultaneously, it can only use the big or the little, and it switches between them dynamically. Since the big cores get to idle/sleep when it's running on the little cores, it uses less power overall. This is the whole point of the big.LITTLE design. It's just a shame it doesn't actually work from a performance point of view.
I explained the nature of the XML test and that it was 3 threads:
"The test is a good candidate because it offers a scaling load with three threads that put both a high load on some cores and let others exercise their power management states at the same time, definitely behavior you would see in day-to-day applications."
Is it me, or does anybody else wish ARM would change their naming scheme?
This single quote took 4-5 re-reads for me:
"As far as performance goes, ARM tells us that A53 can match A9 in performance at equivalent clock speeds. Given just how fast A9 is and just how small A53 is, to be able to match A9’s performance while undercutting it in die size and power consumption in this manner would be a feather in ARM’s cap, and an impressive follow-up to the A8-like performance of A7."
Is the "special" frequency only available to ALU-heavy loads on Exynos really a special case? I noticed a similar behavior on S800, too. Adreno 320 should do max 450 MHz, but 99% of the time I see it maxes at 320 MHz. I thought something must be wrong at first, but when I ran benchmarks or other compute-heavy demos, it finally showed me 450 MHz. (not talking about cheating, obviously) It seems like a wide-spread practice.
Not surprising outcome. All they need is produce this chip for the sheer number of cores which is popular in some but large markets. The chip is supposed to be good for better efficiency but we didn't see that.
I had like to thanks the writers for great in depth article, this is the kind of thing which has kept me coming to this site over the past many years. Keep up the good work.
What it looks like to me is that they need to cap 4 big core load to 1.6 GHz, which would keep the thermals under control. Going by the chart, 1 core @ 1.9 GHz, 2 cores @ 1.8 GHz, 3 cores @ 1.7 GHz would work nicely for power consumption/heat as well. It seems Samsung and Qualcomm are setting the max frequency too high. That last 100 to 200 MHz requires a lot more voltage.
You look at the power consumption at 1.9 GHz vs. 1.6 GHz - 7.39w vs. 4.44w. That's the crux of the problem right there. 4 cores should not be running at such a high clock speed (and voltage needed to support it).
"So the question is, is it still worth to try and get an Exynos variant over the Snapdragon one? I definitely think so. In everyday usage the Exynos variant is faster. The small battery disadvantage is more than outweighed by the increased performance of the new ARM cores."
That made me laugh as it is easily the most out of touch comment I've read in an AnandTech review.
It may be true for you as a reviewer sitting at home with the phone plugged into a USB charger running benchmarks that you feel the extra performance is worthwhile, but it will count for nothing when you use it in the real world and find your battery is dead earlier. Almost everyone with a smartphone today would rather have longer battery life instead of higher performance, because just like with PCs for some time now, the performance is already good enough.
Longer battery life trumps extra performance in smartphones now. I don't know why you want to put a positive spin on these higher performance but lower efficiency A57/A53 cores; I doubt ARM are paying you, but it seems they are a step backwards for people who use their phone primarily on the move, which includes most people.
From long experience with a variety of microarchitectures (including ARMs), I would guess that the latency/bandwidth "oddities" reflect differences in hardware prefetch. That's the most logical culprit among the list of changes that ARM provided.
The hypothesis that the capability to dual-issue loads/stores impacts bandwidth to L2 and/or DDR seems questionable, because 4xA7 already has enough ld/st bandwidth to saturate both. Memory-limited code shouldn't see much impact due to issue-rule relaxation.
Andrei and Ryan, thank you. I have not been impressed with anything Anandtech has published this much since the Original HTC One M7 review by Brian.
I believe you guys have just published the most thorough, detailed, comprehensive review of every aspect of an ARM SoC. Short of working at a chip maker's lab, I don't think anyone is going to have any better exposure to the ARM ecosystem than what you guys have presented here.
Huge thanks for finally paying attention to the SoCs that don't make it to the North American market. I've been fascinated by their performance and power consumption metrics, it's great to finally have an authoritative view of them. I would love to have your take on some other SoCs in this regard as well, especially Cortex A17. There is not much coverage of Cortex A17 and I think, given the situation with big.LITTLE, a quad core well optimised Cortex A17 might actually be a hidden weapon that no one seems to be using.
Also very much looking forward to your coverage of overclocking/undervolting mobile devices. You guys are truly bringing AnandTech to the mobile industry.
Once again, thank you. To be honest, I've been a bit worried since Anand and Brian's departure about the direction of AT, and it's so good to see it thrive in such capable hands now.
On the subject of Javascript benchmarks and Chrome vs Stock browsers:
Are we sure that all of the difference is indeed due to the optimized libraries that Samsung has developed, and that there is no benchmark-targeting optimization going on? After all, we saw what happend with Sunspider (and thanks for dropping it), it is impossible that they are not targeting Kraken and Octane as well?
Would it be feasible for Anandtech to develop its own proprietary javascript benchmark? It could answer a few of these questions.
This was an excellent read. Good detail, and enlightening investigation. With regards to the power aware governor, you have to realize that it's a very hard problem. One that no one has managed, yet (iirc, huawei has claimed that their kernel has such a scheduler, but, you've seen how well it works), for general loads. Yes, there are many ideas but, as you've surmised, board implementations can drastically change assumptions. BTW, power collapse appears to just be the arm term for the state under which cpuidle takes over for that core. So, it's not actually powered off, thus hotplug would still be needed. For an overview of the domain see: http://lwn.net/Articles/482344/
Everyone is aware that developing a power-aware scheduler is a VERY hard problem. The Linux kernel doesn't have it, but neither does anyone else really.
The problem is that when ARM developed big.LITTLE, they would have known that for it to work, it requires a well-designed power-aware scheduler. And they should have known that that's a very hard problem to solve in software. History is littered with great hardware architectures that should have performed a lot better, if only the software was up to it, e.g., Intel's Itanium or Transmeta's Crusoe. But history has time and time shown that architectures that require too clever a software solution around them just don't work (perhaps one should add AMD's Bulldozer to this list as well, seeming as AMD expected everyone to rewrite their software to become GPU aware).
I remember back in the days KISS was a big mantra of Unix sysadmins, and for a good reason: you can optimize simple things very well. Witness the simple (by comparison) dual core Apple A8 that doesn't require any magical scheduler or a binary translator (Denver) and yet beats everyone else in practical tests. It's disheartening that the likes of ARM and Nvidia don't seem to have learnt this.
The article suggests that this (the scheduler) is work that Samsung (alone) should've done. I don't recall the author indicating that it's actually an unsolved problem in computer science (again, in a general purpose environment), as I indicated, BTW. big.LITTLE will certainly work best with such a scheduler, but even without you should expect to approach some efficiency that lies between the big and little cores. Even this half-hearted attempt isn't terribly worse than the android competition.
Power collapse is proper power gating on the individual cores in their respective CPUIdle states, your link is outdated and does not apply to new generation ARM cores.
Do you have a reference? To the best of my knowledge linaro are still working on hotplug. Also, for Linux, cpuidle refers to a specific governor that doesn't actually power down, but handles the c states, but it looks like arm uses it for suspension (http://events.linuxfoundation.org/sites/events/fil... slides 10 and 13).
CPUIdle is the kernel framework that manages the CPU's idle states, such as WFI (Clock gating), core power collapse, cluster power collapse. CPUIdle states are C-states, but "C-states" is an ACPI denomination that is rarely used on ARM CPUs.
Hotplug has been left for dead for a long time, it hasn't been used for PM in ARM CPUs since the A15/A7 generation. Today it's only used for like forcing cores off when in screen-off states or rare coarse power management for like battery savings modes for some vendors.
I have Exynos and wanted that specifically for the Wolfson Audio. Sad to note that, its not exploited enough by Samsung.
Did someone notice the RAM bandwidth. How much impact that it makes? Also, from personal experience, I find exynos seems to be smooth and never noticed lag for an user like me. Graphics performance could be better but again no visible issues for what I have been playing so far with such dense display.
I have been working with ARMv7A cores, and I am interested in the floating-point capabilities of new 64-bit ARM processors. What is the throughput of the main floating-point instructions (add, mul, MAC) for Cortex A53 and A57? Something similar to the test done in http://www.anandtech.com/show/6971/exploring-the-f...
i just dont get it wat do u mean by "however it remains unclear whether we'll see this on the Note 4. My personal opinion remains that we won't be seeing this overhaul in Samsung's 5.0 Lollipop update." does this mean that exynos 5433 could be upgraded to 64bit on android 5.1 or later updates??
At the time of the writing the Lolipop update was not yet released. Now it's out and it's not 64bit as I suspected. If they didn't update it now they won't ever update it and it will stay on AArch32.
> With A7 slot-0 was full-featured while slot-1 could only issue branch and integer data
Actually, the slot-1 could only execute a few integer instructions with immediate arguments (source value encoded into instruction) - which makes the dual-issue capability of Cortex-A7 more or less a marketing-thing: http://hardwarebug.org/2014/05/15/cortex-a7-instru...
I guess this was also the reason why they made Cortex-A32/35 pure single-issue machines again.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
135 Comments
Back to Article
ddriver - Tuesday, February 10, 2015 - link
I'd like to see A57 performance without being so crippled by a ram bottleneck.blanarahul - Wednesday, February 11, 2015 - link
Loved this article. Only thing missing was gaming fps and power consumption comparison b/w LITTLE cluster only, big cluster only and big.LITTLE modes.ddriver - Thursday, February 12, 2015 - link
Also in true 64bit mode, cuz a lot of the perf improvements in v8 are not available in legacy 32bit mode.It is a shame really, samsung decided the uArch improvements would be enough to barely pass this chip as "incremental", they didn't bother to feed a higher throughput chip with a wider memory bus. As much as it pains me, apple did better in that aspect by not crippling their A7 chip, even if only because they needed it for a "wow factor" after so many generations of mediocre hardware, especially given the many exclusive initial shipment deals they secured to stay relevant.
thegeneral2010 - Wednesday, February 18, 2015 - link
i like wat u say and i really like to see note 4 running on 64bit this would give samsung processors a great push forward and trust of consumers.bigstrudel - Tuesday, February 10, 2015 - link
If it wasn't completely obvious already:Apple A Series stands alone years ahead of the rest of the pack.
Flunk - Tuesday, February 10, 2015 - link
But if they don't sell it to anyone else, it doesn't really matter does it?Apple doesn't compete with Samsung or Qualcomm when it comes to selling SoCs because they don't sell SoCs to other companies. A slight lead in CPU performance is not going to get people to buy an iPhone over and Android, if that's what they're set on buying.
xype - Tuesday, February 10, 2015 - link
It does matter insofar as to be a benchmark of what is possible (as long as they are ahead). And let’s not pretend Apple’s CPUs sucking wouldn’t invite the same kind of comments—just like every situation where 2 competing technologies are compared.Platform/fanboy trolling aside, that’s something Android users benefit from as well. Apple being "stubborn" about 2 core CPUs, for example, is a nice counterweight to the 8 cores and 8 mini-cores and 8 quasi-cores trend that some CPU vendors seem to have a hard-on for, and it gives a nice real-world example of how such an approach to mobile CPU design works out, no?
If Apple stays ahead in the mobile CPU game, the people using non-Apple phones will always have a target to point to and demand equality with. Otherwise they’d just have to live with whatever Qualcomm et al feed them.
bigstrudel - Tuesday, February 10, 2015 - link
My comment isn't fanboy jingo-ism. Its fact.There's not a single Android ARM core on the market that can even match the power of the Apple A7's Cyclone cores much less A8's 2nd gen design.
Were still waiting for anything custom to come out of the Android camp aside from the frankensteinish design of Nvidia's Denver core.
I really shouldn't need to explain why to people on Anandtech.
ergo98 - Tuesday, February 10, 2015 - link
The Tegra K1 64 bit is faster, core per core, versus the A8 (you do realize that the K1-64 has only 2 cores, right? I'm going to have to guess no, or you just are completely unable to read a chart). The A8x offers marginal per core performance advantages over the A8, and the primary benefit is the third core. The K1 64 is a A57 derivative, *exactly like the A8*.Your comments can only be construed as trolling. Can't match the A7? Give me a break.
tipoo - Tuesday, February 10, 2015 - link
Ergo, you're completely off. The Denver K1 is a VLIW code morphing architecture - it has nothing to do with the Cortex A57, nor does the Apple Cyclone, they're both custom architectures.The K1 offers better performance in benchmarks, but as a result of code morphing, it can be hit or miss in real world, causing jank.
tipoo - Tuesday, February 10, 2015 - link
I don't know how one can read AT and think this. Read the Nvidia Denver (k1 64) architecture detail. Read the Apple A7 analysis, and by extension that's also the A8. They're not "a57 derivative", they're completely custom.ergo98 - Tuesday, February 10, 2015 - link
Oh save the noise. Both nvidia and Apple are design partners of ARM, and have a long history of deriving from ARM designs. The Apple design (which you seem certain of, despite having zero possible authority to be so) is almost certainly derived from earlier revision A57 designs. Yes, just like Snapdragon they modify and heavily, but a big benefit of being ARM partners is that they don't have to do all of the work themselves.I don't know how you can read Anandtech and not have any rational knowledge of how the semi world works.
Alexvrb - Tuesday, February 10, 2015 - link
They are ISA compatible... but that doesn't mean they're direct derivatives. The custom cores are often quite different in terms of underlying architecture from the reference ARM designs. If it was a simple tweaked ARM design, Qualcomm wouldn't be deploying a reference core in their upcoming flagship - their next-gen custom core isn't ready yet because it takes time.Dmcq - Wednesday, February 11, 2015 - link
If anything the Apple Cyclone looks more like a Dec Alpha EV6/EV7 and the Nvidia Denver is like the Transmeta Crusoe rather than the ARM A15 or A57.tipoo - Wednesday, February 11, 2015 - link
Hide your wrongness in anger, why don't you. They are ISA compatible, nothing more. Apple doesn't even hold an A57 licence, they only licence the ISA now. And Nvidias architecture is very clearly completely different, if you knew what code morphing and VLIW were you would not be arguing this. Save your own noise.tipoo - Wednesday, February 11, 2015 - link
Here, since you can't do your own research. The entire core design is quite different from the relatively narrow A57.http://www.anandtech.com/show/7910/apples-cyclone-...
You could call them "derivative" in that the Core series is derivative of the pentium 3, but still nearly completely different.
doctorpink - Friday, February 13, 2015 - link
Ergo98 : You are so completely lost my friend! LOL Those who replied to you are right.jameskatt - Tuesday, February 10, 2015 - link
Note that the A9 will soon be coming out this year. This means Apple will be 2 generations ahead of the pack when it comes to 64-bit processors. And unlike the Tegra, it is also going into the iPhone, not just a tablet.theduckofdeath - Sunday, February 15, 2015 - link
And the Tegra T2 won't be announced this year? Or the 14nm Exynos processors (You know, the ONLY 14nm mobile processors in the world)DarkLeviathan - Saturday, December 19, 2015 - link
I'm very sure that the Exynos is not the only 14nm processors in the world. And you know that making it a smaller process doesn't make it better right? Just take a look at Chip-gate on the new iPhones. TSMC's 16nm is better than Samsung's 14nm. And apply to their own Exynos processors. Maybe they would do better if they were 16nm too huh?gijames1225 - Tuesday, February 10, 2015 - link
Why do you say that? This seems highly comparable in benchmarks, and it's not even running a 64bit OS yet. I'd guess that after they update it to Lollipop it's equal to the A8 overall, which is really impressive given they're generic cores from ARM.arsjum - Tuesday, February 10, 2015 - link
I don't think bigstrudel actually read the article before leaving that comment.Stuka87 - Tuesday, February 10, 2015 - link
But it does take them twice as many cores, higher clock speed, and triple the ram to match the A8. I am not sure Apple is years ahead, but they certainly have an edge, which is most likely a result of designing the software that runs on the hardware. They are able to make efficiency improvement android handset makers just aren't able to do.Alexey291 - Tuesday, February 10, 2015 - link
That's called optimising and that was actually something derided by the author in the article (browser optimisations for the platform are apparently a bad thing now - talk about throwing out the baby with the bathwater)Andrei Frumusanu - Tuesday, February 10, 2015 - link
I think you misunderstood my point of view, I'm all for optimizations and hope vendors continue it, and even encourage it. I was just pointing out that it negatively affects our benchmarking methodology as Chrome continues to fall behind.bigstrudel - Tuesday, February 10, 2015 - link
Chrome isn't falling behind in real-world load times.Only in tampered with benchmark results like Samsung's "optimized" Stock Browser. Benchmarks show performance gains for Samsung's browser vs Chrome on the order of twice the performance? It makes me chuckle to see Samsung also only cheats the results enough to equal the iPhone 6.
Give me a break. Anyone with half-a-brain knows whats up here.
hung2900 - Tuesday, February 10, 2015 - link
Bigstrudel, how big is your brain? A quarter?Browser optimization is cheating? So hilarious. Did you spend a little bit of time to read the Browser benchmark part? Or just your brain cannot process?
Kidster3001 - Friday, February 27, 2015 - link
Samsung's custom browser is a tweaked version of chrome. It's just optimizing for the platform. Not only commendable but something that should be the norm.bigstrudel - Tuesday, February 10, 2015 - link
4 times the cores. Much higher clock speed and it still lags behind A8 overall.Easy to understand which one is more advanced based on that set of facts.
DarkLeviathan - Saturday, December 19, 2015 - link
lol true. but i never thought about it that way hahatipoo - Tuesday, February 10, 2015 - link
Agreed, it was a little shocking to see that even the Cortex A57 is stomped on by the A8/Cyclone R2. And that with two cores and sane clock speeds.I would say this is what everyone else would be doing, ideally, but the cost here is die size. Instead they shoot for smaller higher clocked designs to save some die size and cost, since other companies aren't willing to pay as much for the SoC in the BoM as Apple is.
ruggia - Tuesday, February 10, 2015 - link
to be fair, the basic minimum performance Cyclone R2 have had to achieve was beat A57, since that was the reference design available from ARM for everyone. So I don't think it's that surprising.tipoo - Tuesday, February 10, 2015 - link
On the other hand, them and Nvidia alone have parts better than the A57 per-core out, and even from those two the 64 bit Denver K1 is too high in power draw and chokes on some tasks due to its code morphing engine bottlenecking the process.So it is still remarkable, to me, how early and how long Apples lead has lasted.
Kidster3001 - Friday, February 27, 2015 - link
Why do we need octa cores in phones/tablets? Marketing says we do, plain and simple. It's bragging rights. No real benefit but it sounds cool. Apple is doing it wider and smarter.DarkLeviathan - Saturday, December 19, 2015 - link
But unfortunately people are getting dumb-er and stupid-er (XD). Falling into marketing ploys. I feel like Apple is the one who is not marketing crazy now. Its all numbers with the Android people :/ Apple cares about user experience more than any other companies and they spend a lot more money on it.xdrol - Tuesday, February 10, 2015 - link
Please go compare it to nVidia Denver cores.tipoo - Tuesday, February 10, 2015 - link
I have. It wins some benchmarks, but is less consistent in the real world because it's a code morphing design that can get choked up by unpredictable code. It's also more power hungry, though that's partly the fab.lilo777 - Tuesday, February 10, 2015 - link
bigstrudel, you are either Apple fanboy or a troll. For your own sake I hope it's the former and you understand that what you posted is pure nonsense. The only tests where iPhone dominates Samsung phones are specint and basemark tests. But the reason for that is not what you probably think it is. Specint benchmarks use only one core. Sure, A8 core is faster but then iPhone has just two of them. The total power of four cores is higher than that of two A8s. And it's not like the two A8 cores consume twice less power than four Samsung cores. A8 is a very BIG core. Each A8 core uses more power than a single Samsung core. And basemark scores... Those depend on screen resolution and iPhone has a very low resolution compared to Note 4. In short, both approaches (two large cores or big.LITTLE architecture) have pros and cons. There is no magic here. It is not clear to me why would you say that A8 "stands light years ahead" when the phone based on this SOC (iPhone 6) lags high end Android phones in synthetic benchmarks like Geekbench.DarkLeviathan - Saturday, December 19, 2015 - link
1. The CPU and resolution has almost nothing in which you can compare with2. If you do a little research and stop drinking that Samsung marketing soup, you would realize that not all the Samsung cores are not the same. They vary in power...
PC Perv - Tuesday, February 10, 2015 - link
Apple A series is already eclipsed by Exynos 5433 as seen by sub-test scores in Geekbench. (how does Geekbench calculate aggregate score? I have no idea) A8 will also be crushed and humiliated by soon-to-arrive Exynos 7420.Dual-core is the best configuration? My ass. That is why they added another core in the new iPad. Oh, if you look at the die shot there is a space for a 4th core there, too.
DarkLeviathan - Saturday, December 19, 2015 - link
They added another core in the new iPad for a totally different reason. Its like having a laptop and a desktop.And there are several reasons why having dual cores in the iPhone is better and having dual cores in the iPad would be a worse idea.
1. The cores in the iPad would get so big and inefficient that it would be pointless to make them bigger. The battery would be wasted. However on the iPhone, the 2 cores are the best size as it is not too small to be slow and too big to be too power hungry.
2. The 3 cores on the iPad is there because they have more space. If they went full Samsun retard style with 4 or 8 cores, you would see 4 or 8 cores with high clock speeds but very low processing power. And therefore inefficient wast of resources and space. Not to mention that most apps only use 1 or 2 cores to run.
zepi - Tuesday, February 10, 2015 - link
Outstanding article, once again.Only thing I'm worried is that writes of such pieces are "Hot Shit" in employment market and I fear our technical writers could yet again disappear to better paying tech-companies...
Andrei Frumusanu - Tuesday, February 10, 2015 - link
I don't plan on going anywhere for the foreseeable future :)Ryan Smith - Tuesday, February 10, 2015 - link
Indeed. Better leg shackles have proven to be an excellent investment this year.rd_nest - Tuesday, February 10, 2015 - link
Wonderful article, loved the detailed analysis done. I wonder if there are any improvements in software stack in 7420 compared to 5433 specially since 7420 will be shipped worldwide.Andrei Frumusanu - Tuesday, February 10, 2015 - link
I'm looking forward to analysing those changes. There should be a considerable amount of change given the new AArch64 kernel platform, but we won't know till it's out.arayoflight - Tuesday, February 10, 2015 - link
I hope to see such an article again in future for the Exynos 7420. Just don't delay that this much.hlovatt - Tuesday, February 10, 2015 - link
I would second zepi's comment "outstanding article", shows why AnandTech is still way ahead of other review sites.TomWomack - Tuesday, February 10, 2015 - link
I'm really impressed by some of the fiddly things you've managed to measure here. What was your source for the die area measurements (Chipworks hasn't done a 5433 tear-down yet), and did you set up the detailed power-monitoring hardware yourself?Andrei Frumusanu - Tuesday, February 10, 2015 - link
The power measurement setup is my own work and we'll hopefully see more of it in the future.Sonicadvance1 - Tuesday, February 10, 2015 - link
"The overall increase in cache helps to improve performance, though perhaps more importantly the larger instruction cache helps to offset the larger size of the 64-bit ARM instructions."This is incorrect. AArch64 has a 32bit instruction length just like ARMv7.
Unless of course you were comparing to 16bit Thumb instructions. Vague in either case.
jjj - Tuesday, February 10, 2015 - link
Wish you would have included power numbers for A15 and A7 on 28nm since that's the more common process for A15/A7 and it's unlikely we'll see them much on 20nm and bellow (to be clear, not saying that you should have excluded the numbers on 20nm).Said this before, very curious about the encryption gains in actual use for both power and perf so maybe you guys look at that at some point. And maybe include https sites in the web browsing battery tests- tests that are kinda fuzzy on the methodology, maybe you've detailed it somewhere and i just don't remember.
The process scaling is surprising, maybe TSMC did better,we'll have to see.
Any clue how A53 power scales at much higher clocks, obviously not from this testing. Wondering how it would perform at very high clocks vs a lower clocked A57. At.1.3GHz the A53 seems to use some 3 times less power than A57 and given it's die size if it could go to 2.5Ghz on 20nm it would be interesting, at least from a cost perspective.
Andrei Frumusanu - Tuesday, February 10, 2015 - link
I only have a S4 with an 5410 at disposition, and that is running cluster migration and it's a very old chip by now. The only other candidates would have been the 5422 S5 variant which I don't posses, or to have to destroy the unibody shells of my Huawei devices to be able to do a proper power measurement.I did overclock the A53, but above 1.5GHz it's not worth running the little cores as the voltage rise is too high and the A57's at low frequency are more efficient. This is highly dependent on the core implementation, I imagine MediaTek's SoCs with high clocked "little" cores are much better optimized in such scenarios.
jjj - Tuesday, February 10, 2015 - link
Thanks for the reply.I kinda like the A53 perf at 1.5GHz and above ,nice little core and nice boost for the market it's addressing. In this SoC it does seem that above 900MHz the power goes up a lot.
Devo2007 - Tuesday, February 10, 2015 - link
Interesting to see the PCMark numbers, and how Lollipop seems to help. Given that Lollipop overall "feels" smoother, it makes sense there would be something that would allow that to be somewhat measurable.Running an early build of CM12 on my Snapdragon Note 3, and I'm seeing numbers nearly on-par with the Nexus 5 shown here.
Pissedoffyouth - Tuesday, February 10, 2015 - link
I'm running CM12 on my Note right from from an early Temasek build. Absolutely love it, and there aren't too many showstopping bugs.I hope they do put note 3 on this graph.
Devo2007 - Tuesday, February 10, 2015 - link
Yup! Teamasek 7.5.1 as of today for me (was on 7.4 when I wrote that post). Absolutely loving it now, and feel comfortable using it as my daily driver.Ranger101 - Tuesday, February 10, 2015 - link
This is the most interesting and relevant technical read I have had for some time.An excellent article.
Well done Messrs Frumusanu and Smith.
juicytuna - Tuesday, February 10, 2015 - link
Monster of an article. Will take me many rereads to take it all in.This is what Anandtech is all about, this is what separates it from the rest.serendip - Tuesday, February 10, 2015 - link
Excellent article, I really appreciate the in-depth analyses on the differences between the Exynos and SnapDragon SOCs. I'm shaking my head at Samsung's mad product line though. They seem to make a different variant for each region with so many SOC/modem/RF combinations.Wouldn't it be better to have just one or two variants supporting most of the LTE frequencies out there? I would hate to be the person at Samsung in charge of software updates for these phones. You would need a huge developer team to keep track of per-device changes and fixing bugs while keeping the code consistent along the same model line.
Johnmcl7 - Tuesday, February 10, 2015 - link
I decided to go for the Snapdragon version for the Gear VR support, I think it was Carmack who posted recently saying the Exynos version was still lagging. Plus the Snapdragon version is officially supported in my territory which should make warranty calls less hassle, I've used the Exynos version but didn't really notice any difference in day to day use and was quite happy with the Snapdragon 800 in the Sony Z Ultra.Also the Snapdragon Note 4's are much better supported for custom roms compared to the Exynos versions.
djvita - Tuesday, February 10, 2015 - link
lol this now is old, samsung has a new exnyos (7420) with mali T760 ready for the S6.http://browser.primatelabs.com/geekbench3/1874253
Tom Womack - Tuesday, February 10, 2015 - link
And when the S6 comes out, in three months or so Andrei will have wired it up, connected it to data loggers, and run the experiments to work out what it does. If you want content-free reviews of products as they come out, I would recommend somewhere other than Anandtech.Andrei Frumusanu - Tuesday, February 10, 2015 - link
It should happen much faster than that, this article fell victim to the same problems as the Nexus 9. Luckily Ryan is healthy again and any future mobile content should be able to be handled by me and Josh.djvita - Tuesday, February 10, 2015 - link
i appreciate the reviews, and from the first part of tom's comment i thought he was going to say that yeah in 3 months after that there will be another exnyos (a72)?i actually like the low # of reviews. i don't want this site to become gsmarena. explore the arch ( i hope once the flex 2 comes out, you do so for S810) and perform normalized benchmarks that show not oooo lookie high score!, but the real improvements in the design and dies.
sure, do a review of each flagship, so people can decide, but not much more as it becomes too taxing on the writer.
Andreii - Tuesday, February 10, 2015 - link
Its not just lollipop though 7420 is overclocked. A57 cores at 2.1 and a53 cores at 1.5 ghzextide - Tuesday, February 10, 2015 - link
That's not what overclocking means...lilmoe - Wednesday, February 11, 2015 - link
looks like the 7420 won't be crippled by memory bandwidth this time around.http://browser.primatelabs.com/geekbench3/compare/...
mpokwsths - Thursday, February 12, 2015 - link
Learn to search better and compare apples to apples: http://browser.primatelabs.com/geekbench3/compare/...psychobriggsy - Tuesday, February 10, 2015 - link
From this (http://browser.primatelabs.com/geekbench3/compare/... we can see that the 7420 is significantly faster under Lollipop that the 5433, the Lua multicore score seems to be fixed, and the significantly higher memory scores suggests LPDDR4 or 128-bit memory.mpokwsths - Thursday, February 12, 2015 - link
This one is the correct: http://browser.primatelabs.com/geekbench3/compare/...Tom Womack - Tuesday, February 10, 2015 - link
This is a superb piece of work: Anandtech at its best.Pissedoffyouth - Tuesday, February 10, 2015 - link
Interesting about the power consumption of A7 vs a15, and a53 vs a57.I'm curious, what would the performance/Watt be like at the same power draw if you clocked the a53 sky high? Overclock it to 3ghz and see what happens
Andrei Frumusanu - Tuesday, February 10, 2015 - link
My unit won't go over 1.5GHz unless I vastly increase the voltages, and I don't feel comfortable doing that.Pissedoffyouth - Tuesday, February 10, 2015 - link
Thanks for the responsepatrickjchase - Wednesday, February 11, 2015 - link
You can't - A53 has too many gate delays per pipe stage.If you want to go 3 GHz then you have to spread the total work required to execute an instruction over more stages (less work per stage ~= fewer gate delays per stage). That's one reason why the A57 has a 16-stage pipe (minimum for a simple integer op) whereas the A53 has an 8-stage pipe.
Pissedoffyouth - Wednesday, March 4, 2015 - link
Thanks for the response dude, interesting stufftechcrazy - Tuesday, February 10, 2015 - link
Excellent article as always. It looks like you guys are going to review the Galaxy alpha, looking forward to that review. Have you guys manage to get A Sony Xperia Z3 Compact? It will be very interesting to see how it compare against Alpha.Andrei Frumusanu - Tuesday, February 10, 2015 - link
I'm not sure we'll be actually reviewing the Alpha due to the device being discontinued. I still have the MX4 Pro in the pipeline and after that things will get busy due to MWC.tdslam720 - Tuesday, February 10, 2015 - link
Great article but I can't help but feel like this is 4 months old. Wouldn't it have been more relevant and better from a clicks point of view to apply most of this research and work to the 7240 and just release this in March?Andrei Frumusanu - Tuesday, February 10, 2015 - link
The article was never intended to be released this late, so no.Shadowmaster625 - Tuesday, February 10, 2015 - link
I'm just not seeing this huge trouncing of the 805. Where is it? It is ahead slightly, but its battary life suffers by what appears to be a roughly equal amount. So it is basically the same as an overclocked 805. But the 805 is an older more straightforward, proven design and it is probably quite a bit cheaper at this point.extide - Tuesday, February 10, 2015 - link
It's not supposed to trounce it...tipoo - Tuesday, February 10, 2015 - link
Power draw increases *more* than proportionally with clock speed, so an overclocked S805 matched to the performance of these would likely draw more power than them.But yes, I do agree that the tradeoff is less than exciting. Denver also draws too much power, so we really don't have much in the Android SoC space.
lopri - Tuesday, February 10, 2015 - link
Geez. The article is too in-depth! ;) I do not know how long it will take for me to finish reading but I wanted to say thank you ahead.Tikcus9666 - Tuesday, February 10, 2015 - link
All these phone reviews are overkill IMO the first one of any giving technology or OS is relevant the rest not so much, there are only a few things important with a phone(smart or other).This one is slightly more relevant since it looks at 2 phones marketed as the same device (however since both versions are not available in the same region it is a mute point)
Can you make phone calls without it dropping the call
Can you send and receive text messages
Does opening email, or any applications happen in a timely fashion
Does it work without crashing
If 1 phone renders a web page a few MS faster than another, it does not matter
If 1 phone can run a game at a few more FPS it does not matter if the slower phone offers acceptable performance.
If a photo is slightly better on phone a compared to phone B it doesn't matter since it is not good enough to print anyway (unless they start putting proper sensors at least 1/2.3, on phones you will never take acceptable photos). As long as it is good enough to view on the 4/5/6" screen to capture the moment it is good enough.
TomWomack - Tuesday, February 10, 2015 - link
But this isn't a review of a phone. If you want a review of a phone, many specialised phone-reviewing sites which look at stupid details to do with phone calls and text messages are available.This is a review of a processor and a GPU; quite plausibly the people at ODROID will make the processor and GPU available on a convenient mini-ITX-sized board with an HDMI connector before Christmas, at which point knowing the cache configuration of the computer is quite handy.
blzd - Saturday, February 14, 2015 - link
I think you may have made a left when you should've made a right.We don't come to Anandtech to see that "yet another SoC delivers acceptable performance, you can all go home now!" lol.
Cygni - Tuesday, February 10, 2015 - link
I was worried about AnandTech without Anand and Brian's insanely thorough testing and writing style. I'm feeling a lot better after reading this article. Great job Andrei/Ryan, great article.lilo777 - Tuesday, February 10, 2015 - link
in fact the opposite is true. With Anand and Brian, Apple products always were praised beyond the reason. Not the case here (although it's primarily a comparison between non-Apple products). Just pure technical stuff as is.MrSpadge - Tuesday, February 10, 2015 - link
Excellent work, guys! But let me point out something:1. Your Geekbench numbers show spectacular gains for the A53. They're actually so good that the multi-threading speed-up almost always exceeds the number of cores (judging by eye, have not run the numbers). For A7 the speedup factor is a bit less than 4, right where it should be. It certainly looks like the big cores were kicking in, at least partly.
2. You wonder that power scales sub-linearly with more cores being used. Actually this is just what one would expect in the case of non-ideal multi-thread scaling (as the A7 shows in Geekbench). The load of all ccores may be the same, percentage-wise, but when running many threads these are competing for L2 cache and memory bandwidth. There will be additional wait times under full load (otherwise the memory subsystem is vastly oversized), so each core is busy but working a little less hard.
3. The lower performance per W of the A53: this may well be true. But if the big cores did interfere, it could certainly explain the significantly increased power draw.
4. You hope for A53 at 1.5 - 1.7 GHz. I agree for CPUs which use only A53's. But as little cores this is not necessary. If you push a design to higher frequencies at the same technology node you always pay in terms of power efficiency (unless you start bad / unoptimized). Better let the little cores do what they're best at: be efficient.
... I'm off to the next page :)
MrS
Andrei Frumusanu - Tuesday, February 10, 2015 - link
Regarding your concerns on the big cores turning on: They did not. I made sure that they're always offline in the little testing. As to why GeekBench scaled like that, I can't answer.jjj - Tuesday, February 10, 2015 - link
Geekbanch scales like that sometimes, TR looked at this phone last week and they notice the Shield tab scaling better than 4x in some tests.For the A53 better scaling over A7 maybe it's the memory subsystem? No clue how heavy GB is on it but the A53 does have more memory BW and maybe faster NAND (you don't have storage tests for the Alpha ).
MrSpadge - Tuesday, February 10, 2015 - link
Sometimes one gets such results if the MT code path uses newer libraries to get multi threading, but also introduce other optimizations the tester is not aware of. Or they have to rewrite code/algorithm to make it multi-threaded and thereby create a more efficient version "by accident". I don't know if any of this applies to GB, though.tipoo - Tuesday, February 10, 2015 - link
It's done that before, I think the cache is almost certainly involved. Maybe it has good cache reusability for multicore in its testing.SydneyBlue120d - Tuesday, February 10, 2015 - link
Excellent article, thanks a lot for that.I'd like to dig deeper about why Samsung is ruining the wonderful Wolfson DAC, I remember that even the legendary François Simond shared the issue with Samsung Developers without getting a response, maybe You will be able to have a response :) Also, I remember an audio quality test suite, why didn't You use it in this review? Thanks a lot.
Andrei Frumusanu - Tuesday, February 10, 2015 - link
We realized testing audio without having the proper equipment is a futile exercise and does not really portray audio quality of a device. Only Chris has the professional equipment to objectively test audio, such as done in the iPhone6 review: http://www.anandtech.com/show/8554/the-iphone-6-re...PC Perv - Tuesday, February 10, 2015 - link
Thank you so much for ditching SunSpider, and thank you for explaining why. It has gone way too long.PC Perv - Tuesday, February 10, 2015 - link
I know you are trying to be nice to your colleague and give them a benefit of doubt, but to mercilessly critical eyes of mine your colleagues (Joshua Ho & Brandon Chester) have shown and time and time again they are not qualified to review Android products. I hope Mr. Frumusanu and Mr. Smith will take charge of this area in the future and limit those two to Apple product reviews.I would love to read quality reviews and analysis like this instead of their tamper tantrum.
PC Perv - Tuesday, February 10, 2015 - link
For example, in the comment section here,http://www.anandtech.com/comments/8795/understandi...
[Q]The increase in brightness for AMOLEDs at 80% APL rather than 100% APL is not very significant, and changing testing to accommodate AMOLED's idiosyncrasies doesn't seem like a good idea either. To put it in perspective, even if I had tested the Nexus 6 at 80% APL in the review my conclusion about the brightness being sub-par would have been exactly the same.[/Q]
That is what Brandon Chest had to say about brightness of the Nexus 6's screen. So arrogant, so biased. But according to the scientific data provided by this article (pg. 10), APL can indeed make a huge difference in AMOLED screen's brightness, given power target. For example, at display power target is 1W, 70% APL will raise the brightness by approximately 40%. At 50% APL, max brightness practically doubles.
I was appalled by the disparaging and arrogant attitude by Brandon Chester when it comes to correctly evaluating Android devices. He also made similarly nonsensical "arguments" in his tablet recommendation article for the holidays.
toyotabedzrock - Tuesday, February 10, 2015 - link
Dropping the browser tests is just stupid squared and wastes the opportunity to have Google and arm fix the inconsistency issue!Also your performance table for the a57 has an error for the PNG Comp ST.
toyotabedzrock - Tuesday, February 10, 2015 - link
To me it is clear why arm has a new core coming. The a57 was not designed to do 64bit well. If the system uses only 64bit apps it might get bottlenecked.lopri - Tuesday, February 10, 2015 - link
(pg. 6)BaseMark OS II Energy Efficiency test makes no sense to me. I get that perf/watt factor looks worse on the 5433, but why does the test consume more energy when run on big cores only, compared to when run on all 8 cores?
You have explained the performance degration part, but I am not sure whether you mentioned the reduced energy consumption part running 8 cores compared to 4 (big) cores. Running on 8 cores consume a little more than running on 4 LITTLE cores.
I wonder if that benchmark is trust-worthy?
Gigaplex - Tuesday, February 10, 2015 - link
Read through it again. They do comment on that and claim that the switching between big and little cores is likely adding so much overhead they're better off just staying on the big cores.Gigaplex - Tuesday, February 10, 2015 - link
If only there was an edit option... My original comment referred to reduced perf/watt in "8 core" mode rather than just the energy consumption.As to why running on all 8 uses less than only the big 4? It doesn't use them simultaneously, it can only use the big or the little, and it switches between them dynamically. Since the big cores get to idle/sleep when it's running on the little cores, it uses less power overall. This is the whole point of the big.LITTLE design. It's just a shame it doesn't actually work from a performance point of view.
lopri - Tuesday, February 10, 2015 - link
So that means the benchmark is limited to 4-threads, I assume? Stating that would have helped me understand it.Andrei Frumusanu - Wednesday, February 11, 2015 - link
I explained the nature of the XML test and that it was 3 threads:"The test is a good candidate because it offers a scaling load with three threads that put both a high load on some cores and let others exercise their power management states at the same time, definitely behavior you would see in day-to-day applications."
MikhailT - Tuesday, February 10, 2015 - link
Is it me, or does anybody else wish ARM would change their naming scheme?This single quote took 4-5 re-reads for me:
"As far as performance goes, ARM tells us that A53 can match A9 in performance at equivalent clock speeds. Given just how fast A9 is and just how small A53 is, to be able to match A9’s performance while undercutting it in die size and power consumption in this manner would be a feather in ARM’s cap, and an impressive follow-up to the A8-like performance of A7."
lopri - Tuesday, February 10, 2015 - link
Is the "special" frequency only available to ALU-heavy loads on Exynos really a special case? I noticed a similar behavior on S800, too. Adreno 320 should do max 450 MHz, but 99% of the time I see it maxes at 320 MHz. I thought something must be wrong at first, but when I ran benchmarks or other compute-heavy demos, it finally showed me 450 MHz. (not talking about cheating, obviously) It seems like a wide-spread practice.zodiacfml - Tuesday, February 10, 2015 - link
Not surprising outcome. All they need is produce this chip for the sheer number of cores which is popular in some but large markets. The chip is supposed to be good for better efficiency but we didn't see that.habbakuk87 - Wednesday, February 11, 2015 - link
I had like to thanks the writers for great in depth article, this is the kind of thing which has kept me coming to this site over the past many years.Keep up the good work.
Arbie - Wednesday, February 11, 2015 - link
Yes, this is a great article - knowledgeable and in-depth. Work like this is what keeps Anandtech way above the crowd. Thanks.joe_dude - Wednesday, February 11, 2015 - link
What it looks like to me is that they need to cap 4 big core load to 1.6 GHz, which would keep the thermals under control. Going by the chart, 1 core @ 1.9 GHz, 2 cores @ 1.8 GHz, 3 cores @ 1.7 GHz would work nicely for power consumption/heat as well. It seems Samsung and Qualcomm are setting the max frequency too high. That last 100 to 200 MHz requires a lot more voltage.joe_dude - Wednesday, February 11, 2015 - link
You look at the power consumption at 1.9 GHz vs. 1.6 GHz - 7.39w vs. 4.44w. That's the crux of the problem right there. 4 cores should not be running at such a high clock speed (and voltage needed to support it).PrinceGaz - Wednesday, February 11, 2015 - link
"So the question is, is it still worth to try and get an Exynos variant over the Snapdragon one? I definitely think so. In everyday usage the Exynos variant is faster. The small battery disadvantage is more than outweighed by the increased performance of the new ARM cores."That made me laugh as it is easily the most out of touch comment I've read in an AnandTech review.
It may be true for you as a reviewer sitting at home with the phone plugged into a USB charger running benchmarks that you feel the extra performance is worthwhile, but it will count for nothing when you use it in the real world and find your battery is dead earlier. Almost everyone with a smartphone today would rather have longer battery life instead of higher performance, because just like with PCs for some time now, the performance is already good enough.
Longer battery life trumps extra performance in smartphones now. I don't know why you want to put a positive spin on these higher performance but lower efficiency A57/A53 cores; I doubt ARM are paying you, but it seems they are a step backwards for people who use their phone primarily on the move, which includes most people.
patrickjchase - Wednesday, February 11, 2015 - link
From long experience with a variety of microarchitectures (including ARMs), I would guess that the latency/bandwidth "oddities" reflect differences in hardware prefetch. That's the most logical culprit among the list of changes that ARM provided.The hypothesis that the capability to dual-issue loads/stores impacts bandwidth to L2 and/or DDR seems questionable, because 4xA7 already has enough ld/st bandwidth to saturate both. Memory-limited code shouldn't see much impact due to issue-rule relaxation.
aryonoco - Wednesday, February 11, 2015 - link
Andrei and Ryan, thank you. I have not been impressed with anything Anandtech has published this much since the Original HTC One M7 review by Brian.I believe you guys have just published the most thorough, detailed, comprehensive review of every aspect of an ARM SoC. Short of working at a chip maker's lab, I don't think anyone is going to have any better exposure to the ARM ecosystem than what you guys have presented here.
Huge thanks for finally paying attention to the SoCs that don't make it to the North American market. I've been fascinated by their performance and power consumption metrics, it's great to finally have an authoritative view of them. I would love to have your take on some other SoCs in this regard as well, especially Cortex A17. There is not much coverage of Cortex A17 and I think, given the situation with big.LITTLE, a quad core well optimised Cortex A17 might actually be a hidden weapon that no one seems to be using.
Also very much looking forward to your coverage of overclocking/undervolting mobile devices. You guys are truly bringing AnandTech to the mobile industry.
Once again, thank you. To be honest, I've been a bit worried since Anand and Brian's departure about the direction of AT, and it's so good to see it thrive in such capable hands now.
Andrei Frumusanu - Wednesday, February 11, 2015 - link
I'm planning on reviewing the A17, but still in the process of securing a device. Hopefully in the near future.aryonoco - Wednesday, February 11, 2015 - link
On the subject of Javascript benchmarks and Chrome vs Stock browsers:Are we sure that all of the difference is indeed due to the optimized libraries that Samsung has developed, and that there is no benchmark-targeting optimization going on? After all, we saw what happend with Sunspider (and thanks for dropping it), it is impossible that they are not targeting Kraken and Octane as well?
Would it be feasible for Anandtech to develop its own proprietary javascript benchmark? It could answer a few of these questions.
tuxRoller - Wednesday, February 11, 2015 - link
This was an excellent read.Good detail, and enlightening investigation.
With regards to the power aware governor, you have to realize that it's a very hard problem. One that no one has managed, yet (iirc, huawei has claimed that their kernel has such a scheduler, but, you've seen how well it works), for general loads. Yes, there are many ideas but, as you've surmised, board implementations can drastically change assumptions.
BTW, power collapse appears to just be the arm term for the state under which cpuidle takes over for that core. So, it's not actually powered off, thus hotplug would still be needed.
For an overview of the domain see: http://lwn.net/Articles/482344/
Some useful links:
https://rt.wiki.kernel.org/index.php/Energy_Aware_...
https://lkml.org/lkml/2014/5/23/621
aryonoco - Wednesday, February 11, 2015 - link
Everyone is aware that developing a power-aware scheduler is a VERY hard problem. The Linux kernel doesn't have it, but neither does anyone else really.The problem is that when ARM developed big.LITTLE, they would have known that for it to work, it requires a well-designed power-aware scheduler. And they should have known that that's a very hard problem to solve in software. History is littered with great hardware architectures that should have performed a lot better, if only the software was up to it, e.g., Intel's Itanium or Transmeta's Crusoe. But history has time and time shown that architectures that require too clever a software solution around them just don't work (perhaps one should add AMD's Bulldozer to this list as well, seeming as AMD expected everyone to rewrite their software to become GPU aware).
I remember back in the days KISS was a big mantra of Unix sysadmins, and for a good reason: you can optimize simple things very well. Witness the simple (by comparison) dual core Apple A8 that doesn't require any magical scheduler or a binary translator (Denver) and yet beats everyone else in practical tests. It's disheartening that the likes of ARM and Nvidia don't seem to have learnt this.
tuxRoller - Thursday, February 12, 2015 - link
The article suggests that this (the scheduler) is work that Samsung (alone) should've done. I don't recall the author indicating that it's actually an unsolved problem in computer science (again, in a general purpose environment), as I indicated, BTW.big.LITTLE will certainly work best with such a scheduler, but even without you should expect to approach some efficiency that lies between the big and little cores. Even this half-hearted attempt isn't terribly worse than the android competition.
Andrei Frumusanu - Thursday, February 12, 2015 - link
Power collapse is proper power gating on the individual cores in their respective CPUIdle states, your link is outdated and does not apply to new generation ARM cores.tuxRoller - Thursday, February 12, 2015 - link
Do you have a reference?To the best of my knowledge linaro are still working on hotplug.
Also, for Linux, cpuidle refers to a specific governor that doesn't actually power down, but handles the c states, but it looks like arm uses it for suspension (http://events.linuxfoundation.org/sites/events/fil... slides 10 and 13).
Andrei Frumusanu - Friday, February 13, 2015 - link
CPUIdle is the kernel framework that manages the CPU's idle states, such as WFI (Clock gating), core power collapse, cluster power collapse. CPUIdle states are C-states, but "C-states" is an ACPI denomination that is rarely used on ARM CPUs.Hotplug has been left for dead for a long time, it hasn't been used for PM in ARM CPUs since the A15/A7 generation. Today it's only used for like forcing cores off when in screen-off states or rare coarse power management for like battery savings modes for some vendors.
sgmuser - Thursday, February 12, 2015 - link
I have Exynos and wanted that specifically for the Wolfson Audio. Sad to note that, its not exploited enough by Samsung.
Did someone notice the RAM bandwidth. How much impact that it makes?
Also, from personal experience, I find exynos seems to be smooth and never noticed lag for an user like me. Graphics performance could be better but again no visible issues for what I have been playing so far with such dense display.
giaf - Saturday, February 14, 2015 - link
Very interesting and detailed article, thank you.I have been working with ARMv7A cores, and I am interested in the floating-point capabilities of new 64-bit ARM processors. What is the throughput of the main floating-point instructions (add, mul, MAC) for Cortex A53 and A57? Something similar to the test done in http://www.anandtech.com/show/6971/exploring-the-f...
thegeneral2010 - Wednesday, February 18, 2015 - link
i just dont get it wat do u mean by "however it remains unclear whether we'll see this on the Note 4. My personal opinion remains that we won't be seeing this overhaul in Samsung's 5.0 Lollipop update." does this mean that exynos 5433 could be upgraded to 64bit on android 5.1 or later updates??Andrei Frumusanu - Friday, February 20, 2015 - link
At the time of the writing the Lolipop update was not yet released. Now it's out and it's not 64bit as I suspected. If they didn't update it now they won't ever update it and it will stay on AArch32.thegeneral2010 - Sunday, February 22, 2015 - link
so wat about that official patches in upstream linux?peevee - Sunday, March 8, 2015 - link
"Overall, the Exynos's CPU is much ahead of the Snapdragon. "But from the graphs everybody can see it is not. Why the exxageration?
MichelMerlin - Wednesday, August 5, 2015 - link
– On most other sources that I visited (http://www.gsmarena.com/samsung_galaxy_note_4-6434... , http://forum.xda-developers.com/note-4/help/snapdr... , etc), the SM-N910S is listed as Snapdragon (Snapdragon 805, Adreno 420).– on your site and on https://theoriginaloracle.wordpress.com/2014/11/07... , it is listed as Exynos (Exynos 5433, Mali-T760).
Can you sort it out? TIA,
Versailles, Wed 05 Aug 2015 14:04:20 +0200
ceisserer - Sunday, October 9, 2016 - link
> With A7 slot-0 was full-featured while slot-1 could only issue branch and integer dataActually, the slot-1 could only execute a few integer instructions with immediate arguments (source value encoded into instruction) - which makes the dual-issue capability of Cortex-A7 more or less a marketing-thing: http://hardwarebug.org/2014/05/15/cortex-a7-instru...
I guess this was also the reason why they made Cortex-A32/35 pure single-issue machines again.
android_user - Thursday, March 9, 2017 - link
Where are the thermal imaging of the phones ?Xentiment - Wednesday, February 6, 2019 - link
How did you disable power management driver?