We’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:

SunSpider Javascript Benchmark 0.9.1 - Stock Browser

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.

BrowserMark

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.

Vellamo Overall Score

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.

Linpack - Single-threaded
Linpack - Multi-threaded

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 Performance

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.

GLBenchmark 2.1 - Egypt
GLBenchmark 2.1 - Egypt - Offscreen (720p)

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.

GLBenchmark 2.1 - Pro
GLBenchmark 2.1 - Pro - Offscreen (720p)

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:

RightWare Basemark ES 2.0 V1 - Taiji
RightWare Basemark ES 2.0 V1 - Hoverjet

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.

Battery Life Camera - Stills
POST A COMMENT

107 Comments

View All Comments

  • antef - Wednesday, June 20, 2012 - link

    I don't believe "context menu" is the right term here. We're not discussing context menus - that would be something related to your *exact* context, such as long-pressing a row in a list and getting some options. What we're discussing is the app's "primary" menu that holds whatever could not fit on the main UI surface. In that sense, both the legacy menu and the action bar "overflow" are going to hold similar things, so what they contain is not really an item of debate. The main problem with the fixed Menu key, as Impulses said, is that it's "hidden" - since it's always present, there is really no indication that an app needs it or not, and it's also off-screen and thus doesn't feel cohesively tied to the rest of the app's UI. Action overflow, meanwhile, only appears when needed and right alongside other related functions.

    HTC switched to the new layout but unfortunately their use of physical buttons necessitates the nasty "full row menu button" for legacy apps. And I bet you that Samsung only stuck with the Menu key because they were too lazy to rethink parts of TouchWiz's UI - it clearly is a carryover from Gingerbread and they've shown before they don't put a lot of polish into their software. In that sense, this device is just stuck with that button because Samsung did not try to design a better user experience, not because they genuinely think this is the better way to go.
    Reply
  • themossie - Thursday, June 21, 2012 - link

    I understand what you mean, and "primary" menu is definitely a better term! However, the "action overflow" on-screen button which Google wants to replace the older "primary" menu (menu button) is not an improvement.

    "Action Overflow" is not intended to be an actual settings menu. With "Action Overflow", Google basically says "Hey guys, you don't need 'settings' any more - just 'buttons you won't press that often." They then allow developers to put the action bar in 3 different places (http://developer.android.com/design/patterns/actio... so there's no longer consistent button placement.

    The biggest problem with the menu button (for new users) was the lack of contextual cues. ICS ironically manages to fix this even as it deprecates the menu.

    At this point, I'm way outside the scope of a phone review's comment sections, so I'll leave some food for though (discussion, not favoring a particular approach)
    http://www.reddit.com/r/Android/comments/uda99/dea...
    http://stackoverflow.com/questions/9286822/how-to-...
    Reply
  • antef - Thursday, June 21, 2012 - link

    Action Overflow is not intended to be an actual settings menu, but neither is legacy menu! it was never intended as a "settings" or "options" menu...literally just a menu to put anything you want. In this sense Action Overflow is exactly the same, only commonly used items don't have to be in the menu and instead can be directly on the action bar. It completely fixes the discoverability issue since the 3-dots are right there next to other icons you're already using. It leads you to it and it appears part of the app's UI.

    Thanks for the links. :)
    Reply
  • synaesthetic - Wednesday, June 20, 2012 - link

    Google was smoking crack when they got rid of the menu button. I installed a custom ROM onto my Nexus to make the menu button come back.

    I have never used a real serious app that didn't have a contextual menu. Never. And the "ICS friendly" apps that use the dotdotdot in-app menu like to put them in really obnoxious places... like the TOP OF THE SCREEN.

    Holy carp Google, this phone is already huge, you want me to drop it trying to hit that menu key with my thumb?

    The SGS3 having a menu button makes me want it EVEN MORE.
    Reply
  • antef - Thursday, June 21, 2012 - link

    I do have to tilt my Nexus forward a bit to reach up there with my thumb, but this is no different than having to reach up there for anything else, including the main action icons which are going to be up there no matter what.

    It is true that most apps used legacy menu, but still, nothing has to. That makes the very idea of an always present button silly. The nav bar should stick to system-wide navigation as it does on the Nexus and leave things pertaining to an app to be on the app's UI surface. The OP of the Stack Overflow link said it best:

    "This [the overflow button] seems much more intuitive for users than throwing them into a separate menu list that requires the user to jump from a touch(screen) interaction to a button based interaction simply because the layout of the ActionBar can't fit them on the bar."

    What he's saying is the on-screen controls and off-screen controls are different UI "sections" that shouldn't intermingle during the course of using an app. An app's controls should all be available within the app's UI. It's more cohesive and straightforward. In practice, it only ever really appears in the top right or bottom right, and most of the time the top right. It's not jumping all over from app to app like some people like to suggest.
    Reply
  • 8er - Friday, June 22, 2012 - link

    Menu button is good.

    Physical home button, even better. It is huge selling point for me.

    Side bar. I do not comprehend how anyone can say 'insert button name here' is bad. It looks like a search button and it searches or a menu buttons bring up menus, or a home buttons brings you home, and someone is confused?

    If the above is true then that person is helpless. I will not apologize for sounding crass, but that person gets left behind. You are not left starving on an island kind of crass. If you do not understand what selecting an icon might do then a smart phone is too much for you.
    Reply
  • robinthakur - Friday, June 22, 2012 - link

    Yes, this totallyl! Coming from an iPhone, the long press to access multitasking is really slow and rubbish, I wasn't sure whether this is the same across all Android handsets. It doesn't help that on iOS, the commands are flipped and long press is Siri with double tap or four finger upwards swipe being multitask! The use of the Menu button seems haphazard as it isn't obvious which apps use it (or even which parts of the apps) and which ones don't. Reply
  • THX - Wednesday, June 20, 2012 - link

    Folks on Head Fi are worried that the S4 chipset will strip out the Wolfson DAC. Any word what sound chip is inside the US Galaxy S3? Reply
  • Impulses - Wednesday, June 20, 2012 - link

    Does the international version still have a Wolfson DAC? I know the SGS2 and many Tegra 2 devices did, haven't really kept up with that aspect of phones but I know a lot of people really liked that DAC because of the untapped potential in it (and the Voodoo app that it). Have they found anything particularly alarming about the One X's DAC or sound tho? (gimmicky Beats EQ aside) HF to ride their FOtM choices pretty hard and in the process anything else is deemed simply incomparable. Reply
  • Impulses - Wednesday, June 20, 2012 - link

    that should've read "HF tends to ride" Reply

Log in

Don't have an account? Sign up now