With all these Intel Atom Z3735F been released right now at a price similar to ARM based mini PCs, many people, including myself, are wondering about the performance of the low cost Intel processor against their ARM competitors. Ian Morrison just published some results from Phoronix Test Suite comparing the performance of Firefly-RK3288 (Rockchip RK3288), ODROID-XU3 Lite (Samsung Exynos 5422 BIN2), and A80 OptimusBoard (Allwinner A80) in Linux (Ununtu 12.04.5), against the performance of MeegoPad T01 (Intel Atom Z3735F) running Linux from a Live CD on a USB drive.
Some of the benchmarks failed because Phoronix Test Suite got apparently confused with the file systems located on a USB drive, but at least we’ve got a comparison point, and the results are a bit confusing, as they’re no clear winner. In some tests like FFmpeg, the Intel SoC really crushed the ARM competition being at least twice as fast as Exynos 5422, and about four times faster than RK328 and A80, maybe because of x86 multimedia extensions (SSE4), while in the CLOMP (OpenMP) benchmark it’s the slowest processor, even 6 times slower than on Rockchip RK3288. But overall, Intel Atom Z3735F seems to be a very good performer. We’ll also have to see some GPU benchmark (in Android) to compare these two ARM and x86 SoCs.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Not sure if you’re comparing the actual hardware or the quality of the software with those tests. ARM especially has a lot of hardware options (decoders…) that may or may not be used be ffmpeg et al.
@obarthelemy
It’s clear that in some benchmarks the difference are so great that it should be a software optimization issues, but that’s what products are composed of: hardware and software.
No clear winner maybe, but a lot of red for RK3288.
@Terry
And red marks first place or last place?
@obarthelemy
I think in a Linux distribution, ffmpeg/libav will generally be sofware only and the same version for alll chips based on for example Debian/armhf with NEON SIMD support. So NEON is used but hardware decoding (VPU) is not. The same is probably true for the Z3735F, but it uses SSE2+ which is used by the x86-64 version of ffmpeg.
The ffmpeg difference might be due to higher SIMD (SSE) throughput for the Intel chip when compared to the NEON SIMD throughput for the ARM chips.
Also remember the Intel Z3735F is manufactured on Intel’s 22nm process, which is more advanced than the 28nm processes of the ARM chips. The Intel chip also has a fast L2 cache with the large size of 2MB, which is relatively big given its segment. The A80 also has 2MB for the Cortex-A15 cores, the RK3288 has 1MB, not sure about Exynos 5422.
The Z3735F also has good GPU performance (helped by the advanced process and large caches), although these ARM chips also have fairly good GPU performance. Based on GFXBench performance, the Mali-628 MP6 in Exynos 5422 seems to be fastest, while the other three chips are close (see http://mobilesemi.blogspot.com/2014/12/analysis-of-gpu-peformance-of-moblie.html#Blog1).
@Jibril
The colour coding is:
Green is best
Red is worst
Grey is in between
@Vegator
I am not sure what ffmpeg benchmark really do but
I did some research last week who really do optimization for ARM NEON and I found a lot of patches from linaro last 5-6 months
It is really interesting that for example x265 don’t have any support for ARM NEON
but it looks like there is big push from linaro since december
and VP9 encoder and opus encoder received big patchset in december with support for ARM 64bit
and also speed up libjpeg-turbo
and many more
@Jibril
Linuxium has answered, but Red is worst.
@Jibril
You can’t. I’ll delete it for you.
Good to see how well the Intel compares! We all knew this was coming, Intel jumping in the crazy race of these embedded chips.
Curious to see if Linux could install as easily on the new Intel based tablets.
Now, when shall we get a good dev board with these cpus? 🙂
its because those optimization efforts are USELESS as every SoC on the market has hardware encoders/decoders, no one sane will use software path when they have hardware capable of 4K x265 on hand.
ffmpeg benchmark is pointless, hardware codecs are baked into silicon and run circles around software implementations
@rasz_pl
You are right that hardware codecs baked into silicon (VPU) are highly preferable, but optimized software decode is NOT pointless.
There are always codec formats or combinations of video and audio codecs that are not fully supported by the VPU, even in Android, so full or partial software decode is required…and those common cases it helps a lot when the software decoding (such as ffmpeg) is highly optimized. Even a single codec standard often has a lot of variants, and most VPUs don’t fully support all variants.
Look at media box reviews on this website — in the video play test, there are virtually always several video formats that skip frames, very slowly and don’t play at all — which means software decode is likely to be used. Optimized software decode can make the difference between “unacceptable” and “acceptable” vidoe playback for such cases.
Having many fast CPU cores helps (for example eight Cortex-A7 or Cortex-A53 cores clocked at 2.0 GHz), because ffmpeg is multi-threaded, so in that case you can have reasonably smooth playback with (partial) software decode in many cases. This is why it helps to have a powerful/many core CPU inside a media player.
What I like most about the Z37XX series is that it has a scaled down HD4000 in there. In other words, there are decent OSS drivers available. If I didnt already have a core I3 NUC attached to my TV, I would definitely get one of these Pipo X7 thingies (I may yet do so anyway 🙂
Thank’s Jean Luc for erasing my erroneous post and I apologize for them