MeGUI CPU Time Test - Compare different CPUs encoding x264
Tags:
-
CPUs
- Download
- Encoding
-
Overclocking
Last response: in Overclocking
graysky
February 17, 2007 6:54:04 PM
I started a thread over at doom9 inviting people with MeGUI installed on their machines to download a small mpg clip with processing scripts and run it, then report the results for the purpose of comparing different CPUs processing the same file. I'd like to extent that same invitation to the folks here.
To participate, you'll need to have MeGUI (which needs dotnet 2.0) and Avisynth installed. Here are links to d/l them:
dotnet 2.0
MeGUI
Avisynth
Download to test files has been removed since >2 weeks of inactivity.
Thanks all!
UPDATE:The results to-date were using a pretty aggressive avs file. I have since updated the files and made a new test.rar -- if you participated in the test PLEASE DELETE YOUR C:\WORK AND WORK.RAR and download the new one from the same URL which uses a more realistic avs file. The new test doesn't require you to mess with the threads setting at all - it is automatic for everyone. I'll start populating a new table with your new results. I started with my own.
Thanks all!
-------------------------------------
![]()
If you keep your CPU:Mem bus 1:1, you'll find that the data scale in a highly linear fashion albeit short of the theoretical maximum. Here is a little analysis on chantmak's data to this end.
![]()
Finally, here is a subset of the data showing that, at least with MeGUI doing this avs, there is really no advantage to running with a higher FSB @ the same clockrate. Mem timing does seem to have an effect (last row). Have a look for yourself:
To participate, you'll need to have MeGUI (which needs dotnet 2.0) and Avisynth installed. Here are links to d/l them:
dotnet 2.0
MeGUI
Avisynth
Download to test files has been removed since >2 weeks of inactivity.
Thanks all!
UPDATE:The results to-date were using a pretty aggressive avs file. I have since updated the files and made a new test.rar -- if you participated in the test PLEASE DELETE YOUR C:\WORK AND WORK.RAR and download the new one from the same URL which uses a more realistic avs file. The new test doesn't require you to mess with the threads setting at all - it is automatic for everyone. I'll start populating a new table with your new results. I started with my own.
Thanks all!
-------------------------------------
If you keep your CPU:Mem bus 1:1, you'll find that the data scale in a highly linear fashion albeit short of the theoretical maximum. Here is a little analysis on chantmak's data to this end.
Finally, here is a subset of the data showing that, at least with MeGUI doing this avs, there is really no advantage to running with a higher FSB @ the same clockrate. Mem timing does seem to have an effect (last row). Have a look for yourself:
More about : megui cpu time test compare cpus encoding x264
graysky
February 21, 2007 1:40:42 PM
graysky
February 24, 2007 5:21:32 PM
Related resources
- Best CPU(s) for X264 encoding - Forum
graysky
February 25, 2007 10:52:59 AM
UPDATE:The results to-date were using a pretty aggressive avs file. I have since updated the files and made a new test.rar -- if you participated in the test PLEASE DELETE YOUR C:\WORK AND WORK.RAR and download the new one from the same URL which uses a more realistic avs file. The new test doesn't require you to mess with the threads setting at all - it is automatic for everyone. I'll start populating a new table with your new results. I started with my own.
The URL is in the first post in this thread.
The URL is in the first post in this thread.
graysky
February 25, 2007 9:19:11 PM
@jeffy: as always, thanks for the large data set. If I entered them correctly, there are two things that stand out to me.
1) It's kinda odd that both the 3.2 GHz examples gave identical results suggesting that the FSB isn't the bottleneck for this experiment (x264.exe with this clip).
2) The overclocking efficiency for your chip is also interesting. If you look at the % increase of the clock vs. the % increase in performance, they aren't 1:1 (see table in first post of this thread). I guess you can also look it in terms of clock rate and work done.
Here's a plot of clock rate vs. encoding time.
![]()
Since you and The Scientist both have data @ clock rate for this chip, I set the error bars to that difference (2.5 %). I'm no statistician, but that's probably okay for these purposes -- we aren't landing a man on the moon after all!
The point I'm making is that you can see a similar trend in the clock rate vs. encode time, suggesting that at some point in your O/C, you face a diminishing return or a loss of efficiency at higher clock rates. Clearly, you'd need a larger number of points in the curve to figure out the sweetspot, but it's interesting none-the-less
...if we assume one factor in the decrease of efficiency is heat (which is probably a safe assumption), I wonder if this sort of data set correlates loosely to "chip health"? In other words, a "healthy" overclock probably isn't on the extreme of the plot and is more likely is the inflection point in the curve? What do you guys think about this? Am I missing something?
1) It's kinda odd that both the 3.2 GHz examples gave identical results suggesting that the FSB isn't the bottleneck for this experiment (x264.exe with this clip).
2) The overclocking efficiency for your chip is also interesting. If you look at the % increase of the clock vs. the % increase in performance, they aren't 1:1 (see table in first post of this thread). I guess you can also look it in terms of clock rate and work done.
Here's a plot of clock rate vs. encoding time.

Since you and The Scientist both have data @ clock rate for this chip, I set the error bars to that difference (2.5 %). I'm no statistician, but that's probably okay for these purposes -- we aren't landing a man on the moon after all!
The point I'm making is that you can see a similar trend in the clock rate vs. encode time, suggesting that at some point in your O/C, you face a diminishing return or a loss of efficiency at higher clock rates. Clearly, you'd need a larger number of points in the curve to figure out the sweetspot, but it's interesting none-the-less
...if we assume one factor in the decrease of efficiency is heat (which is probably a safe assumption), I wonder if this sort of data set correlates loosely to "chip health"? In other words, a "healthy" overclock probably isn't on the extreme of the plot and is more likely is the inflection point in the curve? What do you guys think about this? Am I missing something?
chantmak
February 27, 2007 10:00:05 AM
Here is some more data for you to use...
I'm using 2 gigs of G-Skill 6400 ram, Windows Vista(32 bit), NVidia 7950 GT and a raptor drive.
http://my.imagepile.net/view.php?url=http://my.imagepile.net/images/67941untitled.jpg
http://my.imagepile.net/view.php?url=http://my.imagepile.net/images/13887untitled1.jpg
http://my.imagepile.net/view.php?url=http://my.imagepile.net/images/22132untitled2.jpg
I'm also going to try in xp with a raid 0 configuration (not sure if it matters).
I'm using 2 gigs of G-Skill 6400 ram, Windows Vista(32 bit), NVidia 7950 GT and a raptor drive.
http://my.imagepile.net/view.php?url=http://my.imagepile.net/images/67941untitled.jpg
http://my.imagepile.net/view.php?url=http://my.imagepile.net/images/13887untitled1.jpg
http://my.imagepile.net/view.php?url=http://my.imagepile.net/images/22132untitled2.jpg
I'm also going to try in xp with a raid 0 configuration (not sure if it matters).
graysky
February 27, 2007 6:49:40 PM
graysky
February 27, 2007 7:07:38 PM
Are you using an Intel 965 chipset board?
RJ pointed me to this thread which shows how FSB values from about 360-400 tend to hurt your memory performance which may explain the lower values in your 9x375 result.
RJ pointed me to this thread which shows how FSB values from about 360-400 tend to hurt your memory performance which may explain the lower values in your 9x375 result.
chantmak
February 27, 2007 7:35:38 PM
graysky
February 27, 2007 9:40:26 PM
korbin44
February 27, 2007 11:35:32 PM
No1sFanboy
February 27, 2007 11:45:54 PM
As you requested: 401 x 8: (20 sec. 69.06), (64 sec. 23.11).
............................333 x 9: (22 sec. 66.11), (69 sec. 21.61).
Memory at 1-1 both times.
401 x 8 screenshot
333 x 9 screenshot
............................333 x 9: (22 sec. 66.11), (69 sec. 21.61).
Memory at 1-1 both times.
401 x 8 screenshot
333 x 9 screenshot
graysky
February 28, 2007 12:26:19 AM
graysky
February 28, 2007 12:26:41 AM
Quote:
As you requested: 401 x 8: (20 sec. 69.06), (64 sec. 23.11).............................333 x 9: (22 sec. 66.11), (69 sec. 21.61).
Memory at 1-1 both times.
Thanks man! One thing I was also wondering is at a given clock rate, are results better with a higher fsb?
8x401 = 3.2 ghz
9x356 = 3.2 ghz
...any chance to get your to do the experiment @ 9x356 with mem:cpu 1:1
korbin44
February 28, 2007 12:36:00 AM
graysky
February 28, 2007 12:38:40 AM
korbin44
February 28, 2007 12:53:21 AM
Yeah, it's pretty cool. I love how fast the cpu is. Nothing seems to slow it down. I'm also using air cooling right now. So, once I get my watercooling system in, I can post some faster times. I got the cpu to boot into windows and validated it with CPU-Z running at 3.73ghz, on air! I tried to run Sandra Lite 2007, but it restarted before I could get any results. At that speed, idle with aircooling, I was getting 50C. Pretty hot, but not that bad.
graysky
February 28, 2007 1:32:08 AM
darkstar782
February 28, 2007 1:40:59 AM
korbin44
February 28, 2007 5:56:57 AM
graysky
February 28, 2007 6:50:49 AM
graysky
February 28, 2007 6:57:16 AM
Quote:
Here's some more results:stock
stock test run
3.58ghz
3.58ghz test run
Hope this helps some more.
Cool man, thanks. The log for the 2nd-pass doesn't show the fps; it's cut off in the screenshot
Also, your mem:cpu is 1:1 right?
darkstar782
February 28, 2007 9:30:49 AM
Quote:
It seems I'm missing loads of stuff that should be in c:\work\tools....When you load up MeGUI, run the update function which should d/l everything you need.
Silly me, I avoided that thinking that you had specifically asked us to use an older version, and that a newer (different) version would invalidate the results
darkstar782
February 28, 2007 9:44:00 AM

3.6GHz, 360*10. DDR2-720 3-3-3-10

3.6GHz, 400*9. DDR2-800 4-4-4-12
Actually slightly slower, probably due to relaxed memory timings. Will try again @ 360*10 4-4-4-12.

3.24GHz, 360*9. DDR2-720 4-4-4-12
Sticking with 4-4-4-12 now to make them more comparable.

3.00GHz, 333*9. DDR2-667 4-4-4-12

2.7GHz, 300*9. DDR2-600 4-4-4-12

2.4GHz, 266*9. DDR2-533 4-4-4-12
e6600 stock speeds

3.6GHz, 360*10. DDR2-720 4-4-4-12
4-4-412 results @ 360*10 as promised, it seems FSB speed has a minimal affect on FPS. Memory latencies are far more important.

3.3GHz, 333*10. DDR2-667 4-4-4-12

3GHz, 300*10. DDR2-600 4-4-4-12

2.66GHz, 266*10. DDR2-533 4-4-4-12
e6700 at stock
And finally, just because I want to have the highest Dual Core result:

3.9GHz, 390*10. DDR2-780 4-4-4-12
Who needs Quad Core for real time encoding?
darkstar782
February 28, 2007 11:22:07 AM
korbin44
February 28, 2007 1:34:05 PM
No1sFanboy
February 28, 2007 3:34:25 PM
Quote:
Thanks man! One thing I was also wondering is at a given clock rate, are results better with a higher fsb?
8x401 = 3.2 ghz
9x356 = 3.2 ghz
...any chance to get your to do the experiment @ 9x356 with mem:cpu 1:1
Damn, you've edited you're post. Ok here is the 356 x 9 and the stock speed you originally asked for.
9 x 266 mem 1-1 (27 sec 52.7fps), (75 sec 17.36 fps).
9 x 356 mem 1-1 (21 sec. 70.01fps), (63 sec 23.26 fps).
266 x 9 screenshot
356 x 9 screenshot
No1sFanboy
February 28, 2007 3:39:52 PM
graysky
February 28, 2007 8:24:41 PM
graysky
February 28, 2007 8:26:26 PM
graysky
February 28, 2007 8:34:27 PM
OK! I updated the table with everyone data (I think). If I'm missing something (mem timing perhaps) on your runs, please don't post it to the thread, just PM the missing info or error correct to me and I'll fix it.
The table is larger than my 1280x1024 monitor now; I had to go into 1600x1200 to take that screenshot. Dunno what I'm gonna do when it gets much larger. I think my monitor will do 1920x something
Thanks again to all who contributed to it to date. There is a lot of interesting data in there!
The table is larger than my 1280x1024 monitor now; I had to go into 1600x1200 to take that screenshot. Dunno what I'm gonna do when it gets much larger. I think my monitor will do 1920x something
Thanks again to all who contributed to it to date. There is a lot of interesting data in there!
darkstar782
February 28, 2007 10:31:09 PM
One slight error with your table, 390*10 = 3900 not 3333
Yes, it is prime95 stable at 3.9GHz. Having said that, it gets damn hot, and thats with a Zalman 9700CNPS *and* a 120mm Delta 190CFM fan (think a jet engine but louder) pointing at it.
vCore for that speed is 1.6625V.
The heat and noise is why I usually run @ 3.6GHz.
You seem to have alot of Conroe cores now, I'll try to bench some other machines.
Yes, it is prime95 stable at 3.9GHz. Having said that, it gets damn hot, and thats with a Zalman 9700CNPS *and* a 120mm Delta 190CFM fan (think a jet engine but louder) pointing at it.
vCore for that speed is 1.6625V.
The heat and noise is why I usually run @ 3.6GHz.
You seem to have alot of Conroe cores now, I'll try to bench some other machines.
graysky
February 28, 2007 11:10:26 PM
mrcmtl
March 1, 2007 10:25:00 PM
graysky
March 1, 2007 10:46:26 PM
Quote:
X2 AM2 2808mhz 2GB DDR2-936 C5...58.27FPS/19.33FPS...TIME:25s+76s=101sedit: 12x234 1:1 5-5-5-15
Which X2 (like 4000+ or what and what is the code name of the core)? Also, what are the stock settings for it? If you don't know, you can d/l CPU-Z from here:
http://www.cpuid.com/cpuz.php
graysky
March 1, 2007 10:51:39 PM
graysky
March 1, 2007 10:53:57 PM
@darkstar and N01s: I made a table containing a subset of the main table. It's to demonstrate with both your data that for this chip and avs, there is really no benifit of running at a higher FSB @ a given clock rate. Is it the higher FSB that increases the heat? If so, these data make me think I'd be better off buying a 6700 (for the higher multiplier) and running it @ 10x360 instead of a 6600 running 9x400 or some similar combo.
mrcmtl
March 2, 2007 11:05:50 AM
graysky
March 2, 2007 6:39:34 PM
mrcmtl
March 2, 2007 8:39:57 PM
graysky
March 25, 2007 10:39:45 AM
graysky
February 24, 2008 10:54:49 AM
First off, thanks to all who contributed data.
24-Feb-2008 - Finally updated the data tables on the x264 benchmark page. They are now html based (not .gif images) which makes my life updating them much easier and I will keep this tables up-to-date daily as people post results. Have a look at the 'Data Tends' table that contains a look at the Phenom quad vs. both Kentfield and Yorkfield quads. There are also some comparisons of Wolfdale dual vs. Conroe dual, and some other good stuff.
24-Feb-2008 - Finally updated the data tables on the x264 benchmark page. They are now html based (not .gif images) which makes my life updating them much easier and I will keep this tables up-to-date daily as people post results. Have a look at the 'Data Tends' table that contains a look at the Phenom quad vs. both Kentfield and Yorkfield quads. There are also some comparisons of Wolfdale dual vs. Conroe dual, and some other good stuff.
Read discussions in other Overclocking categories
!
