Current Patches, Where to get them, How they affect speed/output

[JEEB]

x264 r1181 32bit
download ; release notes

• built on Jul 11 2009, gcc: 4.3.3
• fprofiled, -march=i686

x264 r1181 64bit
download ; release notes

• built on Jul 11 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
• fprofiled, -march=core2

patched with:

• x264_win_zone_parse_fix_05.diff
• x264_hrd_pulldown.13_interlace_modified.diff
• x264_AutoVAQ.03.diff

[G_M_C]

/me is hoping for an update of IMK's ICC / SSE4.x build

[juGGaKNot]

Originally Posted by G_M_C

/me is hoping for an update of IMK's ICC / SSE4.x build

What does it bring to the table so special ? intel cpus ?

[G_M_C]

Originally Posted by juGGaKNot

What does it bring to the table so special ? intel cpus ?

I find that ICC builds are slightly faster on my QX9650.

[Fr4nz]

Originally Posted by G_M_C

I find that ICC builds are slightly faster on my QX9650.

Unfortunately we'll have to wait because his video card is broken...read here (I received this message from him via Youtube yesterday):

Originally Posted by imk

However, the video card in my computer died and I'm $120 short of a new one. Until I can replace that video card I can't compile any new builds. I'm pretty broke at the moment, so it could take a month or more until I set aside $120 for a card. I'll let you know when I get it replaced.

We'll wait

[G_M_C]

Originally Posted by Fr4nz

Unfortunately we'll have to wait because his video card is broken...read here (I received this message from him via Youtube yesterday):



We'll wait

I'll wait too. Bummer the Video card broke. Never had one break in my system, but i dont OC videocards (only CPU's, which is easy with an unlocked "Extreme edition" ).

[rack04]

What is the difference between -march=i686 and -march=core2?

[LoRd_MuldeR]

Originally Posted by rack04

What is the difference between -march=i686 and -march=core2?

The C compiler is instructed to optimize the build either for an i686-family CPU or for an Intel Core2.
While the former allows the compiler to use the "PentiumPro" instruction set, the latter allows the compiler to use also SSE instructions (everything up to SSSE3).
Furthermore with -"march=core2" the compiler will optimize for different CPU timings...

In short: The "-march=i686" build should run on every CPU, except for some archaic ones. The "-march=core2" build should run a bit faster on a Core2 Duo.

See for details:
http://gcc.gnu.org/onlinedocs/gcc-4....002d64-Options

Note that this only effects the plain C code in x264. All the "hand-optimized" assembler code is not effected by compiler optimizations at all!
Also note that x264 uses it's own runtime CPU detection to decide which assembler functions will be used (or not used).

Compiler optimizations can squeeze out a bit more performance (ICC more than GCC), but the important speed-up happens in the assembler part of x264

[kemuri-_9]

pengvado (either here or on irc) stated that it's not icc's C compilation that is causing the speed up...
the cause is the icc equivalent to gcc's -mtune

[G_M_C]

Originally Posted by kemuri-_9

pengvado (either here or on irc) stated that it's not icc's C compilation that is causing the speed up...
the cause is the icc equivalent to gcc's -mtune

Originally Posted by LoRd_MuldeR

[...]
Note that this only effects the plain C code in x264. All the "hand-optimized" assembler code is not effected by compiler optimizations at all!
Also note that x264 uses it's own runtime CPU detection to decide which assembler functions will be used (or not used).

Compiler optimizations can squeeze out a bit more performance (ICC more than GCC), but the important speed-up happens in the assembler part of x264

That's why I said that they' re only slightly faster. But on clips with > 200.000 frames even "slightly" counts to be a measurable timesaving

Originally Posted by G_M_C

I find that ICC builds are slightly faster on my QX9650.

[IgorC]

Originally Posted by G_M_C

That's why I said that they' re only slightly faster. But on clips with > 200.000 frames even "slightly" counts to be a measurable timesaving

1% is still tiny speed up for 100 or 10000 or any other number of frames.
This percentage is hardly noticeble for even >200.000 frames. If encoder gets 10 hours to encode then 1% will present only 6 minutes. It is nothing comparing to 10 hours.
It's still 1%.

[akupenguin]

Originally Posted by kemuri-_9

pengvado stated that it's not icc's C compilation that is causing the speed up...
the cause is the icc equivalent to gcc's -mtune

-mtune affects only C compilation.
I said that any difference between icc-sse2 and icc-ssse3 must be due to the -mtune part rather than the -march part, because icc-ssse3 didn't actually use any ssse3 (but it did include plenty of asm differences in non-sse code). This was not meant to explain any comparison between icc and some other compiler.

[Fr4nz]

Originally Posted by IgorC

1% is still tiny speed up for 100 or 10000 or any other number of frames.
This percentage is hardly noticeble for even >200.000 frames. If encoder gets 10 hours to encode then 1% will present only 6 minutes. It is nothing comparing to 10 hours.
It's still 1%.

Well, IIRC sometimes there's a difference of 4-5% in favor of ICC build, which would save 20-30 minutes...not much, but also better than nothing

Changing the subject, I have on question: my father has an AMD Phenom X4 9550 CPU and if I use the "DXVA-HQ preset" in MeGUI first pass is slightly slower than second pass (this does not happen on my Intel E6750 @3,3 ghz , on which the first pass is ~2.3x faster than the second pass)...how's it possible?

[nm]

Originally Posted by Fr4nz

Changing the subject, I have on question: my father has an AMD Phenom X4 9550 CPU and if I use the "DXVA-HQ preset" in MeGUI first pass is slightly slower than second pass (this does not happen on my Intel E6750 @3,3 ghz , on which the first pass is ~2.3x faster than the second pass)...how's it possible?

B-adapt 2 slows it down, probably. Frametype decision (which is done only in the first pass) is single-threaded, so it acts as a bottleneck on multi-core CPUs.

[Fr4nz]

Originally Posted by nm

B-adapt 2 slows it down, probably. Frametype decision (which is done only in the first pass) is single-threaded, so it acts as a bottleneck on multi-core CPUs.

This makes sense, but how's possibile that the Phenom is slowed down so much??

In order to give you an idea, if in the first pass i have 10-11fps/sec with my E6750@3,3ghz, with Phenom I have merely 5fps/sec...

[Dark Shikari]

Originally Posted by Fr4nz

This makes sense, but how's possibile that the Phenom is slowed down so much??

Phenom has 4 cores, Core 2 Duo has only two?

[Fr4nz]

Originally Posted by Dark Shikari

Phenom has 4 cores, Core 2 Duo has only two?

Intel E6750 has only 2 cores.

Furthermore, in order to give you a better idea of the "situation", second pass is faster on Phenom 9550 than on E6750.

[Dark Shikari]

Originally Posted by Fr4nz

Intel E6750 has only 2 cores.

That's what I just said. What don't you understand? More cores means the penalty for using settings that cripple multithreading will hurt speed more.

[Fr4nz]

Originally Posted by Dark Shikari

That's what I just said. What don't you understand? More cores means the penalty for using settings that cripple multithreading will hurt speed more.

Ok, what I don't understand is: is frametype decision (which is single threaded and indicated as the "culprit" by nm) so "heavy" in respect to other algorithms used by x264 so that Phenom 9550 is brutally outperformed (~2x) by an Intel E6750 in the first pass?

[nm]

One core of your overclocked E6750 outperforms one core of the Phenom by almost 2x. If b-adapt 2 dominates the encoding time because of fast first-pass parameters, this means that overall encoding is also twice as fast on the E6750. Just check x264's CPU usage during the first pass. I guess it's less than 50 % on the Phenom.