Hi,

Hello,

Ramiro Polla wrote:

...

Hello,

The people at x264 claim pthreads are faster than w32threads in x264: http://www.via.ecp.fr/via/ml/x264-devel/2006-12/msg00052.html

I released two builds of the same version of FFmpeg at http://arrozcru.no-ip.org/ffmpeg_builds/ One with pthreads for FFmpeg and x264, and the other with w32threads for FFmpeg and whatever's native threading in win32 for x264.

I ask for people to please benchmark both, to finally see and have recorded somewhere which one is better, faster, and more stable. For benchmarking on FFmpeg, use the "-benchmark" argument, and preferable output to "/dev/null" (yes, msys correctly understands /dev/null). This is my result with an AMD Athlon 64 2800+, 512Mb RAM, using http://arrozcru.no-ip.org/ffmpeg_patches/test.mpg :

ffmpeg -benchmark -i test.mpg -f avi -vcodec h264 -acodec mp3 -threads 2 /dev/null

pthreads: bench: utime= 100.281 bench: utime= 102.468 bench: utime= 102.032 bench: utime= 102.359 bench: utime= 102.344 bench: utime= 101.969 avg: 101.909 -extremes: 102.176

w32threads: bench: utime= 101.156 bench: utime= 100.938 bench: utime= 100.812 bench: utime= 100.984 bench: utime= 100.891 bench: utime= 100.765 avg: 100.924 -extremes: 100.906

101.909/100.924 1.0097598192699457017161428401569

pthreads 0.976% slower

102.176/100.906 1.0125859711018175331496640437635

pthreads 1.259% slower

Please, anyone with a dual core or multiple cpu computer?

Test on a Pentium4 D830 CPU 3.00GHz, hyperthreading off. I tested your exe under Cygwin so I modified the command line a bit: time ./ffmpeg.exe -benchmark -i test.mpg \ -f avi -vcodec h264 -acodec mp3 -threads 2 - > /dev/null pthreads: real 1m1.948s user 0m0.015s sys 0m0.015s real 1m1.947s user 0m0.015s sys 0m0.031s real 1m1.965s user 0m0.015s sys 0m0.015s w32threads: real 1m45.064s user 0m0.031s sys 0m0.015s real 1m45.154s user 0m0.030s sys 0m0.031s real 1m45.074s user 0m0.031s sys 0m0.015s (61.948+61.947+61.965)/(105.064+105.154+145.074) .52311901196762099906 The pthreads are the clear winners. Could it be that w32threads is not using the second core? Or that w32threads is not triggering ffmpeg's threaded code? Because with w32threads the times with -threads 1 are the same as -threads 2: real 1m45.205s user 0m0.015s sys 0m0.031s Regards, V?ctor

Hi,

Hello,

V?ctor Paesa wrote:

...

Hi,

...

Hello,

Ramiro Polla wrote:

...

Hello,

The people at x264 claim pthreads are faster than w32threads in x264: http://www.via.ecp.fr/via/ml/x264-devel/2006-12/msg00052.html

I released two builds of the same version of FFmpeg at http://arrozcru.no-ip.org/ffmpeg_builds/ One with pthreads for FFmpeg and x264, and the other with w32threads for FFmpeg and whatever's native threading in win32 for x264.

I ask for people to please benchmark both, to finally see and have recorded somewhere which one is better, faster, and more stable. For benchmarking on FFmpeg, use the "-benchmark" argument, and preferable output to "/dev/null" (yes, msys correctly understands /dev/null).

This is my result with an AMD Athlon 64 2800+, 512Mb RAM, using http://arrozcru.no-ip.org/ffmpeg_patches/test.mpg :

ffmpeg -benchmark -i test.mpg -f avi -vcodec h264 -acodec mp3 -threads 2 /dev/null

pthreads: bench: utime= 100.281 bench: utime= 102.468 bench: utime= 102.032 bench: utime= 102.359 bench: utime= 102.344 bench: utime= 101.969 avg: 101.909 -extremes: 102.176

w32threads: bench: utime= 101.156 bench: utime= 100.938 bench: utime= 100.812 bench: utime= 100.984 bench: utime= 100.891 bench: utime= 100.765 avg: 100.924 -extremes: 100.906

101.909/100.924 1.0097598192699457017161428401569

pthreads 0.976% slower

102.176/100.906 1.0125859711018175331496640437635

pthreads 1.259% slower

Please, anyone with a dual core or multiple cpu computer?

Test on a Pentium4 D830 CPU 3.00GHz, hyperthreading off.

I tested your exe under Cygwin so I modified the command line a bit:

time ./ffmpeg.exe -benchmark -i test.mpg \ -f avi -vcodec h264 -acodec mp3 -threads 2 - > /dev/null

pthreads: real 1m1.948s user 0m0.015s sys 0m0.015s

real 1m1.947s user 0m0.015s sys 0m0.031s

real 1m1.965s user 0m0.015s sys 0m0.015s

w32threads: real 1m45.064s user 0m0.031s sys 0m0.015s

real 1m45.154s user 0m0.030s sys 0m0.031s

real 1m45.074s user 0m0.031s sys 0m0.015s

(61.948+61.947+61.965)/(105.064+105.154+145.074) .52311901196762099906

The pthreads are the clear winners.

Could it be that w32threads is not using the second core? Or that w32threads is not triggering ffmpeg's threaded code?

Because with w32threads the times with -threads 1 are the same as -threads 2: real 1m45.205s user 0m0.015s sys 0m0.031s

Hmm... My bad... I hadn't noticed that "whatever's native threading in win32 for x264" doesn't exist. They removed win32 threading support and only left pthreads. So the w32threads build used x264 with no threading.

I put up new builds on the website. Now they both use pthreads for x264, and the only difference is that libavcodec uses w32threads in one build, and pthreads on the other.

Test on your new build SVN-r7409: pthreads: real 1m1.912s user 0m0.031s sys 0m0.015s real 1m1.927s user 0m0.015s sys 0m0.031s w32threads: real 1m1.997s user 0m0.031s sys 0m0.031s real 1m1.986s user 0m0.015s sys 0m0.031s No clear winner now: (61.912+61.927)/(61.997+61.986) .99883855044643217215 Regards, V?ctor