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

  • vol7ron - Wednesday, April 25, 2012 - link

    I doubt windows would expect PCI channels lol. Though, it might need drivers to operate.

    Everything you need is on the phone for windows to operate (Screen, CPU, Video, RAM and Disk space) exists, even though Windows doesn't require it all. Though, Windows does need some way to communicate with those devices (device drivers), which Win7/etc probably doesn't have.
    Reply
  • Shadowmaster625 - Wednesday, April 25, 2012 - link

    A few years from now it is likely I might be able to acquire one of these for dirt cheap. (Broken screen, etc) I would use it just for an ultra low power ultra low profile *single-function* pc. I would very much like to know if this hardware can run windows 7. It doesnt need to run well, it just needs to be able to go on the web and do basic things similar to an atom nettop. Reply
  • superPC - Wednesday, April 25, 2012 - link

    it won't run windows 7. unlike windows 8, windows 7 requires standard RAM not LPDDR. windows 7 also requires some form of PCI. Reply
  • Musafir_86 - Wednesday, April 25, 2012 - link

    -Excuse me, but IMHO, the type of physical RAM shouldn't matter. If not, we couldn't be able to load these OSes on VMs at all. :)

    Regards.
    Reply
  • B3an - Thursday, April 26, 2012 - link

    Why would you even want to run Win 7 on this when Win 8 would clearly be WAY better suited, not to mention it also uses less resources and RAM while remaining faster/snappier than 7. Reply
  • rahvin - Friday, April 27, 2012 - link

    I'd imagine he wants to know because Windows 8 is going to be only slightly less successful than Vista. Personally I'd guess around 5% of the Vista sales. It's a disaster in waiting unless they make dramatic last minute changes. You should try using it. Reply
  • joshv - Wednesday, April 25, 2012 - link

    I am not sure why this chipset matters. Intel usually wins on x86 compatibility with older software. In the phone space there is no existing x86 code, and in fact they are stuck emulating another ABI - so they will be slower and less efficient that competitors that implement that ABI natively.

    That leaves Intel to compete on price/performance alone in a market where their competitors have 99.9% of the market. An odd position for Intel.

    Perhaps this makes more sense in a Windows 8 tablet?
    Reply
  • Impulses - Wednesday, April 25, 2012 - link

    Its netbooks all over again, on a much bigger scale. ARM is moving upscale, if Intel doesn't start competing directly they will eventually start ceding some existing market share (when tablets/laptops start to overlap more, and the writing's on the wall with Windows for ARM).

    Only difference is they're up against a capable rival(s) as opposed to a limping AMD, so they can't just come out of the gate strong and them dog it and let the lower end market stagnate in order to maintain profits.

    This is a small first step but it'll allow them to ink more deals and possibly cement a strong foundation for upcoming Win8 ARM tablets which is probably their bigger long term concern.
    Reply
  • dcollins - Wednesday, April 25, 2012 - link

    Did you even read the article?

    The x86 vs ARM issue is mostly a non-issue that will be completely resolved within a few months. Dalvik apps are JIT compiled to ARM and x86 and will perform similarly. In fact Intel might have an advantage here because they have the best compiler engineers in the world with decades of experience in generating high performance x86 code. NDK apps will generally be supported natively; developers only have to check a box to include x86 binaries. Even Apps that aren't compiled with x86 support are translated prior to installation on the users device. Nothing about the instruction set makes Medfield slower than ARM.

    Performance today is comparable to modern ARM processors even when running an out of date, slower OS. Performance in 4.0.x should match or outperform even Krait. Graphics performance is middle of the road, but that's a major concern for many smartphone buyers (myself included). Even in benchmarks that purposefully stress mutliple cores, Medfield holds its own against the many cored competitors. Real world usage is more lightly threaded.

    Browser performance is the most important metric for my usage and here Intel performs extremely well. If Medfield is available in a 4.x phone when it comes time for me to upgrade, I will seriously consider it versus a Krait based offering. Now imagine a next generation Atom build on 22nm with dual core, hyperthreading and possibly OoO execution: that chip will eat A15s for breakfast.
    Reply
  • dcollins - Wednesday, April 25, 2012 - link

    edit: "Graphics performances... is NOT a major concern" Reply

Log in

Don't have an account? Sign up now