ARM Cortex-A9 PandaBoard ES Benchmarks

[ssvb]

Do you mean the relative performance of the results with disabled optimizations? Achieving good performance of the generated code is not the target for such builds at all. They are mostly useful for two reasons:
1. disabling optimizations significantly reduces the chances of triggering some compiler bugs (can be specifically wanted for bootstrapping or debugging purposes)
2. makes the process of compilation faster (speeds up the development)

Now consider the following analogy. Imagine that you ask two guys to walk from point A to point B without mentioning the real purpose of this activity. Moreover, you the only hint you give them is to be absolutely sure not to slip and fall. But once one of the guys reaches the destination, you suddenly award him the "fastest runner" prize And if anybody tries to complain, you just say that the conditions are the same, there surely must be some correlation between how fast a person can walk and run, so such competition is fair and the relative running speed must be still the same.

The same applies to processors and compilers. Optimized build can be easily several times faster than non-optimized build. And you can't generally predict this ratio beforehand.

And in the real world everything is even more tricky. One of the guys could have known beforehand that you have a habit of holding such competitions So he might easily use this information to his advantage. In any case, the only valid benchmarking method is to enable the best optimizations because such benchmarks are reflecting real performance and can't be easily cheated.

PS. Exynos is "faster" than Atom even in the existing SMALLPT test. But this does not change the fact that the test itself is broken.

[snadrus]

And in the real world everything is even more tricky. One of the guys could have known beforehand that you have a habit of holding such competitions So he might easily use this information to his advantage. In any case, the only valid benchmarking method is to enable the best optimizations because such benchmarks are reflecting real performance and can't be easily cheated.

Agreed! ARM hasn't had the years of verification like x86 where things that were once optimizations became labelled as safe, so naturally the unoptimized compilations will be worse performance-wise on ARM. You've got to compile for what you measure for:
For Performance: optimized but generic enough for whatever class of devices you're considering

[Popolon]

most of arm SoC has hardware acceleration for several mp4 encodings. That's strange that VP8 and x264 bench only 1fps, in real life, even a cortex A8 like Hummingbird, that is near 2 years old, or older Rockchip Soc (that as vp8 hard codecs) can encode 720p mp4 at 30fps using very few energy (from 100mW to less than 1 W) on Android/Linux.

A Samsung Galaxy S (1) video encoded with my phone is view in ffmpeg as :

<pre>
VIDEO: [H264] 1280x720 24bpp 1000.000 fps 12141.3 kbps (1482.1 kbyte/s)
Clip info:
major_brand: 3gp4
minor_version: 768
compatible_brands: 3gp43gp6
================================================== ========================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
================================================== ========================
================================================== ========================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 16000 Hz, 1 ch, s16le, 57.6 kbit/22.51% (ratio: 7203->32000)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
================================================== ========================
</pre>

So it can easily encode AAC + 720p H264 @ 30fps. This bench is not accurate at all with it's 1.87 for OMAP4 or 4.59 fps Exynos 4210, that should both encode 1080p H264+AAC audio at 30fps, only using DSP. And sure atom or pentium can't do this at all.

[gururise]

most of arm SoC has hardware acceleration for several mp4 encodings. That's strange that VP8 and x264 bench only 1fps, in real life, even a cortex A8 like Hummingbird, that is near 2 years old, or older Rockchip Soc can encode 720p mp4 at 30fps using very few energy (from 100mW to less than 1 W) on Android/Linux.

-cut-

So it can easily encode AAC + 720p H264 @ 30fps. This bench is not accurate at all with it's 1.87 for OMAP4 or 4.59 fps Exynos 4210, that should both encode 1080p H264+AAC audio at 30fps, only using DSP. And sure atom or pentium can't do this at all.

I think I read somewhere that the DSP functionality is closed, and only works through a non-open driver, so we cannot expect this functionality to work inside an open linux distro.

[Popolon]

I think I read somewhere that the DSP functionality is closed, and only works through a non-open driver, so we cannot expect this functionality to work inside an open linux distro.

Samsung works a lot for integrate its own SoC in kernel main tree and they added Khronos OpenMAX functionality to GST (package description : gst-openmax - Accelerated gst drivers) :
https://launchpad.net/~linaro-landin...+build/2290190

* OMAP3 driver for DSP AAC and mpeg4 codec are available via OpenMAX LI (gpl), perhaps with closed source lower layers :
http://omappedia.org/wiki/OpenMAX_Project

I don't know for ST-Ericsson Nova and all others (ARMlogic, Rockchip, Fujitsu, Nufront......) but I suppose there use OpenMAX low level linux driver for android too.

[Update] : At least Android 4.0 use it via an open source implementation : http://en.wikipedia.org/wiki/OpenMAX#Implementations

[Update 2] : The Samsung Exynos 5250 (32nm Cortex-A15) is already capable of encoding 4K2K@30fps and 1080p@60fps, it's already available for developers, and it's main goal is tablet (aka Android or other flavor of Linux and USB should probably be enough for electric power) :
http://www.samsung.com/global/busine...s/news_11.html

[ssvb]

Both libvpx and x264 are software codecs and don't use DSP or HW accelerators. There is nothing wrong with using them in benchmarks if the purpose is to evaluate CPU performance.

Moreover, hardware video accelerators are often quite picky about what video format variants they support (for decoding) or sacrifice quality (for encoding): http://www.behardware.com/articles/8...-and-x264.html
So x264 is not totally useless even nowadays.

[gili2000]

First of all I learned a lot from the article and forum. Thanks.

I'm considering between two models: the ES and the VAR-SOM-OM44, which can be also be equated with the ES SoC-wise. According to the specifications of the OM44 it reaches 1.5GHz..
Also, ES highlights its bluetooth, but for me it seems the same between the two modules
Other main concerns of mine are android 4.0 support and audio.
Did anyone by any chance had the opportunity to compare or benchmark the OM44? Or Experience with it?
Thanks a lot in advance!
Gili

[gili2000]

First of all I learned a lot from the article and forum. Thanks.

I'm considering between two models: the ES and the VAR-SOM-OM44, which can be also be equated with the ES SoC-wise. According to the specifications of the OM44 it reaches 1.5GHz..
Also, ES highlights its bluetooth, but for me it seems the same between the two modules
Other main concerns of mine are android 4.0 support and audio.
Did anyone by any chance had the opportunity to compare or benchmark the OM44? Or Experience with it?
Thanks a lot in advance!
Gili

[Popolon]

gili2000: best is to avoid omap, that is near unusable on Linux, due to lack of hw acceleration, better is to use other alternatives, Mali 400 based.

ARM motherboard that are supported by linaro.org (working the most on linux port to ARM, and that even help improving linux more generaly) can be found on their site (there are links to resellers):

http://www.linaro.org/low-cost-development-boards

Samsung Exynos is well supported and hw acceleration of the desktop works since about 6 month, ST/Ericsson mother board use Mali 400 too, but don't know if it works well too.