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
PEJUman - Wednesday, September 11, 2013 - link
NVM, some googling answers my question. Cool.. I learn something today.Kidster3001 - Thursday, September 12, 2013 - link
All of Android runs in a VM. Every Android device in the world. Apps can call native routines via JNI and some apps do contain native *.so libraries (for multiple ISA's) but in the end, Android is a VM. Your UI, your system apps, everything runs through Dalvik.The difference between Atom devices and ARM devices is that Intel has included a binary translator to convert the ARM *.so to x86 code on-the-fly. If there are no x86 .so included in the app then the x86 device will use the ARM-v7a library via the translator.
It is very easy for app developers to compile their libraries natively if they choose. Most apps have NO native libraries in them, they're all Java. When compiling a native app, just tell the system which ISAs to compile for. Of those apps which do have native components most compile for ARM, ARM-v7a and MIPS. Flicking another switch to also compile for x86 is not that difficult.
monstercameron - Friday, September 13, 2013 - link
kabini android, nope those are most likely the windows results.lmcd - Wednesday, September 11, 2013 - link
Yeah, I imagine or at least hope Kabini + HPL process is on the queue. That would make Intel work a bit harder.Nagorak - Wednesday, September 11, 2013 - link
It wouldn't be anywhere close. AMD doesn't have Intel's process advantage. If AMD could get power down by just cutting GPU performance then they probably would have done so. In a tablet power consumption is pretty damn important.In fact, more so than these load tests, idle power consumption is probably the key, and that wasn't fully tested at this point.
andrewaggb - Wednesday, September 11, 2013 - link
I kinda expected more. It should make for a decent windows 8 tablet, but given that the new iphone has 2x cpu/gpu I think it's pretty safe to say the next ipad will destroy this thing graphically.Intel needs to become a graphics leader now.... not in 2-5 years.
kyuu - Wednesday, September 11, 2013 - link
Obviously the proper comparison here would be with Temash, since that's AMD's tablet SoC. Kabini isn't meant to compete with Bay Trail in power consumption, so it's pretty far from a surprise that it draws more power.I'm guessing the results would be pretty much the same: Bay Trail beats Temash slightly in CPU benches, but still gets soundly thrashed in GPU benches.
Also, don't the current Kabini SKUs lack AMD's equivalent of turbo boosting? I thought I saw that on the Kabini review article...
silverblue - Wednesday, September 11, 2013 - link
The comparison with Kabini is an interesting one. Kabini supports more instruction sets (Bay Trail is Westmere-level which means it lacks AVX) but it has a single memory channel and lacks any form of turbo. Amusingly though, Kabini is practically on-par here in terms of single threading (per clock) but is being hampered a little in multi-threading if 7-Zip is any indication (memory bandwidth?).Add in turbo to Kabini and the Bay Trail advantage in single-threading disappears, but power usage is obviously higher. AMD have their work cut out here; Beema (and HSA) can't come soon enough.
I think AMD's yearly cadence will help here - Beema has HSA plus GCN2.0 at the very least on a more mature 28nm process - however AMD will still be on 28nm when Intel goes 14nm. Still, if HSA is the be-all-and-end-all that we've been told it is, they have hope.
The 4600M is embarrassed in CineBench; clock either SoC at 2GHz and they'll equal it for far less power. CineBench is very Intel-friendly, though the same trick in 7-Zip's multi-threaded test would result in the same outcome. Proof indeed that Kaveri is needed.
zeo - Wednesday, September 11, 2013 - link
Kabini has Turbo, only the two dual core Temash models drops it... and Bay Trail has its alternative to Turbo Boost that's called Burst technology...And HSA requires industry support... they need to make it a standard, which is why they started up the HSA Foundation, but until that happens then it's only a novelty like Nvidia's CUDA, and right now it's mainly just ARM backing them there so far...
silverblue - Thursday, September 12, 2013 - link
The only Jaguar-based chip (outside of consoles) with any turbo functionality (note I'm typing "turbo" in lower case as I'm referring to the basic technology and not a specific implementation) is, at this time, the A6-1450, which is a Temash chip. In addition, without the turbo dock, it cannot actually achieve its turbo frequencies.As regards HSA, here's something quoted from the AMD website:
"The founding members of HSA are: AMD, ARM, Imagination Technologies, MediaTek, Texas Instruments, Samsung Electronics and Qualcomm®."
Consider that ARM is what generally binds most of these together, and their huge dominance of the smartphone and tablet market, and you can easily see that HSA isn't just another "novelty like Nvidia's CUDA".
http://developer.amd.com/resources/heterogeneous-c...