Samsung Galaxy S III Review - AT&T and T-Mobile USA Variants
by Brian Klug on June 20, 2012 12:01 AM ESTWe’ve already seen dual core Krait (MSM8960) performance before and talked about it in the HTC One X (AT&T) review. For the most part, what we see with the USA SGS3 variants is largely the same as what we saw in MSM8960 (or MSM8260A, the same part with different baseband).
If you’re looking for a comparison to the International SGS3 with Exynos 4412, my unit hasn’t quite arrived yet. Anand and I plan to take a comprehensive look at the SoC performance landscape (Tegra 3 / MSM8960 / Exynos 4412) in another review after we’ve had time with the international SGS3. I have benchmark numbers from our SGS3 international preview at the launch event, but those were from pre-final software.
Where the SGS3 differentiates itself from what’s becoming a slew of USA-bound devices with MSM8960 is available RAM. In this case, all of the USA SGS3s include 2 GB of LPDDR2 RAM, of which 1.62 GB is available to user applications. My own suspicions for why this is the case is that Samsung wanted to make sure they had at least 1 GB available for user space applications. Clearly there is 380 MB absorbed for both preallocated GPU memory, and possibly DRM / baseband, and after that subtraction the only way to get dual channel (2x32b) LPDDR2 is to make the jump to two 1 GB LPDDR2 devices.
That’s my own speculation, but either way with the SGS3 you get ample RAM for applications. The positive thing is that even if you launch a ton of applications, it’s unlikely they’ll get tombstoned. I fired up my regular set of daily driver applications (twitter, baconreader, chrome, messaging, speedtest, radarscope, and a few others) and managed to use up nearly 1 GB.
JavaScript Performance
Although smartphones are clearly headed for a life beyond as a communications tool, web browsing, or phone duties, we are still lacking the tools to measure performance in areas other than a component of web page performance. Measuring JavaScript performance is one component of the entire web page rendering process but it’s the most mature in terms of something we can benchmark.
Sunspider 0.9.1 is quite possibly the most well known of these JavaScript tests, and a regular staple of our testing suite:
Like the other 1.5 GHz MSM8960 devices, the SGS3 does pretty well, but still is around 150ms slower. I ran this test multiple times but consistently got results in the 1750s or low 1800s for the SGS3s.
Browsermark is the next JavaScript test in our suite, and here it does very favorably against the rest of the competition.
It’s interesting to see the SGS3 not do stellar in Sunspider, but excellent in Browsermark. Note that in our preview piece, I did see the International SGS3 post a score of 161k here.
Next up is Vellamo, which is a Qualcomm benchmark developed originally for OEMs to use and optimize their browser performance, and later released for general use. It’s a regular member of our test suite and includes both JavaScript tests and scrolling tests that stress the display composition and hardware acceleration in the browser.
I saw an interesting deviation here between the AT&T and T-Mobile version, for reasons I cannot explain despite multiple reboots and making sure everything was closed. Either way, the devices both have stock browsers that feel like butter, absolutely smooth when translating or zooming around.
Low Level FP Performance
Linpack isn’t a great indication of overall smartphone performance, but it is a good test of the floating point capabilities of the CPUs in these SoCs. ARM has steadily been improving FP performance for the past few generations but we’re going to see a big jump to Krait/A15. As most client smartphone workloads are integer based and those that are FP heavy end up relying on the GPU, an advantage here doesn’t tell us much today (particularly because Linpack isn’t running native code but rather atop Dalvik) other than how speedy the FPUs are. There’s a new port of Linpack which runs using native code which we’ll be trying out in the big performance comparison piece.
As we’ve shown before, FP performance on Krait is superb thanks to its architectural advantages over a straight A9. I find that FP performance was more relevant of a benchmark when display rendering was being done in CPU instead of on the GPU with the new OpenGL ES 2.0 render paths. Still, it’s worth talking about.
BaseMark OS
Rightware’s BaseMark OS is a general purpose benchmark designed to better simulate overall Android performance. It includes a heavily threaded benchmark, file IO tests, and compression/decompression tasks that all contribute to its overall score.
Basemark OS is relatively new to us but we’re adding more and more phones as time goes on for comparison purposes. Curiously enough the SGS3s post numbers a bit shy of their HTC cousins. I think that in spite of this, you’d be hard pressed to tell the Krait based One X and Krait based SGS3 apart.
GPU Performance - GLBenchmark 2.1
As we wait for actual 3D gaming benchmarks to make their way into Android (and hopefully crossplatform) games, we must rely on synthetic tests designed to simulate 3D game performance as best as possible. We start with GLBenchmark, one of the better Android GPU tests on the market today. There are two benchmarks, Egypt and Pro, and each is run in two modes: native screen resolution and offscreen (vsync disabled) at 720p. The latter is more useful for apples to apples comparisons as everything is rendering the same number of pixels, whereas performance in the onscreen tests is determined by the screen resolution of the device along with the performance of its GPU.
As a reminder, only the Egypt offscreen test takes place with vsync turned off, which is why you see devices with 720p displays posting different results on versus off screen where vsync is off. Part of the deal in getting Krait to market as quickly as possible required that Qualcomm pair the CPU with an older GPU, in this case the Adreno 225 instead of the newer Adreno 3xx offerings due out later this year in SoCs like MSM8960 Pro or the quad core Krait APQ8064. As a result, you can see the SGS2 with Exynos 4210 pull ahead in both tests. Obviously the on-screen test isn’t a totally fair comparison because of the inherent difference in resolution - 720p vs WVGA.
In the older Pro offscreen test, we see Adreno 225 trading spots with SGS2’s Mali–400 and coming out on top.
Basemark ES 2.0 V1
Rightware’s Basemark ES 2.0 V1 is an aging GPU test that tends to favor Qualcomm’s Adreno GPUs above almost all others:
Basemark ES 2.0 is definitely starting to show its age, as Hoverjet is at vsync essentially the whole time, and Taiji is getting there as well. In addition, Qualcomm appears to be using ES 2.0 as an optimization target, so I wouldn’t put too much faith in the ES 2.0 results.
Facebook
Twitter
RSS
107 Comments
View All Comments
OCedHrt - Wednesday, June 20, 2012 - link
I wish we would get AWS on AT&T's S3 for WCDMA in addition to LTE.richworks - Wednesday, June 20, 2012 - link
Why isn't the International version of SGS3 not included in the benchmark tests? Am I to understand you haven't reviewed it yet?minhajmsd - Wednesday, June 20, 2012 - link
He did mention in the article that his unit hasn't arrived yet.richworks - Wednesday, June 20, 2012 - link
Ah.. thank you. I might have overlooked that part. I apologize for that :)antef - Wednesday, June 20, 2012 - link
Brian, you mention that by Samsung including a menu button that they don't have to include the full-row on-screen menu button that HTC does, but what you didn't mention is how this is still not ideal because it breaks Google's design goals for ICS completely. Google very plainly stated that the Menu key with its hidden functionalities (and sometimes no functionality) was not good design and encourages all developers to move away from it. Yet Samsung decides to include it on a new device built for ICS (probably because TouchWiz is carried over from Gingerbread).This means a few things. First, some app devs might not move to ICS design standards because they think they don't have to with new devices still coming out with Menu keys. Second, even if an app does use the new standards/action bar, the 3-dot overflow button will be HIDDEN because a Menu button is present. This is confusing and hides functionality that should be grouped with the other actions at the top. Finally, it necessitates a long-press of Home for task switching, which is slow and cumbersome compared to a dedicated button.
All around a bad decision on Samsung's part. The full-row menu key necessary for legacy apps on the One X is not ideal either, which is why on-screen buttons like on the Galaxy Nexus are the way to go.
Impulses - Wednesday, June 20, 2012 - link
I agree with you (and Google) on the menu button overall, it needs to go... I was never particularly bothered by it but it was a pretty sloppy design crutch and it confused new users of the platform... I agree that Samsung's implementation now only makes it worse by encouraging devs to continue using it and by messing with the way current ICS UI layouts are presented.I'm not sure I necessarily agree on screen buttons are better tho... IF you can make the device smaller by using them I'd say you have a case, but the Galaxy Nexus is no smaller than the One X so the latter ends up with more screen real estate the majority of the time (only sacrificing space to menu for legacy apps, which seems to be your main argument for on screen buttons).
I really hope Moto doesn't follow Samsung's lead, cause I believe LG has, and this is worse than the old game of musical chairs that manufacturers played with the four classic buttons. I think we've already had some leaks that showed them going with on screen buttons tho, fortunately.
It's gonna definitely gonna take longer than Google would like to deprecate menu...
hat being said, I've always liked Samsung's side power buttons (much easier to reach) so much do that I mod my HTC phones to wake on volume press... And I also kinda dig the physical home button (even tho it's ugly and another point of failure) because it makes it much easier to wake the phone while it's laying flat.
Most of that is subjective tho, Google moving away from menu is not... Not only was it a design crutch, multi tasking feels so much quicker without long press. I know realistically it's not that much slower to long press home, but subjectively it feels slow. I think Duartesaid in an interview that was one of the reasons they were moving away from long presses and towards the use of more swipes etc.
antef - Wednesday, June 20, 2012 - link
I definitely agree with you about Menu being a design crutch and long-pressing Home feeling slow. People might think Menu is no big deal, but they have to consider the broader audience. Why do people think an iPhone is so much easier to use for most people - because everything is right there and easy to explain. Try explaining Menu and long-press to a new user: "You press this button to show more actions - sometimes it will show things, sometimes it won't, you just have to press it and see. And there's no indication of whether an app uses it or not, you just have to remember it's there. And then you press and hold this to switch apps...no, you didn't press it long enough, try again." versus "Press this button to switch apps. Here at the top of the screen are icons for things you can do. If you there are more things you can do you can access them by pressing the 3-dot button right next to it." It's a night and day difference, and like you said this will stall Google's efforts to deprecate it, now a whole new generation of Android users will get accustomed to a Menu key on the SGS III.You are correct that the Galaxy Nexus loses some screen real estate with the on-screen buttons, but I don't see that being much of an issue when you have a 1280x720 resolution screen. The thing is, with 3 physical buttons, you are going to have one of these problems either way, and the on-screen button eliminates that. In addition I think the on-screen buttons are just preferable anyway. They are bold, easy to see, give you feedback when you press them, and appear coherently part of the UI. It looks like a complete package. Versus the off-screen, backlight-lit keys, which appear "separate" from the UI and are typically smaller. I never realized this from pictures, but after actually using a Galaxy Nexus, I much prefer the look and feel of the on-screen buttons.
Definitely also like the side power button, it's practically necessary for large devices like these.
themossie - Wednesday, June 20, 2012 - link
Yes, it does ignore Google's design goals. It also makes most applications far more usable. Why are contextual menus bad? (I understand the inconsistency problem where the menu button on ICS will not pop up on screen depending on the phone, but still...)Seems like many phone manufacturers agree with me here.
Since I'm complaining anyway... :-)
Does anyone else find ICS task switching far less useful than 2.x's "Recent Apps"? With "Recent Apps", I never had to scroll to find the app I wanted - and never had to worry about closing applications to keep the Task Switcher bar reasonably short.
(For reference, I have a Gingerbread phone and a ICS tablet)
Impulses - Wednesday, June 20, 2012 - link
Contextual menus aren't bad per se, forcing people to guess when they exist at all is. Very few applications are better off with a hidden menu than ICS' action bar + overflow menu plainly visible on screen. Many manufacturers = 2 out 5 or so major Android OEMs? Sony, HTC, and Motor have conformed to the new button scheme.Not sure why you're complaining about scrolling on ICS, are you using a 7" tablet? On my 10" the recent app menu shows 9 apps in portrait and 5 in landscape. Previous versions of Android showed either 6 or 8 icons depending on manufafturer, and had no preview of the app.
You couldn't kick apps out of the recent apps pop up either... ICS multi tasking seems like an improvement in every possible way except maybe landscape use or smaller lower res phones, and even then tap + swipe + tap is no slower than long press + tap.
themossie - Wednesday, June 20, 2012 - link
Re: Contextual menus - I do agree that it's bad to force people to guess when they exist. (That wasn't a problem before ICS, when you could safely assume a program has one!) I don't find the ICS icon to be a useful contextual clue to new users - 3 dots does not a menu suggest.Now, for scrolling: (forgive the rant)
That said, from memory:
* CM9 on HP Touchpad (1024x768) - shows 1 app in landscape.
* ICS on Galaxy Nexus - shows only 3 apps in portrait. (images.google "task switcher galaxy nexus")
* ICS on HTC Evo 4G - shows only 1 app in landscape. This may be a Sense issue, experienced other landscape issues.
You have to scroll to do anything!
Compare this with Gingerbread on my Droid 2 (the not-Motoblur), where "Recent Apps" shows 18 apps. With 18 apps in Recent Apps, I no longer need the homescreen to load applications.
I'd still find the stock "Recent Apps" (I believe it's 8 in Froyo, 10 in Gingerbread?) more usable than ICS.