XviD & GCC flags: a small benchmark

[mikeX]

A small benchmark regarding mostly GCC flags and their impact on encoding speed with XviD:

: Profile :
: MSI KT3 ULTRA [VIA KT333 based]
: Athlon XP 1800+ [1533 MHz, FSB 133 MHz]
: 256MB RAM 333 MHz
: Debian GNU/Linux 3.1 [custom kernel 2.6.7]
: transcode v0.6.14 (C) 2001-2003 Thomas Oestreich, 2003-2004 T. Bitterberg
: XviD libxvidcore4-1.1.0-0beta1 (GomGom's proposed 1.1 beta)
: NASM version 0.98.38 compiled on Apr 6 2004
: yasm 0.4.0
: gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-2)

video source:
: raw avi 640x320 transcoded from DVD (with crop & hqdn3d)
: 1min 14sec (1782 frames)

xvid configuration:
: vhq=4, qpel, gmc, trellis (rest at default)
: quality based 1 pass [transcode -i source.avi -y xvid -o /dev/null -R 3 -w 2]

: Results :

1) CFLAGS: none
ASSEMBLY: nasm
result: 6.99 fps, 7.00 fps

2) CFLAGS: -O3 -fomit-frame-pointer
ASSEMBLY: nasm
result: 7.42 fps, 7.40 fps 5.9% faster

3) CFLAGS: -O3 -fomit-frame-pointer -march=athlon-xp -mfpmath=sse
ASSEMBLY: nasm
result: 7.53 fps, 7.55 fps, 7.51 fps 7.6% faster

4) CFLAGS: none
ASSEMBLY: no
result: 2.24 fps (x2) 68% slower

5) CFLAGS: -O3 -fomit-frame-pointer -march=athlon-xp -mfpmath=sse
ASSEMBLY: no
result: 2.72 fps 61.1% slower

6) CFLAGS: no
ASSEMBLY: yasm
result: 7.01 fps, 7.03 fps 0.3% faster

[percentage = (new - org)/org * 100 where org = 7 fps]

[Bogalvator]

Informative, thanks for the info.

I'd be interested to know the effects of -ffast-math and -funroll-loops (hint hint ;))

[mikeX]

Considering GomGom's suggestion that a benchmark should be made with a simpler program such as mencoder (single process), rather than transcode (multiple threads), so as to minimize scheduling overhead, I reran the benchmark. I also used the GNU time command to measure performance (where the results from the previous benchmark came from transcode fps display). I also added Bogalvator's request:

: profile :
: MPlayer dev-CVS-050109-23:27-3.4.2 (C) 2000-2005 MPlayer Team
+CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping: 2)
+Detected cache-line size is 64 bytes
+CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
+Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE
: GNU time 1.7

xvid configuration:
: fixed_quant=2:trellis:gmc:qpel:max_bframes=2:hq_ac:chroma_me:vhq=4

: Results :

1) CFLAGS: none
ASSEMBLY: nasm
result: 260 s: 6.83 fps -> 0.0%

2) CFLAGS: -O3 -fomit-frame-pointer
ASSEMBLY: nasm
result: 244 s: 7.28 fps -> 6.6%

3) CFLAGS: -O3 -fomit-frame-pointer -march=athlon-xp -mfpmath=sse
ASSEMBLY: nasm
result: 246 s: 7.25 fps -> 6.1%

4) CFLAGS: none
ASSEMBLY: no
result: 804 s: 2.21 fps -> -67.7%

5) CFLAGS: -O3 -fomit-frame-pointer -march=athlon-xp -mfpmath=sse
ASSEMBLY: no
result: 667 s: 2.66 fps -> -61.0%

6) CFLAGS: no
ASSEMBLY: yasm
result: 259 s: 6.86 fps -> 0.4%

7) CFLAGS: -O3 -fomit-frame-pointer -march=athlon-xp -mfpmath=sse -ffast-math -funroll-loops
ASSEMBLY: yasm
result: 245 s: 7.25 fps -> 6.1%

8) CFLAGS: -O3 -fomit-frame-pointer -march=athlon-xp -mfpmath=sse -ffast-math -funroll-loops
ASSEMBLY: no
result: 649 s: 2.74 fps -> -59.9%



Times were the average of 3-4 runs. These results contradict the previous ones to a certain degree (especially the ones concerning the 'optimised' builds). Transcode runs using the 'time' command for cases 2, 3, 5, 6 give the following results (in comparison to 7.0 fps):
2) 240 s: 7.40 fps -> 5.8%
3) 237 s: 7.49 fps -> 7.2%
4) 654 s: 2.72 fps -> -61.2%
5) 256 s: 6.94 fps -> -0.8%