The Bay Trail Preview: Intel Atom Z3770 Tested
by Anand Lal Shimpi & Brian Klug on September 11, 2013 12:00 PM ESTOur Windows performance analysis takes place on Intel's Bay Trail Form Factor Reference Design. The 10-inch tablet features a 2560 x 1440 display, 2GB of LPDDR3-1067 memory and a 64GB eMMC solution. The platform was running Windows 8.1 (32-bit).
Intel left me to install and run anything I wanted to during a period of a few hours at their campus in Santa Clara. I got a feel for the speed and snappiness of Bay Trail during my benchmark setup/installation process. While I don't believe Clover Trail was really usable in Windows 8's desktop mode (it was just too slow), the same is definitely not true for Bay Trail. With the exception of a few benchmark installs or loads that simply took forever, my Bay Trail experience was really quite good under Windows. Bay Trail is obviously not as fast as Haswell when it comes to general usage, but it's definitely worthy of a discussion. Whether or not it actually is good enough for an entry level machine will depend on how OEMs choose to configure their Bay Trail systems. I'll hold off on a final verdict here until we have some time with final Bay Trail devices and not just FFRDs.
Intel already teased the Atom Z3770's multithreaded Cinebench performance, but what about single threaded performance? Remember that single threaded performance is often a signfiicant contributor to things like application responsiveness.
The single threaded performance numbers are just barely ahead of AMD's Jaguar based Kabini SoC. The big difference however is power. I had Intel measure SoC power at the board level while running a single threaded Cinebench 11.5 run on the Atom Z3770 and saw a range of 800mW - 1.2W. AMD on the other hand lists the A4-5000's SoC/APU idle power as 770mW. I don't have equivalent data for AMD, but with the A4-5000 idling at 770mW, it's safe to say that SoC level power consumption is lower on Bay Trail. The A10-4600M/Trinity comparison is interesting as it really helps put Bay Trail's performance in perspective as well.
Multithreaded performance puts Bay Trail and AMD's Kabini at similar performance levels. Once again, looking at SoC power however the Atom Z3770 pulls around 2.5W in this test. Looking at the increase in platform power for the A4-5000 here, I'm assuming that the equivalent data for AMD would put Kabini in the 6W range. Multithreaded performance comes very close to the Pentium 2020M, but that's really overstating the strength of Bay Trail here as the Atom Z3770 has twice as many cores as the Pentium 2020M.
Single threaded integer performance is likely more useful to know, especially given Bay Trail's target market. For a rough idea of what to expect there, we turn to 7-Zip's built in benchmark. The dataset footprint is large enough to require main memory accesses, making this benchmark a little more interesting than it otherwise would've been. I unfortunately don't have access to all the CPUs here, so the 2C/4T 1.9GHz Core i7 3517U turns into a 2C/4T 1.7GHz Core i5 3317U as it's the only comparison data I had handy:
While Silvermont's single threaded FP performance seemed identical to Jaguar, its single threaded integer performance is much higher in the 7-Zip benchmark. Here the Atom Z3770 is 25% faster than the A4-5000. Looking further up the list however, there's still a healthy gap between thermally constrained Ivy Bridge Ultrabook class parts and the best Bay Trail has to offer. In this case Surface Pro's silicon is 70% faster than Bay Trail. Depending on your perspective that's either a huge difference or remarkably small given how wide the previous Atom to Core gap was.
7-Zip also features a multithreaded benchmark. Here we're looking at the same workload, but now split across all available cores/threads:
In multithreaded integer workloads, the Z3770 gets dangerously close to Ivy Bridge levels of performance. Again, we're overstating Bay Trail's performance here as the Z3770 has four cores while the Core i5-3317U only has two (but with Hyper Threading presenting another 2 virtual cores). I don't believe most tablet workloads are heavily threaded integer workloads, however the world is hardly single threaded anymore. The reality is that a quad-core Bay Trail should perform somewhere between 40% - 80% of a dual-core Ivy Bridge.
For what its worth, Bay Trail SoC power during the multithreaded 7-Zip benchmark was between 1.9W - 2.5W. At this point there's no question in my mind that Silvermont and Bay Trail are truly tablet-class power consumers.
Our next tests are browser based benchmarks that, once again, hope to characterize Bay Trail's performance in a manner that's more representative of lighter client workloads:
The Silvermont vs. Jaguar comparison shows a 29% advantage for Intel. Looking back at Clover Trail vs. Bay Trail, the performance improvement is staggering. Intel improved performance by over 3x at this point. The 17W Ivy Bridge vs. Bay Trail comparison continues to be interesting. Here the Core i5-3317U completes the Kraken test in half the time of the Atom Z3770.
The Silvermont/Jaguar gap in SunSpider shrinks a bit in SunSpider. Bay Trail is still over 2x faster than Clover Trail, and Ivy Bridge remains over 2x the speed of Bay Trail.
For our final light CPU workload test we have PCMark 7. This is an interesting benchmark as it takes into account the storage subsystem a bit. Keep in mind here that the Bay Trail system is using eMMC based storage, while all of the others are using a standard SSD (Samsung SSD 830):
As we saw earlier, Bay Trail can make up for its single threaded performance by doing quite well in multithreaded tests. PCMark 7 attempts to present a mixed workload view of Bay Trail's performance and the result is relatively similar to AMD's Jaguar based A4-5000 Kabini APU. AMD's Trinity ends up being just under 30% faster than Bay Trail, while 17W Ivy Bridge is 60% faster. Overall platform performance is definitely not bad at all as long as the OEM does a good job specing the device. In this case the Samsung eMMC solution in the Bay Trail tablet reference design was surprisingly decent.
GPU Performance
Arguably the more interesting CPU and GPU tests will come in the Android section but I borrowed some Android data from our Kabini review and ran through 3DMark, GFXBench 2.7 and some lighter Steam games:
Bay Trail's overall 3DMark Ice Storm score (720p) is about on par with Brazos rather than being a competitor for Kabini. Bay Trail's HD Graphics core is based on Ivy Bridge and it's a cut down implementation at that.
3DMark's Physics test is basically a multithreaded CPU benchmark, which allows the Z3770 to pull ahead of the A4-5000.
If we isolate graphics alone however, the Z3770 once again falls behind Brazos.
GFXBench 2.7's T-Rex HD test seems to agree with what 3DMark tells us:
Obviously under Windows we have more opportunities to benchmark actual game performance. I turned to the lighter (1366 x 768, low quality) game benchmarks I ran for our HD 5000 comparison. I had to exclude Super Street Fighter IV as a driver problem kept it from running on the Bay Trail FFRD.
In a couple of cases Bay Trail delivers roughly half the GPU performance of a 2011 11-inch MacBook Air, but in a much lower power package. Minecraft saw a bigger gap at 1/3 the performance. None of these games are really playable, but that doesn't mean others aren't. I was able to play Team Fortress 2 on Intel's Bay Trail FFRD (with a Bluetooth keyboard and mouse of course) at reasonable frame rates. The system would chunk occasionally but for the most part it was relatively quick. Obviously Bay Trail's graphics are better suited for lighter tablet games.
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?