The Bay Trail Preview: Intel Atom Z3770 Tested
by Anand Lal Shimpi & Brian Klug on September 11, 2013 12:00 PM ESTIn addition to showing Bay Trail running on a Windows 8.x platform, Intel showed us a “pre-beta” version of the platform running Android 4.2.2. I have to emphasize that the build they showed us definitely seemed pre-beta, as there was some instability, but overall the build was good enough to run some tests on and get a feel for. Intel made it clear that they do have a lot more work to do on their Android build before it’s considered close to final quality than the Windows equivalent.
Inside Android we can still see the CPU state table data and how long the cores are sitting in each performance state still, despite this now being managed in-silicon on Bay Trail. In addition Android sees the 2.39 GHz Z3770 boost frequency and reports it. I didn’t see any strange behavior on the device while running tests and watching CPU frequency, if anything the reference design platform stayed at the maximum boost frequency even with four cores plugged in for an impressive amount of time. Of course this is a tablet so there’s more TDP to play around with compared to a phone.
Depending on where you were in the Android UI, there was some definite stutter, but I’m told this is a result of an issue with Dalvik not allocating threads to cores properly that Intel is still tuning, something which you can see plays itself out as well in the AndEBench Java test that runs in Dalvik. The launcher especially had some stutter, but Intel claimed they were aware of it and that final performance in areas like that would be dramatically improved. Regardless of the state of Bay Trail’s Android port, it affords us the opportunity to look at performance through our pretty standard benchmark suite.
On the CPU side for Android we’re still limited to just a few tests that rely on a combination of native code and stuff that runs inside the browser. That means AndEBench, JavaScript benchmarks, and part of Vellamo.
Sunspider has been a regular staple but in recent time has become an exercise in browser JavaScript engine optimization rather than actual performance. Nevertheless the FFRD takes the crown in both 1.0 and 0.9.1 (we have more tablet data from the 0.9.1 version so I replicated it here).
Kraken is another JavaScript benchmark which hasn’t quite been an optimization target everyone has gone after lately, and it’s also longer, which makes it a bit more reliable. Once again Bay Trail takes the crown here with notably faster JS engine performance.
Google Octane is another JS test that isn’t quite as platform optimized yet, here there’s once again dominance by Bay Trail with just over a 50 percent higher score.
Browsermark has a combination of both JS tests and other web related performance metrics. Here the Bay Trail platform lags behind the 8974 based devices slightly. This isn’t a raw JavaScript benchmark again but rather a more holistic web browsing performance test, so it’s interesting to see Bay Trail a bit behind here.
AndEBench is a combination native compiled microkernel benchmark (indicative of NDK application performance) that also runs a very similar workload atop Dalvik like a normal Android Java application. Here we can see what Intel was talking about when they said they have more work to do getting Dalvik working properly at dispatching threads to appropriate cores, hopefully the Java number will climb considerably. The native test also shows a lead over the competition.
GPU Performance
While Bay Trail clearly leads on the CPU side, its GPU performance is more middle of the road - at least among the higher end SoCs. In 3DMark Bay Trail's GPU performance is aided by the more CPU bound nature of the benchmark, but here Intel is able to beat the Snapdragon 600. Snapdragon 800 on the other hand pulls ahead by around 35%.
The 3DMark Physics test is effectively a CPU test, which once again plays to Bay Trail's strengths. Here it's faster than Snapdragon 800 and Cortex A15. Only Ivy Bridge is quicker in a tablet.
Basemark X
Basemark X is a bit more GPU bound than 3DMark, and we also have iOS data here so we can put Bay Trail's performance in better perspective. Here Bay Trail is a bit slower than the iPad 4, and clearly Tegra 4 and Snapdragon 800. Intel's GPU in Android is measurably quicker than Adreno 320/S600 though.
Bay Trail's onscreen performance is penalized by the FFRD's extremely high native resolution.
GLBenchmark 2.7
The more interested GLBenchmark numbers, T-Rex HD, show Bay Trail just behind the iPad 4 in performance. It's definitely not bad at all but clearly not industry leading.
Facebook
Twitter
RSS
190 Comments
View All Comments
Nagorak - Wednesday, September 11, 2013 - link
Samsung already used the old Atom in their Galaxy Tab 3 10.1, and they make their own ARM licensed cores in-house. It's not going to take much to get these venders to switch. If the performance is there, and the price is competitive, plenty will make the switch. These OEMs design electronics as their business, it's not going to be a huge difficulty for them to make designs with Atom cores instead of ARM cores. And considering X86 works with both Windows and Android, I don't see why having a higher compatibility base is somehow a negative.Dentons - Wednesday, September 11, 2013 - link
Keep in mind that ARM allows mobile device manufacturers a large, competitive marketplace from which to purchase CPU's.Were tablet manufacturers to spurn ARM, they'd drop themselves right back into Intel's high-margin, nearly monopolistic arms.
So why have Samsung and Asus released Android devices featuring Intel CPUs? Both Samsung and Asus purchase a lot of expensive Intel chips for their laptops. It would be less than surprising were they to have been compensated with discounts for having released Intel powered Android devices.
Another huge problem for X86 Android is software support. Nearly all Android applications are compiled for the ARM instruction set. The hundreds of thousands of existing Android apps *WILL NOT RUN* on an Intel powered Android devices. At best, they need recompilation, at worst, rewriting. Moving hundreds of thousands of ARM compiled software to X86 is a heavy lift. Intel has a recompilation service, but it's only able to do so much.
The bottom line is that Intel is just now, finally releasing a CPU competitive with ARM. ARM has a massive lead. A larger lead than Intel has ever had in the PC market. To convince manufacturers to relinquish ARM for X86, Intel doesn't just need minimally better technology, they need far better technology and equal or better pricing.
Right now, Intel's technology is not that much better than ARM, and their pricing? Unless they decide to sell below cost, they'll likely never beat ARM pricing.
jwcalla - Wednesday, September 11, 2013 - link
I agree with much of this but I think you're a bit off on the Android applications aspect. A vast vast majority of the Android apps are written in Java so there's not incompatibility with x86 there. For the native apps, recompiling to x86 is somewhat trivial since Android is a Linux OS. Third, it seems that Intel's ARM-to-x86 ISA translation program works pretty well.h-jumbo - Thursday, September 12, 2013 - link
Yes - and to further correct Dentons comment on Android compatibility, Intel has a binary translator for Android that will convert ARM ISA to x86 on the fly. It works amazingly well. If x86 gets more traction in Android devices, it will be used less and less as app developers compile for x86 in addition to ARM (which is trivial).JPForums - Thursday, September 12, 2013 - link
Wow, you just talked about Intel killing off WinRT and then moved on to talking about a lack of applications for Windows. You can't have it both ways. Either legitimize WinRT as a competitor and bash it for a lack of applications or (more realistically) dismiss WinRT and accept that Windows has more applications, higher quality, and fully featured than any app store. Since when did a fully featured application become inferior to an app. How many (software) things can you do on a tablet that you can't do with a Windows PC or even OSX. Let's even throw Linux in their for kicks and grins.
Also consider that the biggest advantage of maintaining a process lead is cost. Yes a new process cost more than an old process, especially when applying new techniques like double masking and tri-gates, but the bulk of the cost is still in the silicon. The exact same chip fabricated on a smaller process generically means lower cost due to the ability to fit more chips per wafer. Intel maintains the highest margins in the industry because they also maintain the lowest cost per comparable chip. I'd imagine that Intel will give these chips a price tag to match (or slightly exceed) their level of performance compared to their ARM competition. Unfortunately, as you said, simply being competitive isn't enough to justify a rapid switch over of an ARM dominated market. They are going to need to offer something the their competitors don't have or eat significantly into their margins. That said, they will get some design wins simply by being competitive and being Intel. Pickup into the Windows market will help as manufacturers could conceivably use the exact same or very similar hardware to power both a Windows and an Android tablet, saving cost. This could fuel a slow long term takeover, but like you, I don't see a sudden switch.
lmcd - Wednesday, September 11, 2013 - link
So in that whole power comparison versus Jaguar where was the graphics disclaimer? I think the pounding seen here easily warrants the TDP difference.eanazag - Wednesday, September 11, 2013 - link
The 3DMark extreme bench scores look suspect. I think the graphs are swapped.Clearly AMD's graphics in Kabini smoke Intel's products and many other non-IvyBridge GPUs. I wonder how much of a power hit did Kabini take to produce that. Meaning, would a comparable performing GPU to Intel's make the power to performance ratio be more favorable at maybe 3.5W max under load? I am not thinking if Kabini was cut down on the GPU to even Bay Trail that it would beat Intel's power consumption. I suspect it would be closer.
I am irritated they don't just call it Atom on desktop and laptop. Clearly trying to get out of the netbook Atom stigma. Whatever. Ultimately, I am still disappointed that Atom doesn't do enough on the GPU side. It still leaves me as a consumer having to make a choice between graphics intensive and CPU intensive workloads. And the fact AMD's Kabini is even close on CPU performance is a weak showing because Intel has a mature process node advantage on virtually everyone now.
PEJUman - Wednesday, September 11, 2013 - link
more improtantly, can someone explain how Anand was able to run android with x86 kabini and x86 ivy bridge on the android GPU bench? since when can x86 processors run ARM natively? if not, did Intel actually let Anand use their android pre-beta port at the other 2 platforms?Jaybus - Wednesday, September 11, 2013 - link
Android has run on x86 for a long time. Android is Linux-based.PEJUman - Wednesday, September 11, 2013 - link
yeah but I was under the impression it uses VM and an custom build on that. Anand was able to run GPU bench (I assumed this meant native x86 build), with 4.2.2 build at that. Isn't android is built for ARM only?