Intel i7 and AMD X6 encoding comparision

[Groucho2004]

Originally Posted by xlazom00

As I said on first page

I want to compare real speed of i7 and X6 (single core) on x264
single core thread speed get real information about processor speed.

From my experience x264 can't get 100% of full 6 cores on X6 and i7.
At least I can't get it on 1th pass

This doesn't make sense.

Running the first pass, you will almost always be limited by the decoder/AVIsynth script so the you won't get an accurate result for the raw encoding speed, regardless of the number of threads.

Running the 2nd pass (or CRF), x264 will utilize all cores very efficiently anyway.

So, what's the point?

[xlazom00]

I want to encode multiple files.
In that case you are limited only with CPU power.
It's little more linear in that case.

1. file get 100% of 1. core
2. file get 100% of 2. core
3. file get 100% of 3. core
4. file get 100% of 4. core
5. file get 100% of 5. core
6. file get 100% of 6. core
I can do it in same time


And it's much faster than if you are encoding one file with 6 threads ( 6 files one after another )

[Didée]

Originally Posted by xlazom00

And it's much faster than if you are encoding one file with 6 threads ( 6 files one after another )

I doubt that it's "much" faster. When doing 2-pass encodes, there is some speed increase to expect on the 1st pass (since framedecision is singlethreaded still). There's only very minor speed increase to expect on 2nd pass, and same for CRF encodes.

Quick tryout on a dualcore:

1 x 720p CRF encoding, multithreaded: 6.48 fps

2 x 720p CRF encoding, simultaneously, singlethreaded: 3.30 fps / 3.31 fps

For this random example, that's 2% faster. Is that what you'd call "much faster"?
(The quite little advantage that can be seen is, most probably, the overhead of thread synchronization. Apart from that, 99% CPU usage is 99% CPU usage, no matter how you turn the coin.)

However, one thing is sure: when you mass-convert always 6 videos in parallel, you surely will get more file fragmentation on the resulting files.

[shakey]

If you're encoding 1 file multithreaded, does each core re-use some of the same data in the cpu shared cache (reducing manin memory reads, increasing encoding speed)? If you're doing many single threaded encodes, this won't happen? Also you'll be storing x copys of the x264 executable, x avisynth scripts etc in cache instead of just 1?

Finally, if you're doing many simultaneous encodes, will each encode 'fight' over disk access, since it's very possible that each source is at competely different disk position, so HD seek times will have an effect?

edit: another thought, x264 is quite RAM intensive (with a decent look-ahead buffer). With 6 simultaneous encodes, you'll be limiting this buffer, so you may end up reducing the quality of your encodes if you use single pass mode.

[saint-francis]

Originally Posted by shakey

If you're encoding 1 file multithreaded, does each core re-use some of the same data in the cpu shared cache (reducing manin memory reads, increasing encoding speed)? If you're doing many single threaded encodes, this won't happen? Also you'll be storing x copys of the x264 executable, x avisynth scripts etc in cache instead of just 1?

Finally, if you're doing many simultaneous encodes, will each encode 'fight' over disk access, since it's very possible that each source is at competely different disk position, so HD seek times will have an effect?

edit: another thought, x264 is quite RAM intensive (with a decent look-ahead buffer). With 6 simultaneous encodes, you'll be limiting this buffer, so you may end up reducing the quality of your encodes if you use single pass mode.

I'm not qualified to comment on most of you points but I do know that disk access will not be an issue. Any HDD that can physically interface with a motherboard capable of using X264 will be no where near it's random/sequential read/write limits. And I'm imagining that the I/O will be little more than it is for single process. The only difference, as you noted, would the that there would not be a single, presumably, contiguous file. Still it's peanuts compared to what drives can accomplish.

[Didée]

Another point is: what kind of source material you're encoding. With SD material, the point probably isn't all too serious. But assume it's some Full-HD material, perhaps a BR source, or - who knows - some kind of raw data? Decoding one H.264 1080p stream is one story - decoding six such streams at the same time is another story. After all, you mainly want to encode, not just decode. OTOH, in case of RAW data, the mere bitrate surely starts to matter when dealing with six streams at the same time.