Javascript Performance

Although smartphones are clearly headed for a life beyond simple messaging, web browsing and phone duties, we are still lacking the tools to measure performance in areas other than a component of web page rendering. 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 is quite possibly the most well known of these javascript tests, and it also happens to be one that runs extremely well on Medfield:

SunSpider Javascript Benchmark 0.9.1 - Stock Browser

The Lava phone is just a tad faster than the FFRD we tested at the beginning of the year, which may not sound like much but is positive given that Mike Bell was very confident that all Intel FFRD phones would deliver the same level of performance. The X900 ends up being the fastest smartphone we've ever tested here. Intel won't be able to claim that title in any other benchmark here today but it's an impressive feat for just now showing up to the game. It's also worth pointing out that Intel is able to do this well running on Gingerbread, while its closest competition are running on Ice Cream Sandwich with far improved JS performance built into the browser.

Why is Medfield so much faster here? It's tough to say, but likely a combination of reasons. Google's V8 engine has had a ton of optimization work done around x86 to begin with. By virtue of nearly every computing platform that runs a Google browser outside of Android being x86, it's natural that some of those optimizations are going to transition over into Android for x86 as well. That's actually a part of a much larger advantage Intel has should x86 take off in the smartphone space.

On a more technical hardware level, Intel claims its cache and memory interfaces are simply better than the competition here - which in turn results in a significant performance jump in Sunspider.

BrowserMark is another js benchmark in our suite, but here the advantage has been reduced to simply competitive with the fastest phones in our labs:

BrowserMark

For a single Atom core running Gingerbread, Medfield does very well here - roughly equaling the performance of NVIDIA's Tegra 3 (HTC One X) and Qualcomm's Snapdragon S4 (HTC One S). It's quite possible that when running ICS Medfield will once again step ahead of the competition, but even if this is as good as it gets it's a good start. Keep in mind that we're looking at a 4 year old microprocessor architecture running on a n - 1 process from Intel.

Low Level FP Performance

Linpack isn't a great indication of 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:

Linpack - Single-threaded

Single threaded FP performance is very good on Medfield as you'd expect, but a bit lower than Qualcomm's Snapdragon S4. As Krait is a wider, out-of-order architecture with a fairly reasonable FPU the 13% advantage here isn't too surprising. Compared to anything A9 based however, Medfield is obviously quicker.

Linpack, like many scientific workloads, scales up to multiple cores quite nicely. If we spawn as many threads as there are logical cores (2 for Intel and Qualcomm, but 4 for NVIDIA's Tegra 3) we can see how Intel's single-core Atom fares in a multithreaded world:

Linpack - Multi-threaded

There's roughly no change in Medfield's performance here, which will be an issue for any compute heavy, very threaded application. Luckily for Intel, not many of these types of applications exist on smartphones today, but it is a limitation of this first generation Medfield. Hyper Threading is a great way to increase CPU utilization power efficiently, but for some workloads there's no replacement for more cores. Snapdragon S4 does extremely well here in the HTC One S by being a combination of two cores and having a much faster FPU.

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. We only have results from the HTC One S (Snapdragon S4), One X (Tegra 3), Galaxy Nexus (OMAP 4) and the Lava phone (Medfield) here:

BaseMark OS Performance

At least in BaseMark OS, Intel's performance is distinctly modern although not at the head of the class. Differences in performance here extend beyond the SoC and are obviously influenced by things like NAND selection as well as the OS on the device. For many of these benchmarks I'm very curious to see how they change with the arrival of Ice Cream Sandwich.

Vellamo

Vellamo is a Qualcomm developed benchmark that focuses primarily on browser performance, both in rendering and UI speed. The results are heavily influenced by the browser used on the device being tested. As a whole Vellamo isn't always indicative of whether or not you're going to get a smooth browsing experience, but it's another datapoint that captures more than just javascript performance. The Qualcomm-developed nature of the benchmark is always cause for concern, but even if you exclude the Snapdragon results the benchmark can be useful:

Vellamo Overall Score

Once again we have a good showing from Intel. The X900 and its Medfield soul aren't the fastest, but Intel's first smartphone is in the top three and faster than almost everything that came before it. Much of the advantage here actually comes from the Google V8 benchmark, another js test, which we've already established Intel can do quite well in.

Flash Rendering Performance

These days nearly all high-end smartphones (I refuse to call them superphones) can render Flash smoothly. Thankfully Intel's platform is no exception as the X900 delivers a competitive showing in our Flash benchmark:

CraftyMindFlash Rendering Performance

Android on x86 and Binary Translation GPU Performance
POST A COMMENT

106 Comments

View All Comments

  • kyuu - Wednesday, April 25, 2012 - link

    I dunno what review you all were reading, but I didn't see average performance. I saw it pretty much beating everything else save the HTC One S/X with only a single-core and running an old version of Android. Wth ICS, it'd probably be at the top easily.

    Sure, ARM isn't sitting still, but is Intel. I have no desire to see Intel overtake the market, but I can easily see Intel being the performance king by a good margin in the mobile SoC market when they release their next SoC.

    Also, for people saying cost is a factor... do you have any source to back up the claim that Intel's SoC is significantly more costly? All I see are assumptions.
    Reply
  • kyuu - Wednesday, April 25, 2012 - link

    That's "neither is Intel" in the second paragraph, first sentence. Reply
  • UpSpin - Thursday, April 26, 2012 - link

    SunSpider and Browsermark results are that good because of software tweaks done by Intel. Intel tweaked a lot in software, thus I doubt that ICS will improve anything further.

    Linpack single threaded, that's the most important benchmark to compare raw processing power without software tweaks. It shows that Medifield is faster than ARM A9, a good sign, but slower than Krait and thus all soon to get released A15 cores, a bad sign.
    Linpack multi threaded shows that Medfield has not the slightest chance vs. Krait and ARM A15, most of them will be dual core SoCs, but even if they get produced in single core varients they will be faster (Linpack single threaded). Medifield also gets beaten by Quad Core A9 chips (all new high end smartphones pack either a Quad Core A9, or dual Core krait/A15). Medfield is at best, as fast as a dual core A9 (raw processing power).

    Then take a look at the GPU: Poor performance for todays standards. Slower than the SGSII, slightly faster than the Galaxy Nexus, which has a slow GPU, too.

    Power consumption: poor to average. (sadly we don't have numbers for Krait or Tegra 3 (HTC One X/S)

    The SoC is not bad at all, but its release date is one year too late. This year is the year of Krait and A15, which beat Medfield in single threaded applications and are at least dual cores, so more than twice as fast. The integrated GPU is pretty weak, too, especially if you consider that this years ARM SoCs have a much better GPU.

    Additionally x86, the advantage is huge software tweaks thanks to Intel, the disadvantage, custom skins/apps/features made by third party manufacturers won't run that easily.
    Reply
  • Exophase - Friday, April 27, 2012 - link

    Intel doesn't tweak Sunspider or Browsermark. But Javascript JIT performance is probably much better on x86 than ARM right now because it got a ton of attention on PCs from all major browser vendors, starting with the release of Chrome. And there's at least one major ARM improvement (EABI hardfloat) that's in V8 but didn't make it into official Android yet.

    Browsermark is only partially Javascript, but the other part (HTML5 rendering) is really lame too. Run it and you'll see what I mean, I hope.

    Linpack is also a lousy benchmark. Any serious vector FP code on a phone (like matrix stuff for a game) would use SIMD with compiler intrinsics or ASM, and probably single precision over double precision. But even as a Dalvik double precision floating point test it sucks because it's not tiled and therefore heavily bandwidth limited.

    Basically, most of the benchmarks used are awful.
    Reply
  • clockerspiel - Wednesday, April 25, 2012 - link

    The cell phone industry desparately needs a "flagship" representative for the Android ecosystem - and this ain't it! Reply
  • jjj - Wednesday, April 25, 2012 - link

    You can't normalize battery life unless you factor in the screen size since the screen uses a lot of power and the handset's volume is directly related to the screen size and battery size.
    By normalizing you are making things worse than better.If you can't measure the power consumption for just the SoC you might as well just provide the system's battery life since,in the end, that's what matters anyway.
    It is what it is,you can't take out the screen or the RAM or the NAND but that's no reason to make things worse with tests that distort the reality instead of helping.
    Reply
  • menting - Wednesday, April 25, 2012 - link

    uhh, it's not measuring the power consumption for the SoC, it's measuring the whole phone's power usage. So in this case, normalizing IS a valid way to go about this. Reply
  • plamengv - Wednesday, April 25, 2012 - link

    It is beyond me why Intel will market x86 CPU with OS that has nothing to do with x86. The people who want Android will always go with the better looking and cheaper device. Something that this device is not. The other with knowledge will go for iPhone because there is no other alternative. Windows Phone is from professional point of view worse than Windows Mobile 6.5 and lacks lot of features. Intel had to bet on Windows 7 turning the smartphones into UMPC. Imagine Viliv S5 shrinked to Galaxy Note but running Windows 7! Well maybe Haswell and 22nm will finally make it. Reply
  • menting - Wednesday, April 25, 2012 - link

    android was built from Linux..tell me where Linux has nothing to do with x86. And with future android versions including x86 compiles by default., x86 or not isn't an issue.

    The X900 is a reference design, who says other companies can't put a different external case on it? And where's proof that it will be more expensive?
    Reply
  • superPC - Thursday, April 26, 2012 - link

    why windows 7? windows 8 would be a lot better suited for something similar with this phone (with compatible GPU). Reply

Log in

Don't have an account? Sign up now