Thread: Easy Debian Fremantle Beta Testing
View Single Post
sulu is offline sulu
2012-03-04 , 14:16
Posts: 915 | Thanked: 3,209 times | Joined on Jan 2011 @ Germany
#2625
I just tested a Debian Wheezy chroot in armhf. In principle it works but there are some odd things that I don't understand.
To check whether there is any performance gain I ran nbench. For reference I first did this in in an armel chroot. The result is as follows:
Code:
\h:\w$ ./nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          311.04  :       7.98  :       2.62
STRING SORT         :          48.123  :      21.50  :       3.33
BITFIELD            :      1.4078e+08  :      24.15  :       5.04
FP EMULATION        :          94.282  :      45.24  :      10.44
FOURIER             :           355.5  :       0.40  :       0.23
ASSIGNMENT          :          5.8009  :      22.07  :       5.73
IDEA                :          771.67  :      11.80  :       3.50
HUFFMAN             :          517.72  :      14.36  :       4.58
NEURAL NET          :         0.52156  :       0.84  :       0.35
LU DECOMPOSITION    :          16.355  :       0.85  :       0.61
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 18.351
FLOATING-POINT INDEX: 0.660
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 
L2 Cache            : 
OS                  : Linux 2.6.28.10-power49
C compiler          : gcc version 4.4.5 (Debian 4.4.5-8) 
libc                : libc-2.11.3.so$W5 (Debian 4.4.5-8) 
MEMORY INDEX        : 4.581
INTEGER INDEX       : 4.578
FLOATING-POINT INDEX: 0.366
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder
Then I did the same in the armhf chroot:
Code:
\h:\w$ ./nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          365.68  :       9.38  :       3.08
STRING SORT         :          47.982  :      21.44  :       3.32
BITFIELD            :      1.6907e+08  :      29.00  :       6.06
FP EMULATION        :          51.779  :      24.85  :       5.73
FOURIER             :          1512.4  :       1.72  :       0.97
ASSIGNMENT          :          6.0761  :      23.12  :       6.00
Illegal instruction
The first thing you'll notice is the "illegal instruction" error. I repeated the test maybe a dozen times and the error did not always occur at the same point. Mostly it happened after the STRING SORT (never before) or BITFIELD test but there was no pattern that seemed to make sense. The above run that even completed the ASSIGNMENT test was the very first try. Each of the following runs failed one test earlier until the 5th one failed after the STRING SORT test. After that the pattern was completely random. Because there is no pattern I believe the reason is not Maemo or the N900 being armhf incompatible but some strange effect of other Maemo kernel settings or programs similar to the watchdog.
Does this make sense to anybody? I'm running KP49 without DSP profile and without CSSU btw.

The second thing you'll notice is that the result of the armhf FOURIER test is more than 4 times as high as the one of the armel test which in theory should come in handy in multimedia related tasks. On the other hand the FP EMULATION test dropped by 45%. Does anybody have an idea why the FP EMULATION result changed or does someone know the practical implications of that change?


To get more practical results I made a video decoding benchmark with mplayer and youtube's 240p version of the big buck bunny video:

armel:
Code:
\h:\w$ mplayer -benchmark -nosound -vo null /root/bbb.flv
MPlayer 1.0rc3-4.4.4 (C) 2000-2009 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /root/bbb.flv.
libavformat file format detected.
[lavf] Video stream found, -vid 0
[lavf] Audio stream found, -aid 1
VIDEO:  [FLV1]  400x226  0bpp  24.000 fps  256.8 kbps (31.3 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffflv] vfm: ffmpeg (FFmpeg Flash video)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 400 x 226 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 400x226 => 400x226 Planar YV12 
V: 596.4   0/  0  5%  0%  0.0% 0 0 

BENCHMARKs: VC:  31.237s VO:   0.117s A:   0.000s Sys:  16.393s =   47.748s
BENCHMARK%: VC: 65.4215% VO:  0.2452% A:  0.0000% Sys: 34.3334% = 100.0000%

Exiting... (End of file)
armhf:
Code:
\h:\w$ mplayer -benchmark -nosound -vo null /root/bbb.flv
MPlayer svn r34540 (Debian), built with gcc-4.6 (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /root/bbb.flv.
libavformat version 53.20.0 (external)
Mismatching header version 53.19.0
libavformat file format detected.
[flv @ 0x40a06b10]Estimating duration from bitrate, this may be inaccurate
[lavf] stream 0: video (flv), -vid 0
[lavf] stream 1: audio (mp3), -aid 0
VIDEO:  [FLV1]  400x226  0bpp  24.000 fps  256.8 kbps (31.3 kbyte/s)
Clip info:
 starttime: 0
 totalduration: 596
 totaldatarate: 317
 bytelength: 23668451
 canseekontime: true
 sourcedata: BADC20661MH1320360564963154
 purl: 
 pmsg: 
Load subtitles in /root/
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 53.34.0 (external)
Mismatching header version 53.32.2
Selected video codec: [ffflv] vfm: ffmpeg (FFmpeg Flash video)
==========================================================================
Audio: no sound
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 400x226 => 400x226 Planar YV12 
V: 596.4   0/  0  5%  0%  0.0% 0 0 


BENCHMARKs: VC:  32.116s VO:   0.116s A:   0.000s Sys:  15.791s =   48.023s
BENCHMARK%: VC: 66.8774% VO:  0.2411% A:  0.0000% Sys: 32.8815% = 100.0000%

Exiting... (End of file)
As you can se there is virtually no difference, which I don't understand either. Obviously it works in armhf at all, so the nbench "illegal instruction" error doesn't affect mplayer. On the other hand I'd expect either a noticeable increase due to the better FOURIER test results or a decrease due to the worse FP EMULATION results, depending on how mplayer decodes the video. But the result suggests that there aren't any FP operations involved at all. Is that normal for this codec?
 

The Following 4 Users Say Thank You to sulu For This Useful Post: