X264 latest revision for Intel Processors

[cakuhnen]

I will add here some Intel version of X264 to test purposes only separated for each Intel Processor, test it for me to see if get some speed on it or no :)

Win32 Binaries

* Intel Pentium 4 Release SSE 3 HT
* Intel Pentium 4 Release all compatible without SSE3
* Intel Duo Core 2 Release
* Intel Pentium 3 Release

These binaries cant use in AMD Processors, sorry.
Later will be included 64 bits binaries :)

All Processor specific binaries are inside the archive, use the correct file like your processor you have.
In Intel Math Library directory copy the DLL to X264 directory and in Microsoft Visual C++ 8 Runtime also only the included DLLs not the directory, have fun.

http://rapidshare.com/files/10290314/X264_intel_binaries.7z.html

[CAFxX]

These binaries cant use in AMD Processors, sorry.

Even if this is completely pointless, there you are: ICCPatch (http://www.swallowtail.org/naughty-intel.html)

[foxyshadis]

The only way you would get any important difference out of them is to compile without assembly optimizations, and by doing that all versions would be slower than the original.

[quake74]

Is there a way to test the speed difference reliably under windows? I can run the same command line twice and the final fps will be 5% to 10% different.

[chadamir]

Is there a way to test the speed difference reliably under windows? I can run the same command line twice and the final fps will be 5% to 10% different.

To be accurate, run each one 100 times and find the average.

[Sharktooth]

10 times is enough.. :p
however as it was measured in the past, dont expect a big (if any) speedup...
x264 has already hand-made optimizations that will be faster than any intel lib... (even if i doubt those libs would be used at all since all the math is already translated into assembly, with the exception of the rate control...)

[cakuhnen]

I will try to compile without the assembler optiomizations to see the results then i will post here for test purposes only but remember dont use in AMD Processors it will crash and they are imcompatible. It will be avaliable soon the EMM64 build and Quad Core tests :)

[Romario]

I will try to compile without the assembler optiomizations to see the results

That's not very good idea, cakuhnen.

[Sharktooth]

Remember if you turn off assembler optimizations there will be a MAJOR hit in performance.
Dont think the intel libs are better than hand-made optimizations...

[cakuhnen]

Yes, i know but the current perfomance that X264 now have are much because Pthread Library, cuz if i compile without Pthread lib it uses only 1 core of my 2 core processor

[dragongodz]

These binaries cant use in AMD Processors, sorry.
remember dont use in AMD Processors it will crash and they are imcompatible.
hmmm wrong and wrong. for example the pentium3 compile works perfectly fine with an athlon xp.

even though intel only specify their own cpus in the manual the compiled code does actually work with amd cpus that have the same features(ie. sse, sse2 etc).

[Sharktooth]

Yes, i know but the current perfomance that X264 now have are much because Pthread Library, cuz if i compile without Pthread lib it uses only 1 core of my 2 core processor
No... x264 could have used native windows threads and have similar performance.
pthreads was choosen for code simplicity and coz akupenguin said pthread was slightly faster than win native threads in his tests...

[akupenguin]

I haven't personally tested the speed of either pthread of win32thread, I don't have a smp box with windows.
Various people in #x264dev benchmarked them, and pthread was much faster than win32thread.

[Sharktooth]

Is there a patch to use the new threading model with win32 native threads? I would like to test it as well.

[akupenguin]

http://haali.cs.msu.ru/win32-threads-2.patch
This is not the one that was benchmarked before, and it may be more efficient. But then iirc Haali was one of the people who didn't get a performance penalty with win32threads.

[Sharktooth]

There are cases on windws where programs sitting idle will affect other multithreaded programs performance making them awork only one one core. In that case rising the number of threads will fix...
maybe those were the cases where performance drops were reported.
However the patch seems to be incomplete. There are still undefined references to pthreads in muxers.c, encoder.c and cpu.c.