x264 on Nehalem

[Dark Shikari]

so how much more do the x264 devs expect to increase the performance on the nehalem chip?
even some 'eyeball guesses' would be OK, if you don't know for sure.I expect another ~5% maybe, depending on whether or not we can come up with various interesting optimizations or not. This is Nehalem-specific optimizations: I don't count it if we get something that boosts things 5% on all chips.

The optimization I'm testing currently (SSE2 8x4/8x8/8x16 multiSAD) will have the following benefit at --me umh --subme 7 --8x8dct --ref 6 --mixed-refs --bframes 3

6.9442% x264_pixel_sad_x4_8x8_sse2
1.1245% x264_pixel_sad_x4_8x16_sse2
0.4894% x264_pixel_sad_x3_8x8_sse2

Since the total benefit is about 25%, and those profile CPU-time %s are after the patch, that's an overall ~2% benefit at those settings.

[hajj_3]

every little helps:) I'll upgrade to nehalm once there are £130 boards and triple channel ram is alot cheaper, £280 for a board is just crazy! You should ask intel to send all x264 developers nehalm hardware, faster x264 will help sell more off their cpu's and chipsets.

[Dark Shikari]

committed (http://git.videolan.org/?p=x264.git;a=commit;h=83baa7fdd2edf3e2f9522fc8b79e0826bcf190fc)

[plonk420]

based on my current economic situation (and the stupidly high price of mobos), i may need to skimp on memory if i get an i7...

anyone have any idea as to the impact of running single or double channel memory compared to triple with x264? would video frame size make a difference?

edit: my two uses would be distributed computing and x264 encoding... i'm ASSuming distributed computing (rosetta, world community grid) wouldn't take such a big hit as it doesn't seem there's heavy mem <-> cpu traffic .. at least compared with gaming...

[7oby]

anyone have any idea as to the impact of running single or double channel memory compared to triple with x264?

Tech ARP x264 HD Encoding Test 1st/2n Pass
dual channel : 83.8 fps / 30.3 fps
tripple channel: 85.3 fps / 30.3 fps
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3448&p=5

That test used an older version of x264 though (0.59.819).

Latency is in general more important as you can see on the next slide:
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3448&p=6
However in the case of x264 latency and bandwidth seem to have a similiar effect.

3x 1GB DDR3 isn't expensive anymore as it used to be.

[LoRd_MuldeR]

As a side-note: I just read that some boards come with four memory slots, which is kind of stupid. That's because you can only use three of them, unless you want to put asynchronous load on the memory channels. If you want to keep the option to use two modules per channel, take care to get a board with six memory slots...

[Sharktooth]

4 filled memory slots are configured as dual channel memory access.
no asynch crap...

[LoRd_MuldeR]

4 filled memory slots are configured as dual channel memory access.
no asynch crap...

Really? Then the info in c't magazine was wrong ^^

However being limited to two memory channels when you are supposed to be able to use three would be a significant drawback too...

[Sharktooth]

well, ill check again, but im pretty sure...

EDIT: i just read in general it will be 4 memory slots in a 3+1 configuration. filling the fourth slot will set all the memory subsystem to single channel. however it's at the discretion of the motherboard manufacturer to unhide the options in the BIOS to set what mode of operation to use.

[Oryon]

http://techreport.com/r.x/core-i7/x264-2.gif
It seems that HT help a little, but is not equal for physical cores.

[Sharktooth]

it's obvious it cant be equal to physical cores...

[Sagekilla]

If x264 (or any other multithreaded app) can't feed the 4 physical threads, then yes the extra logical thread will come in handy. They're there only to help keep the execution units completely filled up, but x264 shouldn't have a hard time keeping the execution units churning out data.

[Sharktooth]

HT is exactly the opposite. it doesnt help the software, but the pipeline.
if there are difficulties to keep the pipeline filled, HT becomes effective, otherwise it doesnt.
and that's not a matter of software but of a series of problems a CPU may have (L1 cache too small, pipeline too long, non optimal instructions/data fetch/prefetch, too frequent cache misses, etc...).

[LoRd_MuldeR]

However HT requires at least two threads per CPU core to keep all the ALU's busy.

Hence in order to get the maximum benefit from HT on a Quadcore machine, you need at least eight threads running at a time.

Unless your application is multi-threaded and scales well to a huge number of threads, there's no benefit from HT.

Since x264 scales well with many threads, usually, some benefit from HT can be expected...