At Brian Klug's recommendation, I ran the Xperia Play through a battery of common benchmarking tests. Below you'll find the alphabetically ordered results, in comparison to similar-featured and similar-age Android handsets from other suppliers:

Basemark (aka 3DMarkMobile) ES 2.0 V1

RightWare Basemark ES 2.0 V1 - Hoverjet

RightWare Basemark ES 2.0 V1 - Taiji

BrowserMark

Rightware BrowserMark

GLBenchmark 2.0 ('Standard' results in both cases)

GLBenchmark 2.0 - Egypt

GLBenchmark 2.0 - PRO

kwaak3 aka Quake 3 (note that this particular test was run with lightmaps off, per longstanding AnandTech practice)

Quake 3

Linpack

Linpack - Single-threaded

Linpack - Multi-threaded

And SunSpider 0.9

SunSpider Javascript Benchmark 0.9

The results are largely predictable, but some encouraging surprises also emerged. Performance differences between platforms based on the first-generation 65 nm-based QSD8x50 (aka S1-class SoC) and second-generation 45 nm-based MSM8x50 SoCs predominantly derive from two factors, since the processor cores are fundamentally the same save for the process they're built on:

·       Clock speed differences (800 MHz versus 1 GHz, for example), and

·       Graphics core differences (Adreno 200 with the QSD8x50, Adreno 205 with the MSM8x55)

Slight variances between similarly clocked systems in CPU-centric benchmarks are likely the result of benchmark run-to-run differences, coupled with minor evolutionary Dalvik virtual machine enhancements in successive Android versions. Perhaps the most significant Dalvik improvement came with the transition to Android 2.2 'Froyo', which added a JIT (just-in-time) compiler to the mix with a resultant claimed 2x–5x performance boost with CPU-heavy code. The Xperia Play still notably outperforms its fellow MSM8x55- and Adreno 205-based peers on graphics-heavy benchmarks. This result surprised me, until Brian Klug explained that the Xperia Play represented one of the first production systems containing improved graphics drivers from Qualcomm.

Unlike with a PC, where you can regularly install updated drivers from AMD, Intel or Nvidia, with a handset you need to rely on Google and its hardware and carrier partners to bundle the updated drivers with an operating system upgrade for your hardware...or in this particular case, for an OEM like Sony Ericsson to include them from the get-go. Note, for example, the frame rate improvements of the Xperia Play on Basemark ES 2.0's 'Taiji' and Hoverjet tests, versus the seemingly identical (at least from CPU and GPU standpoints) HTC Thunderbolt. Similarly, the Xperia Play had notably higher frame rates in the Quake 3-based kwaak3 test, versus the Thunderbolt.

One other result was also intriguing, until I thought about it for a bit. Linpack recently added a multi-threaded benchmark option, so I decided to run both it and the legacy single-threaded test. The multi-threaded MFLOPs (millions of floating-point operations per second) was lower than that for the single-threaded test variant; consider, however, that the MSM8x55 is a single-core CPU. I believe that the decrease is the result of multi-thread management thread-switching latency overhead, in spite of the Cortex-A8 superscalar dual-issue microarchecture foundation upon which Qualcomm built its Scorpion approach. Conversely, if you look at the Linpack data for a system such as the HTC Sensation 4G, based on a true dual-core CPU such as Qualcomm's MSM8x60 (S3-class SoC), you'll see dramatically higher multi-threaded Linpack results in comparison to those for the traditional single-threaded test.

FYI I also tested the Xperia Play using Qualcomm's recently introduced Vellamo benchmarking suite, but AnandTech isn't quite ready yet to start publishing Vellamo results. Stay tuned for more in this regard. Similarly, I ran the Xperia Play through the newer SunSpider 0.9.1, whose results we'll start publishing once we have a sufficient-sized system sample set.

Bill Of Materials User Interface, And Update Frustrations
Comments Locked

34 Comments

View All Comments

  • RoninX - Wednesday, August 10, 2011 - link

    Maybe they should just release a 3G/4G version of the Vita that makes calls.

    Then you would get by far the best portable gaming experience without having to carry two devices.
  • SimKill - Wednesday, August 10, 2011 - link

    But then battery life would go to the dogs.
  • etobare - Monday, August 8, 2011 - link

    There you make it sound as if xperia play didn't have access to android non-xperia play optimized games... i concur with much of the review but that may lead to confusion
  • Mike1111 - Monday, August 8, 2011 - link

    A gaming smartphone with fewer, more expensive and worse looking games compared to iOS devices? Why even bother. It's a niche market at best. To have a chance in the mainstream market the successor must have PS Vita-like hardware, graphics and kick-ass games. And should Apple ever decide to make an adequate Bluetooth profile available for (analog) gamepads then the dedicated gaming smartphone market is dead anyway.
  • lowlymarine - Monday, August 8, 2011 - link

    I just finished a run of BrowserMark on my Captivate (AT&T Galaxy S) and got a score of over 71,000. Admittedly I'm running at a fairly modest overclock of 1.2 GHz, but unless each one of those 200 MHz are imbued with pure magic, there's no way the likes of the Droid 3 and the Atrix should be doing worse. Similar with Sunspider - my 3193ms result (yes, on 0.9) beats out even the fastest device you've tested. I'm not using Firefox Mobile or something either; this is all with the stock AOSP browser.

    I'm just curious as to why there's the massive discrepancy in browser performance. My Linpack scores are, while still nearly 3 times what you've got for the SGS (largely attributable to the difference between Gingerbread and Eclair, I'm sure), no where near those of the dual-core powerhouses. I know the second core won't really help them on Sunspider et al., but certainly it shouldn't be hurting them?
  • Death666Angel - Monday, August 8, 2011 - link

    Are you using other/newer kernels and roms? They usually add nice boosts to those benchmarks by either having better drivers, better optimizations or just fewer active programs. :-)
  • Vepsa - Monday, August 8, 2011 - link

    I considered getting a Xperia Play, but I decided against since I kinda like having more than 512MB of RAM on my phone. The bulk doesn't bother me and nor does the SoC since I have the same one in my Droid Incredible 2. If the phone had had 1GB of RAM & 2GB+ of app storage I would have probably gotten it. The only thing that will get more games made for them is if more are sold since its an open API.
  • StormyParis - Monday, August 8, 2011 - link

    Did someone just receive a new digital camera ? Is there an epidemic of photographic logorrhea I'm not aware of ? Are Ars writers paid a lot more for each picture ? Or is it about the page views ?

    One could easily cut half the pictures in the article (first page), redo some (you can put 3 phones in a single picture for comparison, yessir....).

    This article is giving me a feeling akin to PCmag's infamous "slideshows"
  • Anand Lal Shimpi - Monday, August 8, 2011 - link

    Fixed :)

    We have no internal mandates for picture or page count, sometimes it's easier just to string a bunch of images together rather than toss them in a gallery but I've done the latter here at your request :)

    Take care,
    Anand
  • StormyParis - Monday, August 8, 2011 - link

    Thanks. Am I the only one bothered when there are so many pics in an article ? because, frankly, the numerous screenshots and charts on the following pages also bother me. With Anandtech's already narrow, heavily paginated format, there's lots of scrolling involved already... I find more than 1 pic/page a pain, except when the pics are *really* needed... which they are not, for example, to report a *one-number* test result. It gets even worse when reading the article on my phone or tablet.

    Personally, I simply jumped to the conclusion after a few pages. I find the galleries you put in the first coupl of pages the best trade off: really motivated readers can see all the pictures, the rest of us can read the article without kilometers of scrolling. <ripoff source="Arrested Development ">It's a nice way to satisfy the "buy" crowd and the "curious" crowd, and we're all buy/curious </ripoff>

Log in

Don't have an account? Sign up now