[x264-devel] MSVC patch test results under MSVC 2013

Joe Stevens jgsteven at yahoo.com
Sun Mar 30 12:56:18 CEST 2014


Martin, Jason, and Steven,

Thanks for your responses.  Per Martin's comment I tested with the MSVC 2013 update 2 CTP and was able to compile x264 with only his patches.  Note that in my original test both binaries that I ran the test with were x86/32 bit builds using with the same configure command and that the gcc build was the exact same code as the MSVC one (e.g., it had the MSVC patches applied as described in my previous email in order to make it an apples-to-apples comparison, the only differences being CC and CFLAGS when configured and built).

I did some additional testing, and wanted to post a few additional numbers.  These tests were done with power management off, a high definition input file (an ATSC capture), and the output file set to NUL and got the following results for average FPS across 6 runs of the encode.

32bit GCC with inline ASM:  1.38 FPS
32bit GCC without inline ASM: 1.34 FPS
32bit MSVC 2013 Update 1 with both sets of patches: 1.27 FPS
32bit MSVC 2013 Update 2 CTP with only Martin's patches: 1.25 FPS
64bit MSVC 10`2 Update 2 CTP with only Martin's patches: 1.40 FPS

So my conclusion is that MSVC is slightly slower but that this difference basically goes away when using a 64 bit build (I didn't have a GCC 64 bit build environment to test with unfortunately).  It also appears that inline ASM accounts for only part of the difference meaning that at least for 32 bit code GCC's compiler optimization must be a little bit better (although this is speculation).  Some details of the test are at the end of the mail.

Regards,

Joe

-- TEST DETAILS -- 

Command: 

time x264 --quiet --crf 18 --preset veryslow --level 4.1 --profile high --frames
 150 -o NUL /home/Joseph/test.y4m


(test.y4m is a 720p clip of random TV from over the air ATSC)

Test method:  

Looped around the above command 6 times with a 'sleep 60' between each execution of the command.  Repeated the test for each version of x264 compiled.

Output (notice there is still significant variation so its hard to say how scientific this test was; should probably do this with a longer input clip or on a better machine than this old testing laptop):

** 32 bit with GCC (including inline ASM) **

encoded 150 frames, 1.46 fps, 2952.85 kb/s
real    1m42.707s
user    0m0.000s
sys     0m0.015s
encoded 150 frames, 1.42 fps, 2952.85 kb/s
real    1m45.994s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.36 fps, 2952.85 kb/s
real    1m50.116s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.40 fps, 2952.85 kb/s
real    1m47.493s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.35 fps, 2952.85 kb/s
real    1m51.659s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.31 fps, 2952.85 kb/s
real    1m54.210s
user    0m0.000s
sys     0m0.031s

** 32 bit with GCC and HAVE_X86_INLINE_ASM set to 0 **

encoded 150 frames, 1.34 fps, 2952.85 kb/s
real    1m52.023s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.31 fps, 2952.85 kb/s
real    1m54.835s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.32 fps, 2952.85 kb/s
real    1m53.376s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.36 fps, 2952.85 kb/s
real    1m50.509s
user    0m0.031s
sys     0m0.000s
encoded 150 frames, 1.34 fps, 2952.85 kb/s
real    1m51.988s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.35 fps, 2952.85 kb/s
real    1m51.538s
user    0m0.015s
sys     0m0.015s

** 32 bit with MSVC 2013 Update 1 **

encoded 150 frames, 1.27 fps, 2952.85 kb/s
real    1m58.251s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.28 fps, 2952.85 kb/s
real    1m57.180s
user    0m0.031s
sys     0m0.000s
encoded 150 frames, 1.24 fps, 2952.85 kb/s
real    2m0.990s
user    0m0.015s
sys     0m0.031s
encoded 150 frames, 1.26 fps, 2952.85 kb/s
real    1m58.976s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.28 fps, 2952.85 kb/s
real    1m57.800s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.27 fps, 2952.85 kb/s
real    1m57.864s
user    0m0.015s
sys     0m0.015s

** 32 bit with MSVC 2013 CTP **

encoded 150 frames, 1.25 fps, 2952.85 kb/s
real    1m59.830s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.27 fps, 2952.85 kb/s
real    1m58.422s
user    0m0.031s
sys     0m0.000s
encoded 150 frames, 1.28 fps, 2952.85 kb/s
real    1m56.982s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.24 fps, 2952.85 kb/s
real    2m0.888s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.28 fps, 2952.85 kb/s
real    1m56.954s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.15 fps, 2952.85 kb/s
real    2m10.682s
user    0m0.031s
sys     0m0.000s

** 64 bit with MSVC 2013 CTP **

encoded 150 frames, 1.47 fps, 2952.85 kb/s
real    1m42.445s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.29 fps, 2952.85 kb/s
real    1m56.321s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.42 fps, 2952.85 kb/s
real    1m46.091s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.38 fps, 2952.85 kb/s
real    1m49.038s
user    0m0.000s
sys     0m0.031s
encoded 150 frames, 1.39 fps, 2952.85 kb/s
real    1m48.337s
user    0m0.015s
sys     0m0.015s
encoded 150 frames, 1.43 fps, 2952.85 kb/s
real    1m45.342s
user    0m0.015s
sys     0m0.015s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20140330/224c0132/attachment-0001.html>


More information about the x264-devel mailing list