MeGUI CPU Time Test - Compare different CPUs encoding the same file

[graysky]

I am interested in seeing how newer CPUs compare to my old Athlon XP 3200+. To participate in the test, just download the test file and follow the "instructions.txt" file that's included in the rar file and just post your results to this thread. I'll compile them and post them collectively here.

The rar file contains a small (43 meg) mpeg-2 clip with the an avs script file, d2v file, the jobs etc.

test files (null)
and
avisynth plugins if you need them (null)

(edit - links removed due to inactivity, if you want them, make a post in the thread and I'll add them back)

Remember to read the instructions.txt in the rar file and be sure to grab the older version of x264.exe (also in the instructions.txt).

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!

Update: 07-Apr
Added new data comparing the mt.dll results from the standard results for some multicore machines.

-------------------------------------

http://img249.imageshack.us/img249/8972/resultsnewerrw1.gif

If you keep your CPU:Mem bus 1:1, you'll find that the data scales in a highly linear fashion albeit short of the theoretical maximum. Here is a little analysis on chantmak's data to this end.

http://img337.imageshack.us/img337/8745/graphstw7.gif

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:

http://img250.imageshack.us/img250/7766/fsbfl1.gif

Have a look at the post by aicjofs here (http://forum.doom9.org/showthread.php?p=975017#post975017) where he shows that using mt.dll (http://avisynth.org/mediawiki/MT) on the work.avs I provided can translate into an addition boost of ~14 % on his QX6700. Morph166955 also got a pretty hefty boost on his octacore machine you can read about here (http://forum.doom9.org/showthread.php?t=122318&page=14). I compiled their results in the table below. If you want to experiment with mt.dll yourself, please post your results in the thread and I'll add them to the table as well.

http://img337.imageshack.us/img337/4425/resultsmultizu0.gif

[steve77]

I have an E6300 overclocked to 3.2GHz. Doesn't have the 4MB of L2 cache, but I get a boost from the higher memory speeds.

Post a link so everybody can download it, I'm sure you'll get some takers.

I don't really want to download a ton of plugins though....

Post your AVS file and upload your clip. Mediafire.com is apparently good.

[The Scientist]

Not quite what you asked for but I have a E6600 (Vista). It sounds like you are not quite getting the speed you expect from your encode?

[graysky]

Thanks to both of you guys. I'll put the clip and script together and hopefully later tonight get a friend to put it up on the web for you to d/l.

I have an old athlon xp and just wanted to see how much speed gain the 6600 or 6700 would offer doing an encode (2x speed gain, 4x speed gain, etc.) I'm thinking about building a new core 2 duo system to replace this one. I'll PM you guys with the link ASAP.

Thanks!

[jeffy]

Hi Graysky,

maybe there are more people willing to test, so I would like to suggest using some public upload site like rapidshare.de (see sticky http://forum.doom9.org/showthread.php?t=96362) if you haven't considered this already. Hopefully, then you might be able to compare the results between different PCs more objectively.

If you do this, it will make sense posting results like this:
time - CPU - frequency - RAM - frequency - OS
36 s - E6600 - 2.4 GHz - 1 GB DDR2-800 - WinXP Pro

[graysky]

Thanks jeffy... I agree with you that for a serious comparison and to draw meaningful conclusions we need to be more rigerous about this. My goal here is just to see ballpark numbers to help justify the cost of a new machine right now :)

I think for a real test like you're talking about, we'd need to do more than a 1 minute clip which is just what I got here and am about to put up on a friend's webspace. Are you interested in becoming a datapoint too?

[jeffy]

Thanks jeffy... I agree with you that for a serious comparison and to draw meaningful conclusions we need to be more rigerous about this. My goal here is just to see ballpark numbers to help justify the cost of a new machine right now :)

I think for a real test like you're talking about, we'd need to do more than a 1 minute clip which is just what I got here and am about to put up on a friend's webspace. Are you interested in becoming a datapoint too?
Yes, I might help. C2D - E6600 - 3.5 GHz overclocked - 533 DDR2 at 587 MHz.

[graysky]

Here are the results from the encode on an Athlon XP 3200+ with 1.0 gig of PC3200 (all at stock settings):

http://img243.imageshack.us/img243/6322/resultsvt3.jpg

[jeffy]

As promised:
http://img265.imageshack.us/img265/6404/resultszg9.jpg
4:42 - E6600 - 2.4 GHz - overclocked 3.5 GHz - 1 GB DDR2-533 - overclocked 587 MHz - WinXP Pro

final muxed size: 36,597,760 bytes

In three months' time there are price cuts expected for Core 2 Duo & Quad Cores:
http://forum.doom9.org/showthread.php?t=121978

[graysky]

Very cool. Thanks for doing the test. So it's ~2x boost in encoding time. Can you comment on your overclock. How different are the settings you're using from the stock settings? Also, which MB do you have and would you recommend it?

I'm thinking about either a 6600 or 6700. I also read about the planned cuts, thanks for the link. The other thing I'm thinking pretty hard about is waiting for the 6650 and 6750 to get released and run one on the newer chipset... decisions decisions!

Thanks.

[jeffy]

Very cool. Thanks for doing the test. So it's a little under a 2x boost in encoding time. Can you comment on your overclock. How different are the settings you're using from the stock settings? Also, which MB do you have and would you recommend it?

I'm thinking about either a 6600 or 6700. I also read about the planned cuts, thanks for the link. The other thing I'm thinking pretty hard about is waiting for the 6650 and 6750 to get released and run one on the newer chipset... decisions decisions!

Thanks.
Explained above: 3.5 GHz vs. stock 2.4 GHz
RAM 587 MHz vs. 533 MHz stock
Regarding the motherboard: ASUS P5W DH Deluxe,
http://www.asus.com/products.aspx?l1=3&l2=11&l3=248&model=1198&modelmenu=1
I used Noctua NH-U12F for CPU cooling
http://www.noctua.at/main.php?show=productview&products_id=6&lng=en

I had some issues with this board, but unfortunately it proved that I had my RAM modules faulty so I had to RMA them (running with replacements now), therefore I am unable to comment on its stability.

[graysky]

Thanks for the info. Can I get you to repeat the test @ stock clock speeds? It'll be interesting to see if the increase is linear.

[jeffy]

Thanks for the info. Can I get you to repeat the test @ stock clock speeds? It'll be interesting to see if the increase is linear.
Probably after half a day :-)

[graysky]

Here is the same job on a PII-450 MHz w/ 512 meg of PC133.

http://img248.imageshack.us/img248/2686/p2450mh0.jpg

About 34x slower than your machine and about 16x slower than mine :)

[jeffy]

Here is the same job on a PII-450 MHz w/ 512 meg of PC133.

http://img248.imageshack.us/img248/2686/p2450mh0.jpg

About 34x slower than your machine and about 16x slower than mine :)

:eek: 2:34:20 :thanks:
PII-450/512 RAM.... it used to be ehm... mid-stream, some time ago.... memories :cool:

You have my sympathy for being able to wait 2,5 hrs for a 62-second clip!

[graysky]

Anyone else (someone with a faster Athlon 64 or FX maybe) willing to try it and post results?

[cbarroso]

Hey, I want to participate too! E6400@2.4Ghz (almost passive heatsink :p ), DDR2 @600MHz 4.4.4.12, Vista Utimate. Please, tell where the RAR file is.

[The Scientist]

Couldn't do the test as the first job required the neroAAC. I thought you would have done the test with the default stuff that comes/gets downloaded with meGUI.

[jeffy]

Well, I have to admit something happened the first time... the filesize is too LOW :confused:

So in the end I have decided to make the overclocked high priority comparison again. I have forgotten to make a note about filesize in some cases, sorry.

I have also tried changing the priority in job1-2.xml and job1-3.xml from IDLE to HIGH and NbThreads from 1 to 2, 3 and 4.

Stock, idle:
http://img402.imageshack.us/img402/223/resultsstocktj0.jpg

Stock, high:
http://img402.imageshack.us/img402/8434/resultsstockhighvs2.jpg

Overclocked, high, take 2:
http://img184.imageshack.us/img184/6564/resultshightake2ht3.jpg

Overclocked, high, 2 threads:
http://img253.imageshack.us/img253/7286/results1ovhigh2tje1.jpg

Overclocked, high, 3 threads:
http://img253.imageshack.us/img253/1003/results1ovhigh3tgj9.jpg

Overclocked, high, 4 threads:
http://img251.imageshack.us/img251/7704/results1ovhigh4tcp1.jpg

Final comparison table:
http://img184.imageshack.us/img184/8017/comparisonqh6.jpg

[graysky]

Couldn't do the test as the first job required the neroAAC. I thought you would have done the test with the default stuff that comes/gets downloaded with meGUI.

Sorry man, I thought most had that. It's a free d/l

ftp://ftp6.nero.com/tools/NeroDigitalAudio.zip

Just put neroAacEnc.exe in your MeGUI dir (not the /tools) and it should work.

[graysky]

Final comparison table:
http://img184.imageshack.us/img184/8017/comparisonqh6.jpg

Very interesting data. Thanks for posting these. Your priority (low vs. high) findings are also interesting. I wonder if the odd result in the o/c example was due to some sort of instability? I just ran mine again on high priority and normal got results that are damn near the low priority results:

Priority: Low
FPS 1st Pass: 13.9
FPS 2nd Pass: 3.81

Priority: High
FPS 1st Pass: 14.0
FPS 2nd Pass: 3.72

Priority: Normal
FPS 1st Pass: 14.0
FPS 2nd Pass: 3.78

I have changed the jobs to all be NORMAL priority and re-uploaded the rar file.

[jeffy]

Very interesting data. Thanks for posting these. Your priority (low vs. high) findings are also interesting. I wonder if the odd result in the o/c example was due to some sort of instability?
Well, I think the reason was not overclocking, but the main system partition (C) probably became full during the mux. During the take 2, the filesize 81,617,462 bytes seemed okay.

EDIT: Almost full. The file needed about 80 MB, but less than 40 MB was available.

[graysky]

Since I don't have a dual core processor... how do you change the number of threads? That seems to make a very big difference. Also, can you repeat the results using stock level with different number of threads?

Also, I'm assuming your o/c settings are the same as before: 3.5 GHz RAM 587 MHz?

Thanks!

[jeffy]

Since I don't have a dual core processor... how do you change the number of threads? That seems to make a very big difference. Also, can you repeat the results using stock level with different number of threads?

Also, I'm assuming your o/c settings are the same as before: 3.5 GHz RAM 587 MHz?

Thanks!
I just changed the line in job1-2.xml and job1-3.xml.
<NbThreads>1</NbThreads>
The settings used for overclocking remained the same as before. I am sorry, but I will not repeat the test with stock settings. Anyway, I do hope that someone else will post their results soon.

[cbarroso]

Here is my test:
http://img293.imageshack.us/my.php?image=meguitestkw2.gif
Core 2 Duo E6400@2.4, DDR2@600 4.4.4.12, Windows Vista
Threads = 0 (auto)

[graysky]

Thanks... results added to first post.

[steve77]

This is the result 2 threads:

http://img159.imageshack.us/img159/7691/2thread79705jk7.jpg

This is the result 4 threads:

http://img249.imageshack.us/img249/1350/4thread79702ci2.jpg

2Thread resulting file size: 79,705 KB

4Thread resulting file size: 79,702 KB

Core 2 Duo E6300 @ 3.205GHz, DDR2-916, 2x512MB of RAM. Gigabyte 965P-S3 motherboard, G.Skill HZ ram 4-4-4-12

[rack04]

Overclocked results:

http://i11.photobucket.com/albums/a199/rack04/untitled-3.jpg

AMD XP-M 2400+ @ 2.37 GHz
PDP PC3200LLK 2x512mb @ 215MHz

The final file (test-muxed.mp4) is 77.8 MB (81,622,374 bytes).

http://i11.photobucket.com/albums/a199/rack04/untitled1.jpg

[graysky]

Updated.

[steve77]

I'm actually pretty happy with my times... given that I have a lower clock speed than jeffy, and less L2 cache.

I suspect that memory performance has a big influence on the overall speed...

Great thread, I'll bench my D915 (stock) later on when I get a chance.

[graysky]

Sounds good, thanks for contributing.

...wish I could get you C2D guys to do the test with the optimal # of threads and at the stock levels -- wink wink ;)

[jeffy]

Sounds good, thanks for contributing.

...wish I could get you C2D guys to do the test with the optimal # of threads and at the stock levels -- wink wink ;)
What number is the optimal?? ;)

[graysky]

What number is the optimal?? ;)

Good questions... for you seems like 3 or 4. Wonder how that compares to a setting of 0 like cbarroso's run.

[jeffy]

Good questions... for you seems like 3 or 4. Wonder how that compares to a setting of 0 like cbarroso's run.
Well, I am reconsidering the stock speed test (after half a day) with threads 0 or maybe even threads 4 as well. I can't do that straight away, you have to interrupt all the work, switch to BIOS, reset all the switches necessary, reboot, patiently wait doing nothing and then another reset, setting the appropriate overclock... and getting back to your work, which isn't that :cool:

[graysky]

Whenever you can get to it would be great. Thanks. I'm leaning towards a e6600 and that asus board you have: a 3x increase would be nice. Is it stable at that level of O/C? Have you torture tested via prime95 for 12 hours or so? What are your settings (voltage, FSB, etc.)

Any complaints about the Asus board? I'm also looking at the MSI 975X Platinum Power Up.

[jeffy]

Whenever you can get to it would be great. Thanks. I'm leaning towards a e6600 and that asus board you have: a 3x increase would be nice. Is it stable at that level of O/C? Have you torture tested via prime95 for 12 hours or so? What are your settings (voltage, FSB, etc.)

Any complaints about the Asus board? I'm also looking at the MSI 975X Platinum Power Up.
I have torture tested it only shortly (Prime 95 - approx. 2 hours), it is stable at this level of OC. Regarding the MB, this thread is a don't-miss-it thing:
http://www.xtremesystems.org/forums/showthread.php?t=110193

You should probably weight ins and outs of OC as it voids the CPU warranty. Many people do it, but you have to bear this in mind. It's good to watch CoreTemp temperature:
http://www.thecoolest.zerobrains.com/CoreTemp/
(Supported Intel and AMD CPUs:
http://www.thecoolest.zerobrains.com/CoreTemp/supportlist.html)
Mine are 53/51 degrees of Celsius as of now, CPU usage 87%.

[graysky]

Thanks for the info... how many watts is your PS rated? Also, what brand did you endup going with?

[graysky]

New data point from a dvdrhelp.com (http://forum.videohelp.com/viewtopic.php?t=322709&highlight=) user. Thanks!

[j4gg3r]

You should also provide links to DGIndex, LeakKernelDeInt, Undot and Decimate.
I'll have my unclocked XP2800+ results for you soon.
Well maybee not soon if you have set HQ x.264 output. :D

Edit:
And warn about DGIndex :scared:
http://img401.imageshack.us/img401/8079/warndgyc8.jpg

So I'm guessing v1.48 yes?

http://img291.imageshack.us/img291/2826/h264benchamd2800xpfx5.jpg

Specs:
ASUS A7N8X-X nForce2 400FSB
AMD XP2800+
512MB DDR 400MHz(CAS3) @ 333MHz(CAS2.5 Sync to CPU FSB Multiplier)
http://img183.imageshack.us/img183/3164/cpuzchiphy7.jpg

http://img183.imageshack.us/img183/1584/cpuzmemdw1.jpg

FileSize: 77.8 MB (81,622,555 bytes) every time

[jeffy]

stock, high, threads=0, auto, 81,615,286 bytes
http://img184.imageshack.us/img184/4536/resultsstockhigh0tautoqs3.jpg

stock, high, threads=3, 81,613,746 bytes
http://img218.imageshack.us/img218/4931/stockhigh3tod8.jpg

overclocked, threads=0, auto, 81,615,159 bytes
EDIT: high
http://img48.imageshack.us/img48/2724/results1ovhigh0tautoax5.jpg

[jeffy]

Thanks for the info... how many watts is your PS rated? Also, what brand did you endup going with?
PSU is 350W, Fortron FSP350-60THN-P
http://www.fsp-group.com/english/1_product/2_detail.asp?mainid=1&fid=52&proid=213

[graysky]

You should also provide links to DGIndex, LeakKernelDeInt, Undot and Decimate.
I'll have my unclocked XP2800+ results for you soon.
Well maybee not soon if you have set HQ x.264 output. :D

Edit:
And warn about DGIndex :scared:

Something must have gone wrong with the MeGUI update... when you launch it, the app should automatically install those items for you (at least it did for my system) :confused:

In any case, thank you very much for the data points!

[graysky]

@jeffy: again, thanks for the information and the data! (By now you're sick and tired of resetting overclock settings!)

[jeffy]

@jeffy: again, thanks for the information and the data! (By now you're sick and tired of resetting overclock settings!)
:D :goodpost:
As I was explaining the outs of overclocking, I realized that the stock settings might be more useful for you, so... the results are here.

[rack04]

Overclocked results:

http://i11.photobucket.com/albums/a199/rack04/untitled2-1.jpg

AMD XP-M 2400+ @ 2.43GHz
PDP PC3200LLK 2x512mb @ 220 MHz

The final file (test-muxed.mp4) is 77.8 MB (81,622,374 bytes)

http://i11.photobucket.com/albums/a199/rack04/untitled1-1.jpg

[rack04]

Overclocked results:

http://i11.photobucket.com/albums/a199/rack04/untitled2-2.jpg

AMD XP-M 2400+ @ 2.48GHz
PDP PC3200LLK 2x512mb @ 225 MHz

The final file (test-muxed.mp4) is 77.8 MB (81,622,374 bytes)

http://i11.photobucket.com/albums/a199/rack04/untitled1-2.jpg

[graysky]

Cool man, updated the data. Thanks again for contributing.

[The Scientist]

I was messing around with some code and after reading this thread sort of came up with a little XVID encode test. I know the thread was aimed at a meGUI test but you may be interested in an XVID test.

Don't expect too much, just a silly little test. Download the zip file, sorry it's nearly 15MB, it's due to the data file needed for the conversion test. Just unzip and run the 'bench.NET' file, after a minute or two you should have:

http://www.dvduk.pwp.blueyonder.co.uk/_files/c2d_xvid_112.png

DOWNLOAD LINK (http://www.dvduk.pwp.blueyonder.co.uk/_files/xbench.NET.zip)

P.S. It's a '.NET' program so you know what.....

[Blue_MiSfit]

My Results:

http://img93.imageshack.us/img93/7071/misfitrz4.png (http://imageshack.us)

http://img405.imageshack.us/img405/807/cpuzam3.png (http://imageshack.us)

[Nematocyst]

I have also tried changing the priority in job1-2.xml and job1-3.xml from IDLE to HIGH and NbThreads from 1 to 2, 3 and 4.


Why would you want to video encode at >= normal priority other than to convince yourself it confers no speedup?

It doesn't make sense to run processes that aren't time critical at a priority that allows them to usurp normal processes. (Unless you like turning your box into a paperweight during an encode)

[Now that I think about it, I guess it's because you're running a test and mostly interested in just the encoding performance irrespective of other factors. I guess it makes more sense for a test to use high priority than a real encode. Although, since my typical encodes are done at idle, results using idle priority would be most meaningful to me. Not that it matters... If you aren't using your computer, or just light browsing, you won't see any significant difference in the encode performance... just the performance of the other processes.]

[jeffy]

Why would you want to video encode at >= normal priority other than to convince yourself it confers no speedup?

It doesn't make sense to run processes that aren't time critical at a priority that allows them to usurp normal processes. (Unless you like turning your box into a paperweight during an encode)

[Now that I think about it, I guess it's because you're running a test and mostly interested in just the encoding performance irrespective of other factors. I guess it makes more sense for a test to use high priority than a real encode. Although, since my typical encodes are done at idle, results using idle priority would be most meaningful to me. Not that it matters... If you aren't using your computer, or just light browsing, you won't see any significant difference in the encode performance... just the performance of the other processes.]
Some people need the encoding jobs done as quickly as possible and some don't need it. I like the speed, but if I need the CPU power for another processes as well, I can lower the priority anytime. As high vs. idle offered more than 6% speedup, I'm glad it made the difference. Another point of view: some do their encodes when away from the computer, so the highest possible speed is appropriate.

[jeffy]

I was messing around with some code and after reading this thread sort of came up with a little XVID encode test. I know the thread was aimed at a meGUI test but you may be interested in an XVID test.

Don't expect too much, just a silly little test. Download the zip file, sorry it's nearly 15MB, it's due to the data file needed for the conversion test. Just unzip and run the 'bench.NET' file, after a minute or two you should have:

http://www.dvduk.pwp.blueyonder.co.uk/_files/bench.png

DOWNLOAD LINK (http://www.dvduk.pwp.blueyonder.co.uk/_files/bench.zip)

I used XviD v1.1.2.

P.S. It's a '.NET' program so you know what.....
I can post my results, but it might be better to separate the threads.

EDIT: Could you please explain what do the methods "X","Y" and "Z" do exactly with the source?

[Nematocyst]

Some people need the encoding jobs done as quickly as possible and some don't need it. I like the speed, but if I need the CPU power for another processes as well, I can lower the priority anytime. As high vs. idle offered more than 6% speedup, I'm glad it made the difference. Another point of view: some do their encodes when away from the computer, so the highest possible speed is appropriate.

Except your own data shows that at stock, the encode times were the same for idle or high. That's exactly what you'd expect for a computer not being used for other tasks.

I guess I don't really understand the test either-- why not md5 the result file to make sure each test is indeed doing the same work? I've never used MeGUI before so maybe that's why I don't understand. But it seems to me if you have the same inputs and use the same process on them, you'll end up with the same output. That doesn't appear to be what's happening, for whatever reason.

[jeffy]

Except your own data shows that at stock, the encode times were the same for idle or high. That's exactly what you'd expect for a computer not being used for other tasks.

I guess I don't really understand the test either-- why not md5 the result file to make sure each test is indeed doing the same work? I've never used MeGUI before so maybe that's why I don't understand. But it seems to me if you have the same inputs and use the same process on them, you'll end up with the same output. That doesn't appear to be what's happening, for whatever reason.

I don't know the exact reason why the filesizes differ. I think when you enable multiple threads like I did, you don't get bit identical output and the filesize will also be different, due to the threading penalty. I have tried running a single threaded idle priority test in its original form twice, the filesizes were 81,617,459 and 81,617,462 bytes although the settings were the same, BUT I have in "Tools-Settings-Delete intermediate files" no checkmark, so I could verify the filesizes of both test.264 raw files were identical 81,089,002 bytes and they were bit identical (MD5 sums: 1D31E91B10EB5FA1153640224C167780 and 1D31E91B10EB5FA1153640224C167780). The difference is the sound file 513,551 vs 513,548 bytes. However raw filesizes do differ when the threads are greater than 1 or auto.

[Nematocyst]

However raw filesizes do differ when the threads are greater than 1 or auto.

Ok. That's makes sense. But it's also scary to think that some distributed computing projects could produce different results based on the number of utilized threads, or even because of different synchronization due to external factors. Yikes.

[The Scientist]

I can post my results, but it might be better to separate the threads.Good point, just think it's a bit over kill for a little app, what the hell, I'll start a new thread, try to give it a whirl, someone might like it.

Could you please explain what do the methods "X","Y" and "Z" do exactly with the source?Well rather than do a single test, using certain settings, I use three sets of settings, X,Y,Z, they don't mean anything, could be 1,2,3 or A,B,C. Roughly, X=fast codec settings, Y=medium, Z=slow, qpel, gmc e.t.c.

[graysky]

My Results:

Thanks for contributing man.

It's interesting that my old Barton with the same clock rate as your 64 3500+ keeps pace with it.... at least for this test. After reviewing the data to-date, it seems that the real bang for your buck comes from the dual cores when multithreaded.

[Blue_MiSfit]

Indeed. I'm a little irate that I've been through two platform changes since I had my Barton, and I've seen pretty small gains in video encoding. Still, plenty of other improvements in gaming and photoshop etc to make it well worth it..

A new C2D is on the horizon for me soon :D

~MiSfit

[graysky]

A new C2D is on the horizon for me soon :D

Which C2D are you looking at? I'm on the fence now given the April 22 price cuts on the 6600 or 6700. Also, the whole overclocking for either of these is a bit unknown to me. I'm not wanting to push it to the point of 50C idle temps like jeffy is reporting @ 3.5 GHz. Maybe something a little more conservative like 3.2 GHz which is why I'm thinking the 6600 would be fine.

Anyone know what advantage the 6700 would give me if I'm planning to clock either the 6600 or 6700 around 3.2 GHz? Is it worth the extra 200 bucks in this scenario?

[jeffy]

Which C2D are you looking at? I'm on the fence now given the April 22 price cuts on the 6600 or 6700. Also, the whole overclocking for either of these is a bit unknown to me. I'm not wanting to push it to the point of 50C idle temps like jeffy is reporting @ 3.5 GHz. Maybe something a little more conservative like 3.2 GHz which is why I'm thinking the 6600 would be fine.

Anyone know what advantage the 6700 would give me if I'm planning to clock either the 6600 or 6700 around 3.2 GHz? Is it worth the extra 200 bucks in this scenario?

50C ISN'T IDLE!!! I did said this before:
http://forum.doom9.org/showthread.php?p=955793#post955793

As of now:
CoreTemp 53/51C (89% CPU usage now) means 34C shown in SpeedFan.
Idle CoreTemp is: 46/44C (29C SpeedFan) (CPU usage below 3%)


The difference is explained at the section of CoreTemp website:
http://www.thecoolest.zerobrains.com/CoreTemp/
(Intel and AMD recently published detailed, public information about the "DTS" (Digital Thermal Sensor), which provides much higher accuracy and more relevant temperature reading than the standard thermal diode sensors do.)

It does require better than a stock boxed HSF (cooler) when you want to keep it cool overclocked, my Noctua NH-U12F costs about US$65/EUR55
(http://www.noctua.at/main.php?show=presse_archiv&step=2&news_id=18&lng=en)
This one isn't even noisy - 17 dB(A)
(http://www.noctua.at/main.php?show=productview&products_id=6&lng=en)

[graysky]

It does require better than a stock boxed HSF (cooler) when you want to keep it cool overclocked, my Noctua NH-U12F costs about US$65/EUR55

I was considering the Scythe Ninja Plus. Since I too am thinking about the Asus P5W DH Deluxe board, can you describe your settings? All are done in the BIOS, no?

FSB=?
Multip=?
CPU Voltage=?
Mem Ratio=?
Mem Voltage=?
Other settings I'm not listing=?

Also, do you have speedstepping enabled?

Thanks man.

[jeffy]

http://www.bjorn3d.com/read.php?cID=973&pageID=2628



Disclaimer: All the settings desribed are shown for informational purposes only. They work for me, but there is no warranty whatsoever, express or implied, they will work for anyone else. Everything you do you do at your own risk and the information is provided "as is". Any higher voltage than specified might cause damage to the chips, you have been warned. I did overclocked the CPU and upped the voltages in really small steps.

Advanced - JumperFree Configuration
http://www.xbitlabs.com/misc/picture/?src=/images/cpu/core2duo-e6300/bios-1.jpg&1=1
AI Overclocking: Manual
CPU Frequency 390
DRAM Frequency (as mine allows 533 only) 292
Performance Mode Auto
PCI Express Frequency 100 MHz
PCI Clock 33.33 MHz
Memory Voltage Auto
CPU VCore Voltage 1.525 V (This voltage is really high and I don't RECOMMEND it to anyone)
FSB Termination Voltage Auto
MCH Chipset Voltage 1.60 V (again high voltage)
ICH Chipset Voltage Auto

Advanced - Chipset
http://www.xbitlabs.com/misc/picture/?src=/images/cpu/core2duo-e6300/bios-2.jpg&1=1
Hyperpath 3 Disabled
DRAM Throttling Disabled
Memory Remap... Disabled

BTW, while I am on XBITLABS, there is also a review:
http://www.xbitlabs.com/articles/cpu/print/core2duo-e6300.html

The same page also shows usually ...minor... subtle... differences between 2 and 4 MB L2 cache, according to tests 1.86 GHz AutoGK 2.27/DiVX 6.2, fps = 40.23 vs 40.81 = 1.4%

And when you are in the mood for 158 pages worth/long reading
you still have Asus P5W DH - Problems + Fixes Thread
http://www.xtremesystems.org/forums/showthread.php?t=110193
-- information about voltages, cooling, successful/unsuccessful overclocking etc. Some people say their later produced CPU chips require significantly lower voltage for their reliable operation than the other chips produced earlier and some are overclockable on stock voltage as well.

My board is not modded in any way, the chipset coolers were not lapped/thermal conductive material altered etc. BIOS I use: 1506

The only different thing I used with Noctua NH-U12F cooler instead of a supplied thermal paste was Arctic Silver 5.

Also, when choosing your PSU, beware, 350W like mine are not enough when you go for a newer graphic card.

Quote:
To power a single GeForce 8800 GTX card, Nvidia recommends a 450-watt power supply in a PC with a high-end dual-core chip and a typical combination of internal hardware. But the trick is that the power supply must have two PCI Express card power connectors to plug into the two sockets on the back of the card. Most modern power supplies should have the necessary connectors. If you want to add two 8800 GTX cards in an SLI configuration, however, you've got a challenge on your hands.
http://reviews.cnet.com/Nvidia_GeForce_8800_GTX/4505-8902_7-32132889.html

These motherboard comparison reviews might be useful:
http://www.tomshardware.com/2006/10/11/four_975x_motherboards_for_core_2_duo/
http://www.tomshardware.com/2006/11/13/shootout_at_the_core_2_corral/

Also, do you have speedstepping enabled?
I will report sometime later, I am not sure.

[graysky]

Thanks for the info as usual.

[jeffy]

Whilst I was digging something for Xbench.net thread (http://forum.doom9.org/showthread.php?p=958053#post958053), I noticed there was the CPU you were asking about, E6700 included in this test (2.66/3.33/3.46 GHz):
http://www.tomshardware.com/2006/10/10/cheap_thrills/page3.html#test_system

Xvid and DivX included:
http://www.tomshardware.com/2006/10/10/cheap_thrills/page4.html#video

[graysky]

Thanks for the links.. I nearly ordered a 6600 system today and I realized. The board I was about to buy was over a year old and ditto for the chip. Why am I paying a premium for it I wondered? I think I'll just wait for the Bearlake chipset to get released and pick up a 6650 or 6750 to put on it. I dunno.

[jeffy]

Thanks for the links.. I nearly ordered a 6600 system today and I realized. The board I was about to buy was over a year old and ditto for the chip. Why am I paying a premium for it I wondered? I think I'll just wait for the Bearlake chipset to get released and pick up a 6650 or 6750 to put on it. I dunno.

As the title says, if you can wait, then maybe in six months... but there might be "teething" problems with motherboards, my Asus had quite a row of BIOSes.... the same for Gigabyte etc... simply said.

Intel Bearlake chipsets set to arrive in May
(I can only use the link from http://www.tgdaily.com/2007/01/31/intel_bearlake/)
http://www.digitimes.com/news/a20070130PD220.html

http://www.xbitlabs.com/news/chipsets/display/20070215115130.html
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9006938&pageNumber=3

I don't think there was a specific release date published, according to some sources it looks like Q2 or Q3/2007.
http://xtreview.com/addcomment-id-1477-view-intel-bearlake-release-date.html
http://xtreview.com/addcomment-id-686-view-intel-bearlake-chipset-launch-date-and-full-specification.html
http://www.beyond3d.com/forum/showthread.php?t=32786
http://www.dailytech.com/article.aspx?newsid=4588
http://en.wikipedia.org/wiki/List_of_Intel_chipsets

As a last comment, more affordable quad-cores on the way ($530 for Q6600 this April/May).

[graysky]

Ha, finally uppd the FSB on my machine from 200 to 225 and did the benchmark. The machine is actually stable at this level. Anyway, added to the table. I also did the same experiment at higher and lower values; perhaps unsurprisingly, the results are linear. In other words, if you increase the clock rate by 10 %, your benchmarks increase by 10 %.

It's seems to be a limited return on these older chips compared to the pretty huge gains jeffy reported (46 %).

[Selmer79]

I'll get on with testing my rig as soon as I'm done dumping 24 S1 to my HDD for encoding..

[Selmer79]

<NbThreads>1</NbThreads>:
http://i130.photobucket.com/albums/p270/Selmer79/meGUI1.gif

<NbThreads>2</NbThreads>:
http://i130.photobucket.com/albums/p270/Selmer79/meGUI2.gif

Oh, realized I had this image on my Photobucket site.. Should make it really easy to verify my setup..
http://i130.photobucket.com/albums/p270/Selmer79/cpuz1.gif http://i130.photobucket.com/albums/p270/Selmer79/cpuz3.gif

[graysky]

Thanks for the data points - I updated the tables.

[Crisao23]

Since xtremesystems forum went down for the moment, I'm posting here:

Opteron 165 @ 2906Mhz, 2GB DDR400 @ 264Mhz using 4 threads with high priority

http://img506.imageshack.us/img506/508/results29064threadsva3.th.jpg (http://img506.imageshack.us/img506/508/results29064threadsva3.jpg)

[jeffy]

Also, do you have speedstepping enabled?


SpeedStep - disabled in BIOS

[Selmer79]

greysky, you might want to re-calculate your numbers..

My 1-thread test is just about identical to jeffy's 1-thread test, yet his is listed as 1.3x and mine is listed as 1.1x.. ;)

[graysky]

Darnit... I have to error check these. Thanks for the catch.

[Selmer79]

OK, I reproduced your spreadsheet and went over the numbers for you..

Two things I noticed was:

1: Don't use negative values in the last column, just use plain ?.?x. (Ex. george's P2-450 wasn't 18.4x slower, but it was 0.05x of the reference-speed).

2: Instead of running different thread-tests for all kinds of numbers, you should only make a chart of <NbThreads>1</NbThreads> (how powerful the core is) and <NbThreads>0</NbThreads> (how powerful the CPU is). I don't really think you'll see much of an improvement by processing with fewer threads than what meGUI finds optimal. (Only difference might be in video-quality, but this is a SPEED-test right?)

I don't want to be too absolute here, but I'd say that the difference in speed in jeffy's OC'ed 3-, 4-, and 0-thread tests are so small that it's just as likely to be randomness than trend..

(Input on these points is very welcome, since I'm no expert on this area.)

[jeffy]

I don't want to be too absolute here, but I'd say that the difference in speed in jeffy's OC'ed 3-, 4-, and 0-thread tests are so small that it's just as likely to be randomness than trend..
(Input on these points is very welcome, since I'm no expert on this area.)

Comment:
As I had the time to compare the same encode with NbThreads setting of 0, 1, 2, 3, 4, in the end the table shows how insignificant the difference sometimes is.

[Selmer79]

My point being that running nine tests on an Intel quad-core would be kinda meaningless since what's really interesting is the 1-thread test (which is a nice way to gauge speeds between different CPU manufacturers and models) and the 0-threads test (which is a nice way to show just how much horsepower is hiding in the CPU).

From what I understand from the meGUI wiki, running much more than 3 threads can have a negative impact on image quality (or was it compressibility?) because you can't trace motion-vectors between theads...

If I had the choice today, I'd get an Intel system, but when I got my rig, the options in Intel motherboards with SLi was VERY limited... My next rig WILL be Intel though.. My first Intel since 2001 or something?

[Selmer79]

It's good to watch CoreTemp temperature...

SpeedFan can also read out Core Temp (does so on my X2 4600+ atleast). Core Temp is much nicer than that stupid thermistor in the CPU-socket..

http://almico.com/speedfan.php

Core Temp is more accurate, and more responsive. In my rig, the core-temp is usually higher than socket-temp under load, and lower than socket-temp when idle.. I also use SpeedFan to control my CPU-fan, because the on-board Q-Fan feature on my ASUS A8N32-SLI is either full-on or full-off, and it seems to be triggered off the core-temp exactly at 50c (meaning that audio-encoding makes the CPU-fan go up and down "constantly", which is really annoying).

[foxyshadis]

From what I understand from the meGUI wiki, running much more than 3 threads can have a negative impact on image quality (or was it compressibility?) because you can't trace motion-vectors between theads...

That was the old threading model, before r600; the new one has nearly zero quality degradation no matter how many threads it runs. Well, after 32 it starts becoming an issue. Not sure if the wiki's been updating with that info.

[Selmer79]

That was the old threading model, before r600; the new one has nearly zero quality degradation no matter how many threads it runs.

Thanks for the info. :)

This makes me think that this speed-test should be <NbThreads>1</NbThreads> and <NbThreads>0</NbThreads>.. Maybe make a second set of 4 jobs with <NbThreads>0</NbThreads> already in them so that people don't need to muck about with the files themselves (and people with single-core systems will run the test twice with a single core (which would give a bit more accuracy)?

[graysky]

Update to the table: we now have a quad core example -- thanks drjay!

[steve77]

Wow, the Quad Core really flies! However if you have a complex filter chain it must really put it in it's place (especially as many filters are single threaded).

[Selmer79]

Since you're trying to add core-names to the listings, mine is a Manchester...

[graysky]

Updated the chart and will upload to the thread soon.

[Wishbringer]

I have an Athlon64 X2 4600+ (Toledo, 2.4GHz) with 2 GB Corsair 2-2-2-5 DDR1/400 Ram on a Nforce3 Board.
Tests were made with 1 to 4 Threads with increasing speed each step.
System is not overclocked.

1 Thread = 373 sec
2 Threads = 240 sec
3 Threads = 218 sec
4 Threads = 216 sec

[graysky]

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.

[steve77]

Allright, I'll give it another shot. I really don't feel like going stock-clocks though... hope you don't mind. I'll get it done within the next hour or so

[graysky]

Sounds great man. The only thing getting a stock data point is good for is seeing if your clock ratio = your performance ratio. In other words, you're o/c'ing by 20 % you'd expect a 20 % increase in performance.

[steve77]

http://img9.imagepile.net/img9/25122newtest.jpg

Alternative Link to Image: http://img301.imageshack.us/my.php?image=newtestzw2.jpg

File Size: 16,830,651 bytes
Core 2 Duo E6300 @ 3.205GHz (7x458FSB)
Ram 1:1 @ DDR2-916 4-4-4-12

[rack04]

I get this error:

Calling setup of processor failed with error The file C:\work\test-NEW.avs cannot be opened.
Error message for your reference: Telecide: you must specify the order parameter (0=bff, 1=tff).
Refer to the user manual for how to set it properly.
An incorrect setting will result in incorrect decombing.
(C:\work\test-NEW.avs, line 5)

[graysky]

That's odd... I tested it on several machines with no error. Did you install Avisynth to C:\Program Files\AviSynth 2.5 and does your plugins dir within have Decomb.dll ? That should have been updated automatically when MeGUI update runs.

This is what the avs file (test-NEW.avs) should look like:global MeGUI_darx = 4
global MeGUI_dary = 3
DGDecode_mpeg2source("C:\work\test-new.d2v")
AssumeTFF()
Telecide(guide=1,post=2,vthresh=35) # IVTC
Decimate(quality=3) # remove dup. frames
crop( 2, 0, -10, -4)
Spline36Resize(640,480) # Spline36 (Neutral)

Please let me know :)

[rack04]

Yes I have AviSynth installed to C:\Program Files\AviSynth 2.5 and Decomb.dll is in the plugin directory. I didn't have any problem with the first script you posted.

[graysky]

What happens if you drag and drop the script file into your media player? Same error?

[jeffy]

I have even better error! :p
(No offense, please.)

I can't get it to start audio encoding job1-1.xml.
What are the pre-requisities? I can only abort it, then it will do video passes only and of course muxing fails as well.

[ditche]

Nice idea... :)

http://img103.imageshack.us/img103/803/meguiet8.png

Athlon 64 X2 4200+ (Manchester - s939) 2.2 GHz o/c @ 2.53 GHz (11x230), 2 Go DDR PC3200

[graysky]

Same as before: MeGUI (dotnet2.0) and Avisynth. As long as you have MeGUI updated it should just work. As long as you're running it from c:\work it should work (be careful it's not c:\work\work which is could be depending on how you unrared it).

What happens if you load your fav. media player and drag-and-drop the avs file into it? Does it play or give an error?

If you copy of the jobs files to your /megui/jobs and then load megui. Hit Queue and they should be there with status "waiting."

[graysky]

Think I figured it out. I suspect you're missing some dlls from you avisynth/plugins dir that should have been added automatically when megui updated... wonder why it didn't update them for you if I'm right about this.

They are here (http://home.insightbb.com/~pixels/test_encode/plugins.rar). Simply unrar them to the plugins dir of avisynth (where ever you installed it, the default is C:\Program Files\AviSynth 2.5\plugins).

Please let me know if it worked for you both and thanks again!

I also updated work.rar with plugins.rar and updated the instructions.txt to help others if this problem occurs for them too.

[BigDid]

Hi,

I had done the first test but being a non-megui user I was unable to get my C2d to work at full load (E4300 à 2400: 20.89/4.82 fps :( )

New test is ok.
Here are the results for a E4300/1800Mhz o/c @2630 -9x292 Fsb - Ram 2x512 DDR @ 219 - 4:3, timings 3.3.3.8 1t dual channel - MB is an Asrock 775DualVSTA : 52.89/18.17fps
Config still in test, for techs details see: http://forum.doom9.org/showthread.php?t=120509


http://img503.imageshack.us/img503/7919/x264test2e4300263mem219lz8.jpg (http://imageshack.us)

http://img182.imageshack.us/img182/2299/cpuz263ez9.jpg (http://imageshack.us)

Did

Edit: I'll try to take the time to redo at stock speed in a near future

[graysky]

Very cool result. If you have time, it would be cool to see the same test @ stock GHz to compare the efficiency of the E4300 to overclock.

Thanks!

[rack04]

What happens if you drag and drop the script file into your media player? Same error?


Same error when playing the file in Media Player Classic. I have all the files necessary in the Plugins directory.

[jeffy]

Same as before: MeGUI (dotnet2.0) and Avisynth. As long as you have MeGUI updated it should just work. As long as you're running it from c:\work it should work (be careful it's not c:\work\work which is could be depending on how you unrared it).

What happens if you load your fav. media player and drag-and-drop the avs file into it? Does it play or give an error?

If you copy of the jobs files to your /megui/jobs and then load megui. Hit Queue and they should be there with status "waiting."
Avs plays fine, I don't have a problem with the video, plugins are ok, the path is "C:\Work" only.

I found the culprit:
The file job1-1.xml, I had to change this line:
<ForceDecodingViaDirectShow>true</ForceDecodingViaDirectShow>
to:
<ForceDecodingViaDirectShow>false</ForceDecodingViaDirectShow>

[The Scientist]

Slightly overclocked, not much, on a rather crappy overclocking mATX board, P5B-VM, so only a little amount of boost.

Vista with 1GB ram.

http://www.dvduk.pwp.blueyonder.co.uk/_files/c2d261.png

[graysky]

@jeffy: I wonder why that errored out for you? No matter, the audio track is simply there to allow megui to mux something and produce a successful file. I just tested it three times and got results that were identical to the three times I tested it with my old jobs.

I went ahead and updated the main work.rar with that change to maximize compatibility. Good catch and a great piece of detective work there!

[graysky]

@The Scientist: Thanks for running the experiment. If you have some time, please consider running it again on your machine @ stock levels so we can see how efficiently the E4300 overclocks (compare the increase to the clock speed to the increase in performance like I did for my chip in the first post of the thread).

I'm pretty sure jeffy will do the same w/ his 6600.

Thanks!

[ditche]

I don't see my result in your table... :scared:

:)

[graysky]

I don't see my result in your table... :scared:

:)

Oops, sincere apologizes, man. I dunno how I missed your post! Updated now :) Thanks for participating! If you get bored, please run the experiment again at stock levels so we can see how efficiently the Manchester overclocks at your settings.

[ditche]

OK, but wait for my next reboot. :p

[The Scientist]

so we can see how efficiently the E4300 overclocksI have a 6600...... But I'll do stock levels if you want.

[graysky]

I have a 6600...... But I'll do stock levels if you want.

Oops... steve77 has the 4300. Yeah man, by all means please do :) It'll also be interesting to compare your stock result with jeffy's stock result.

[BigDid]

Hi,

@grayski, methinks I am the only one (in spite of my efforts to promote it :) ) to own a E4300; Steve77 had a E6300 a few days ago, so I'm quite sure he stills has it -> 1st post sheet change from E4300 to E6300 ;)

@steve77
Wow, the Quad Core really flies! However if you have a complex filter chain it must really put it in it's place (especially as many filters are single threaded) Or try the MT/Setmt() way :)

Originally Posted by graysky
If you have some time, please consider running it again on your machine @ stock levels so we can see how efficiently the E4300 overclocks
That one is for me, I'll let the E6600 to The Scientist ;)

Did

[graysky]

Same error when playing the file in Media Player Classic. I have all the files necessary in the Plugins directory.

Here (http://home.insightbb.com/~pixels/test_encode/plugins.rar) is a small rar file containing the three dlls this script is using. I'm thinking you might be missing TDeint.dll from that error. I dunno why MeGUI updater didn't give it to you if I'm right about this.

Please unpack them to your avisynth/plugins and try it again... we'll get it working :)

[The Scientist]

http://www.dvduk.pwp.blueyonder.co.uk/_files/c2d240.png

[graysky]

Cool, updated the chart. Thanks again.

...how do you like Vista by the way? Is it a memory hog like I've read?

[jeffy]

E6600 9x266 stock DDR2-533@534 2.4 GHz 16,827,736
http://img460.imageshack.us/img460/1381/newst0t9x266jn5.png

E6600 9x356 OC DDR2-533@534 3.2 GHz 16,834,044
http://img91.imageshack.us/img91/2594/newov0t9x356gk7.png

E6600 8x400 OC DDR2-533@600 3.2 GHz 16,832,952
http://img240.imageshack.us/img240/4449/newov0t8x400ka9.png

E6600 9x400 OC DDR2-533@600 3.6 GHz 16,832,858
http://img107.imageshack.us/img107/153/newov0t9x4002ts4.png

[The Scientist]

...how do you like Vista by the way? Is it a memory hog like I've read?lol, if I had listened to just 1% of the things I've read about Vista then I'm sure I would never have upgraded from XP. As with all new OS's, more memory is needed. Luckily, I upgraded to Vista the same time I upgraded my hardware, went from a P4 @ 3GHz 512MB ram 6200 GFX to a C2D 2.4GHz (6600) 1GB ram 7600GT GFX and have never looked back, system is now awesome compared to my previous setup. I would never go back to XP, every program I have works fine on Vista.

This is just my own opinion and experience of Vista, don't anyone else reply with the "why Vista is crap" as it will destroy the thread with off topic discussions. :D

[graysky]

@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.

http://img513.imageshack.us/img513/8079/graphoj6.gif

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?

[graysky]

You know, the more I think about this the more I'd like to see more data to help decide which chip is optimal. Think if you could have 6 or 7 point curves for each chip. You can then figure out which one has the best O/C'ed performance curve and buy that one. In my case I'm torn between the E6600 and E6700. I wonder if the curve for a E6700 would peak earlier then the curve for the E6600 since it's got a higher multiplier... hmmm

[jeffy]

...if we assume one factor in the decrease of efficiency is heat (which is probably a safe assumption),

I don't think it is my case, as the chip is not throttling.

[The Scientist]

Since you and The Scientist both have data @ clock rate for this chipOne other thing to bear in mind, my RAM is DDR2-800.

[ditche]

Nice idea... :)

http://img103.imageshack.us/img103/803/meguiet8.png

Athlon 64 X2 4200+ (Manchester - s939) 2.2 GHz o/c @ 2.53 GHz (11x230), 2 Go DDR PC3200

Groumf, my Maxtor 160 Go didn't like the reboot... he's practically dead... :angry: thanks to GetDataBack ! :p

So, now my results @ stock (2,2 GHz - 11x200)

http://img135.imageshack.us/img135/1353/megui2ek2.png

What do you think create an Excel graph ?

(Sorry for my english... :D )

[graysky]

One other thing to bear in mind, my RAM is DDR2-800.

True... I forgot jeffy is using DDR5xx so it's actually pretty amazing that he got to 400. Hmmm... he just PMed me to remind me of that fact. I still think the concept of a clock rate vs. performance has merit. Since my machine can't get the range of a C2D, it would be a poor test case. I'm either about 1:1 or it doesn't boot :)

Someone with a C2D and fast memory that wouldn't interfer with the graph would need to do it: start at stock and work his/her way up to the high end and see if it's linear.

[The Scientist]

If only there's was a proper modern mATX overclocking board I could do it for you.

[graysky]

That's okay... check out the latest table: drjay has broken triple digits with his O/C'ed QX6700. That machine is encode the video faster than you can watch the original!

[Selmer79]

Finally got meGUI to run on Vista. Took some thinking to realize the obvious and get AviSynth-scripts in etc..

Here's the result of the new test under Vista (64-bit):
http://i130.photobucket.com/albums/p270/Selmer79/meGUI/meGUItestVistaStock.jpg
Stock speeds.

Same test on the same machine under XP Pro (32-bit):
http://i130.photobucket.com/albums/p270/Selmer79/meGUI/meGUItestXPStock.jpg.
Stock speeds.

[jeffy]

True... I forgot jeffy is using DDR5xx so it's actually pretty amazing that he got to 400. Hmmm... he just PMed me to remind me of that fact. I still think the concept of a clock rate vs. performance has merit.

I know there are many points having effect on this equation:
:: FSB TO MEMORY RATIO ::
- I saw somewhere in Sandra that you can get best performance while having 1:1 ratio
- I was able to have 400 MHz FSB and 300 MHz DDR2=600 MHz, ratio 4:3

:: MEMORY TIMINGS ::
:: CPU FREQUENCY ::
:: HARD DRIVE SPEED:: and if it is the same drive as the one used for system
and probably also ::RAM SIZE:: depending on the script eg. yours uses on my PC at some point in time
x264.exe 328116 (VM) + 194252 (PM)
megui.exe 149808 (VM) + 33992 (PM)
VM = Virtual Size
PM = Working Set (both given by Process Explorer)

[graysky]

FSM to Mem Ratio was something I didn't think about. I wondered how you hit 400 with your DIMMs :)

I'd still like to see that sort of graph I suggested to see if it's linear or more parabolic.

[graysky]

Thanks for the data, selmer. The small difference between the two O/Ss is interesting.

[The Scientist]

Thanks for the data, selmer. The small difference between the two O/Ss is interesting.
Bear in mind the 32-bit/64-bit too.

[steve77]

I think there might be a mis-calculation: I'd be really surprised if my PC @ 3.2Ghz is just shy of Jeffy's result @ 3.6GHz. If that's the case, I guess that memory bandwidth really does play a huge part! I somehow doubt it though...

[Selmer79]

Feeling bored, I just ran some more tests:

XP Pro, 5% OC:
http://i130.photobucket.com/albums/p270/Selmer79/meGUI/meGUItestXP5pctOC.jpg

XP Pro, 10% OC:
http://i130.photobucket.com/albums/p270/Selmer79/meGUI/meGUItestXP10pctOC.jpg

Vista Home Premium x64, 5% OC:
http://i130.photobucket.com/albums/p270/Selmer79/meGUI/meGUItestVista5pctOC.jpg

Vista Home Premium x64, 10% OC:
http://i130.photobucket.com/albums/p270/Selmer79/meGUI/meGUItestVista10pctOC.jpg

This is just a very simple CPU (FSB) overclock.. Since the temp at the CPU core went up quite a bit (without a very big improvement in performance) I'll keep my system running at stock speeds..

EDIT: I notice that on my 5% Vista OC, there's barely any difference on the first pass.. I think I'll re-run the test and see if it's because of my new arch enemy: Speed Fetch.. It makes video-encoding perform like I was doing a defrag while encoding.. Totally indiscriminate about when it stores it's findings. :eek:

[The Scientist]

@graysky

Whilst editing the original post list you've messed up the % Overclock (core speed) on my test.

[The Scientist]

I guess that memory bandwidth really does play a huge part!Yes it does, especially on more lean (faster) settings.

[graysky]

@TS: I sure did... fixed now, good catch.

[graysky]

I think there might be a mis-calculation: I'd be really surprised if my PC @ 3.2Ghz is just shy of Jeffy's result @ 3.6GHz. If that's the case, I guess that memory bandwidth really does play a huge part! I somehow doubt it though...

The formulas are right to my eye. Guess the FSB really does boost the speed.

[Selmer79]

I've decided to run my own test to compare XP Pro vs Vista Home Premium on my own sources (a full episode of something, probably 24), and while prepping my spreadsheet I noticed I get slightly different results than you do on the "% Performance (TET)"..

What is your formula?

From what I read, it's something like this?

(sTET-oTET)/sTET

sTET = Stock TET
oTET = Overclocked TET

Also, should I use an interlaced source or not (does it make a difference?), and if yes, what filters should I avoid (i.e. non-multithreading filters).

Also, the last row (speed relative to the reference machine).
Am I right the formula used there is:
1/(sTET/rTET)

sTET = Sample TET (setup I just tested)
rTET = Reference TET (non-overclocked XP in my case)

[rack04]

Here are my results from a different computer. I still can't figure out why it doesn't work on my other system.

Intel Pentium D 945 stock @ 3.40 GHz w/ 2GB RAM

http://i11.photobucket.com/albums/a199/rack04/untitled1-3.jpg

http://i11.photobucket.com/albums/a199/rack04/untitled-4.jpg

[Selmer79]

I've been playing some more with the numbers here, and started looking at Total Encoding Time vs Video Encoding Time (since only the video-encoding benefits from multi-threading).

As soon as I run my longer tests and get graysky's formulas I'll post my findings here..

[jeffy]

I get this error:

Calling setup of processor failed with error The file C:\work\test-NEW.avs cannot be opened.
Error message for your reference: Telecide: you must specify the order parameter (0=bff, 1=tff).
Refer to the user manual for how to set it properly.
An incorrect setting will result in incorrect decombing.
(C:\work\test-NEW.avs, line 5)


Have you really tried overwriting your Decomb.dll in Avisynth plugins directory with the version supplied by graysky?
The error looks similar to this thread:
http://forum.doom9.org/showthread.php?p=559997#post559997
If you can, post the MD5 checksum of Decomb.dll.

[rack04]

Have you really tried overwriting your Decomb.dll in Avisynth plugins directory with the version supplied by graysky?
The error looks similar to this thread:
http://forum.doom9.org/showthread.php?p=559997#post559997
If you can, post the MD5 checksum of Decomb.dll.

I tried the Decomb.dll version supplied by graysky in the "work" folder. I don't have access to the problem computer at the moment, but what I can do is copy the Decomb.dll version installed on this computer and overwrite the one on my personal computer when I get home. Thanks for your help.

Here is the MD5 checksum for the Decomb.dll I have on this computer that works:

E4B664C5C504E7A961E676071C347E45

[ditche]

Oops, sincere apologizes, man. I dunno how I missed your post! Updated now :) Thanks for participating! If you get bored, please run the experiment again at stock levels so we can see how efficiently the Manchester overclocks at your settings.
Wouhou ? Twice. :D
http://forum.doom9.org/showthread.php?p=960226#post960226

[Wishbringer]

corresponding to my first test results based on the old work.rar:
http://forum.doom9.org/showthread.php?p=959947#post959947

here's my test with the new work.rar:
124 secs
on a Athlon64 X2 4600+ (Toledo, 2.4GHz) with 2 GB Corsair 2-2-2-5 DDR1/400 Ram Nforce3 Board not overclocked

(as long picture is pending: pass1 = 49,03 fps = 28 sec, pass2 = 16,08 fps = 85 sec... CPU-Settings 12*200)
Maybe differs from Selmer79 because of DDR1 vs. DDR2 or other Tcl/Tras/Trcd or because of other Core (Toledo/Manchester)

[graysky]

What is your formula?

From what I read, it's something like this?

(sTET-oTET)/sTET

sTET = Stock TET
oTET = Overclocked TET

Yep, that's what I'm doing in mine.

Also, should I use an interlaced source or not (does it make a difference?), and if yes, what filters should I avoid (i.e. non-multithreading filters).

I used an interlaced source since it came off a PVR-250. I wanted a realistic test so I intentionally used an interlaced source. I think you should design a test that works for your application (do you mostly do interlaced or progressive in other words). I unfortunately don't know which filters are multithreaded. You might wanna email the authors of them to find out for sure... (let me know what you find out btw)!

Also, the last row (speed relative to the reference machine).
Am I right the formula used there is:
1/(sTET/rTET)

sTET = Sample TET (setup I just tested)
rTET = Reference TET (non-overclocked XP in my case)

I'm using just rTET/sTET for that which is more or less what your formula is as well.

[graysky]

I've been playing some more with the numbers here, and started looking at Total Encoding Time vs Video Encoding Time (since only the video-encoding benefits from multi-threading).

As soon as I run my longer tests and get graysky's formulas I'll post my findings here..

Total Encoding Time is just the sum of the Time1 and Time2 in my spreadsheet. Maybe I should rename it Total Video Encode Time to be more clear. I don't take the audio compression or muxing into account at all -- they're just there to make MeGUI happy and to make a complete video file of known size.

[graysky]

Wouhou ? Twice. :D
http://forum.doom9.org/showthread.php?p=960226#post960226

This is a perfect example of what happens when you start to juggle too many balls :) I'm going to burn out one day soon.

[graysky]

Here are my results from a different computer. I still can't figure out why it doesn't work on my other system.

Intel Pentium D 945 stock @ 3.40 GHz w/ 2GB RAM

I'm confused a bit by the pics and your statement. When you said it's stock @ 3.40 GHz do you mean stock voltage?

Also the pics: the first one shows CPU-Z screenshot with 12x200 = 2400 clock rate, but it also shows "Intel (R) Pentium (R) D CPU 3.40GHz." What's going on... if you're o/c'ing it, what are the multiplier and bus for that O/C? The encode times are more consistent with a 2.4 GHz machine.

Did you run the test twice (once @ stock and once @ o/c and just post the wrong pic)?

I'll add your result(s) to the table once I understand them -- no offense intended, I am genuinely confused :)

[graysky]

here's my test with the new work.rar:
124 secs
on a Athlon64 X2 4600+ (Toledo, 2.4GHz) with 2 GB Corsair 2-2-2-5 DDR1/400 Ram Nforce3 Board not overclocked

Thanks for running it again (sorry about that by the way). The attachment needs some sort of approval before it is viewable. I'm assuming the 124 sec is the sum of the two times so I'll add it to the table as such and update it once the pic becomes available to the public.

Also, is stock for your Toledo 9x266?

[jeffy]

I tried the Decomb.dll version supplied by graysky in the "work" folder. I don't have access to the problem computer at the moment, but what I can do is copy the Decomb.dll version installed on this computer and overwrite the one on my personal computer when I get home. Thanks for your help.

Here is the MD5 checksum for the Decomb.dll I have on this computer that works:

E4B664C5C504E7A961E676071C347E45

Sorry for getting back so late: mine is the same and working
E4B664C5C504E7A961E676071C347E45

[Selmer79]

I'm using just rTET/sTET for that which is more or less what your formula is as well.

Looking at my formulas, I saw that I was making a few errors (math isn't exactly my strong side), but I didn't have time to correct my post (had a bus to catch).

Nice to know you were actually only using the video-encoding in your test.. I always thought you used the whole run.. :thanks:

[graysky]

I should change the column header to make it more clear what is going on...

[Selmer79]

Testing with or without interlacing is really meaningless as long as you use the same source and AviSynth script I guess.. The only thing I can think a filter does to a test like this is add complexity to the encoding, which adds time..

In my case, I don't need to add more time since my progressive source will still take about 30 minutes to encode per test, and ~30 minutes is long enough to get a good sample (random interference will have less influence on the end result).

Since we're counting whole seconds, 1 second is a "big" percentage of 2 minutes, but 1 second is "insignificant" over 30 minutes.

PS: Why do you even need the audio and mux in your test? If you do a 2-pass video-encode alone with your setup, you'll get the "test-new.264" file, which is a known filesize. meGUI is perfectly happy with making just a video-file without sound..

[rack04]

I'm confused a bit by the pics and your statement. When you said it's stock @ 3.40 GHz do you mean stock voltage?

Also the pics: the first one shows CPU-Z screenshot with 12x200 = 2400 clock rate, but it also shows "Intel (R) Pentium (R) D CPU 3.40GHz." What's going on... if you're o/c'ing it, what are the multiplier and bus for that O/C? The encode times are more consistent with a 2.4 GHz machine.

Did you run the test twice (once @ stock and once @ o/c and just post the wrong pic)?

I'll add your result(s) to the table once I understand them -- no offense intended, I am genuinely confused :)

Hell, you got me. It's my work computer so just the regular Dell package deal. Sorry that's all I can tell you. You can omit my results if you like. I was able to find this information:

http://processorfinder.intel.com/details.aspx?sSpec=SL9QB

[*.mp4 guy]

-A64 3800 venice core @2400mhz (stock, single core)
-2*512MB pc3200 Dual channel 2-2-2-5 1T @200mhz (stock, 400mhz DDR)
http://img145.imageshack.us/img145/2305/meguiww5.png
-241s total time

[The Scientist]

You forgot to drag the slider... can't see the FPS. :)

[*.mp4 guy]

First pass was 27.33fps, second was 8.8fps.

[BigDid]

The result for the E4300 stock @ 1800Mhz 9x200/200 - 1:1, same Ram timings:

http://img294.imageshack.us/img294/3039/x264test2e430018mem200qk2.jpg (http://imageshack.us)

Also a cpuz snapshot for the 2630 results ( in post 98)

Did

[jeffy]

Hell, you got me. It's my work computer so just the regular Dell package deal. Sorry that's all I can tell you. You can omit my results if you like. I was able to find this information:

http://processorfinder.intel.com/details.aspx?sSpec=SL9QB

I was looking at that sheet a few hours ago as well, as it says multiplier 17... 17x200=3400 MHz=3.4 GHz, I could only think of CPU-Z showing a SpeedStep state. However, if the PC is still responsive during the test, then you might be able to take the CPU-Z screenshot while the test is running and it should show a full used frequency. There is no need to let the test run again, you can cancel it thereafter, this is just for the CPU frequency to be shown properly.

[graysky]

Hell, you got me. It's my work computer so just the regular Dell package deal. Sorry that's all I can tell you. You can omit my results if you like. I was able to find this information:

http://processorfinder.intel.com/details.aspx?sSpec=SL9QB

I suppose CPU-Z could be wrong... or could be like jeffy said while idled. When you get to work again, can you try jeffy's suggestion? Also, what speed does it display right after the POST on a reboot?

Please let us know what else you can find out :)

[graysky]

First pass was 27.33fps, second was 8.8fps.

Thanks for running the experiment!

[The Scientist]

Hell, you got me. It's my work computer so just the regular Dell package deal. Sorry that's all I can tell you.If you get chance, time, and don't mind, download xbench.NET (in this same forum) and see what it says. It should display the current CPU speed.

[rack04]

Calling setup of processor failed with error The file C:\work\test-NEW.avs cannot be opened.
Error message for your reference: Telecide: you must specify the order parameter (0=bff, 1=tff).
Refer to the user manual for how to set it properly.
An incorrect setting will result in incorrect decombing.
(C:\work\test-NEW.avs, line 5)

Well I still can't get this test to run on my home PC. I used the .dll files in the work.rar and still no go. Here are the md5 checksomes of the 3 files:

E4B664C5C504E7A961E676071C347E45 *Decomb.dll
948D3769BC96B047A4D962A01C65FF5D *DGDecode.dll
495086AFC53C7E33200A3B9374C698A4 *TDeint.dll

I don't know if it makes any difference but I'm using AviSynth 2.56 Build: Oct 28, 2005 [18:44:09]

[jeffy]

Calling setup of processor failed with error The file C:\work\test-NEW.avs cannot be opened.
Error message for your reference: Telecide: you must specify the order parameter (0=bff, 1=tff).
Refer to the user manual for how to set it properly.
An incorrect setting will result in incorrect decombing.
(C:\work\test-NEW.avs, line 5)

Well I still can't get this test to run on my home PC. I used the .dll files in the work.rar and still no go. Here are the md5 checksomes of the 3 files:

E4B664C5C504E7A961E676071C347E45 *Decomb.dll
948D3769BC96B047A4D962A01C65FF5D *DGDecode.dll
495086AFC53C7E33200A3B9374C698A4 *TDeint.dll

I don't know if it makes any difference but I'm using AviSynth 2.56 Build: Oct 28, 2005 [18:44:09]
doesn't return the order value for Telecide, that's all folks! :D
Seriously, mine is 2.57 Dec 31, 2006.
All your MD5 checksums match all my files.

Workaround:
change this line in the file test-NEW.avs
Telecide(guide=1,post=2,vthresh=35) # IVTC
to this:
Telecide(order=1,guide=1,post=2,vthresh=35) # IVTC

[cbarroso]

http://img361.imageshack.us/img361/8144/testio0.gif

Core 2 Duo E6400 @ 2371 (296X8)

[ditche]

Can you create a graph like this ?

http://img401.imageshack.us/img401/3675/megui3fq0.png

[graysky]

doesn't return the order value for Telecide, that's all folks! :D
Seriously, mine is 2.57 Dec 31, 2006.
All your MD5 checksums match all my files.

Workaround:
change this line in the file test-NEW.avs
Telecide(guide=1,post=2,vthresh=35) # IVTC
to this:
Telecide(order=1,guide=1,post=2,vthresh=35) # IVTC

Before trying jeffy's work around (which may change the speed -- I haven't used the order=x parameter myself). You might try upgrading to the newer version of Avisynth which is 2.5.7 -- dunno if that will handle it differently or not?

[graysky]

Can you create a graph like this ?

I never tried to do double bar graphs like that. I'm assuming you want to see the stock vs. o/c for the machines? Maybe someone else can try it out.

[graysky]

RJ pointed me to this thread (http://www.thetechrepository.com/showthread.php?t=30) which shows how FSB values from about 360-400 tend to hurt your memory performance which may explain the lower values in chantmak's results (particularly the 9x375 result), assuming he's using a P965 board. I asked.

What do you guys think about this?

[ditche]

Me ? :D

http://users.skynet.be/bk314761/megui01.png

And without o/c:

http://users.skynet.be/bk314761/megui02.png

:)

[graysky]

What did you use to generate those graphs?

[ditche]

Excel (2007 beta). :)

[BigDid]

Excel (2007 beta). :)
Hi,

Would you consider re-doing a graph with a performance order?
Simpler criterion being the TET (total encoding time) ...

:thanks:

Selfnote: If I want to beat the Athlon64 x2 I have to overclock more :D
Edit: ATM I am n°2 (was n°1) for best %Performance: 46% o/c -> 29.9% TET

Did

[Blue_MiSfit]

Dudes, this is a really good benchmark. A few pieces of it could be better standardized, like the AviSynth version, plugins residing in the plugins folder, the versions of all the encoders (though MeGUI's auto update pretty much takes care of that).

It's quite reproduceable and is an accurate representation of modern high end media encoding.

Review sites should use this :)

~MiSfit

[steve77]

Yeah, if those graphs could be redone by order of performance, and maybe change the font character for the OC'd machines (or make 2 graphs, probably the better idea) It would be one hell of a graph

[graysky]

There are already too many columns in the table for my tastes (I like things to be simple and streamlined), but if you add another column which simply takes the the work divided by the overclock rate (% TET / % Overclock) you get a "over clock efficiency."

With the exception of The Scientists, all of the Core 2 Duo chips overclock to about 65-70 % with this test. Strange that they aren't 100 % efficient. Here is a snapshot of the current table:

http://home.insightbb.com/~pixels/test_encode/snapshot.gif

[The Scientist]

Yippeeeeeeeeeee I'm top of something :)

Me thinks the DDR2 PC-6400 (800) may have something to do with it.....

[graysky]

Actually I'm confused by the results. If you calculate efficiency values based separately on the frames per second, they track much better with the clock rate compared to the times. I did a sample calculation using chantmak's data since his cpu:mem is 1:1 here:
http://home.insightbb.com/~pixels/test_encode/linear2.gif

[graysky]

Me thinks the DDR2 PC-6400 (800) may have something to do with it.....

Chantmak also has DDR2 PC-6400.

[The Scientist]

Yes but if he's at 1:1, then hes memory must be getting underclocked (375). Were as mine was getting overclocked (+400).

[graysky]

Well, the results do scale in a linear fashion:
http://home.insightbb.com/~pixels/test_encode/workvclock.gif

[steve77]

For the sake of the test, this is my time with stock speeds:

1.86Ghz DDR2-533 4-4-4-8 (a little different timings, I tightened them and forgot to change it to 12... shouldn't have a huge impact)

http://img297.imageshack.us/img297/9030/mp4stockuh5.jpg

[graysky]

updated thanks for the data.

[graysky]

Ok! Updated the chart. Interesting that for O/C'ed machines, in general, the work values (1st pass FPS) seem to track closer to the clockrate than the total video encode time does... I still can't figure that one out.

[The Scientist]

Well, the results do scale in a linear fashion:
http://home.insightbb.com/~pixels/test_encode/workvclock.gifYou're making the graph fit an hypothesis, which is easy enough to do, believe me. It doesn't make sense to say it represents a linear fashion when you're comparing the total time (time of both passes) against the FPS of just the 1st pass. Compare like for like, time 1st pass v FPS 1st pass, or 2nd passes, or both.

[The Scientist]

I still can't figure that one out.Although the cpu/motherboard/ram and speeds all play their part in both tests, if you're interest in the brute force of the CPU then concentrate on the 2nd test, if you like to see how the ram and bus speeds play their part look at the 1st test. It goes without saying look at both tests for an overall picture.

[shpitz]

here's mine.
http://img83.imageshack.us/img83/7161/cpuz200pr9.gif
http://img245.imageshack.us/img245/5728/excel200az7.gif
http://img245.imageshack.us/img245/2341/megui200cd4.gif
1-thread at the top, 8-threads at the bottom.

[graysky]

here's mine.

Very interesting data set. Can I get you to run one at threads = 0 to be consistent with the other entries in the table as well? Also, just for my knowledge, when you ran your tests, did you just change the threads value in the jobs file, here:
<NbThreads>0</NbThreads>?

Or did you also change it in the commandline for x264:
--pass 2 --bitrate 1000 --stats "C:\work\test-NEW.stats" --ref 3 --bframes 3 --b-pyramid --weightb --direct auto --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --output "C:\work\test-NEW.264"

[graysky]

You're making the graph fit an hypothesis, which is easy enough to do, believe me. It doesn't make sense to say it represents a linear fashion when you're comparing the total time (time of both passes) against the FPS of just the 1st pass. Compare like for like, time 1st pass v FPS 1st pass, or 2nd passes, or both.

I agree with like for like, I just put FPS1 and total time up there to show that both are linear, in fact if you put all 4 up there: fps1, fps2, time1, and time2, they are all linear. I can't understand why the fpsx values tracks closer to clockrate than the time does.

[ditche]

Hi,

Would you consider re-doing a graph with a performance order?
Simpler criterion being the TET (total encoding time) ...

:thanks:
Salut,
OK, I do (make ?) that when I'm at home. :)

[Wishbringer]

No Pictures for CPU-Z oder MeGUI yet, didn't managed to make some under Vista.

Intel Pentium 4 (Prescott, Socket 478, 90 nm)
3000 MHz, 200 MHz*15, not overclocked
with 2 GB of OCZ 2-3-2-5 DDR400 Platinum XTC

Pass1 = 20,07 fps = 69 sec
Pass2 = 6,66 fps = 208 sec (evil, isn't it?!)

and 298 secs for whole process

[The Scientist]

I agree with like for like, I just put FPS1 and total time up there to show that both are linearBut have no direct relationship to each other. It's like taking a 100 mile journey at 60mph then coming back home at 25 mph and you're linking the total journey time to the first 100 mile 60 mph journey.

I can't understand why the fpsx values tracks closer to clockrate than the time does.If you want to see the correct correlations you need to change the way you're looking at it. You're never going to get anywhere displaying FPS1 and FPS2 as seperate entities and linking to total time. Either find the mean of the two FPS values against total time or each FPS against time each individual run took, not total. If we had values/graphs with these figures it may be easier to see, if any, relationships between them.

[rack04]

Before trying jeffy's work around (which may change the speed -- I haven't used the order=x parameter myself). You might try upgrading to the newer version of Avisynth which is 2.5.7 -- dunno if that will handle it differently or not?

Here is an update:

I had some time to run CPU-Z again and here are the results.

http://i11.photobucket.com/albums/a199/rack04/asdfasdf.jpg

Not it shows the clock speed as 3.4GHz. Strange. I'll rerun your test and report back.

Also, I don't want to upgrade to the newest AviSynth on my personal computer because I need the 2.56 version for DVD Rebuilder.

The version on my work computer which works is AviSynth 2.5.7 Build:Dec 21, 2006. I guess this error comes from an old AviSynth version.

Here is the newest encode:

http://i11.photobucket.com/albums/a199/rack04/qweweqr.jpg

[ditche]

When they are several same CPU like the E6600, I take that which have the best results, OK ?

PS: A 4600+ Toledo ? Manchester nop ? :)

[Selmer79]

Ok, I finally finished my lengthy XP vs Vista benchmark that was inspired by graysky.. Here are my findings:

Source: 24 S4E01 DVD-rip - 61866 frames @ 25fps progressive, no audio.
Encoder: x.264 r620
AviSynth Script:
DGDecode_mpeg2source("C:\24-test\VTS_01_1.d2v")
crop( 2, 2, -2, -2)
LanczosResize(640,352) # Lanczos (Sharp)

Results:
http://i130.photobucket.com/albums/p270/Selmer79/meGUI/summary.jpg

Conclusions:
1: Vista is slower than XP at the moment (like so many others have found before me). From this test and my results on graysky's test, I'd say about 5% slower.
2: Benchmarking under Vista can be a bitch!
3: Something kept engaging my hard-drive during the Vista-tests, and I found no way to stop it.. This has negatively influenced at least three of the Vista-tests.
4: I'll have to re-do all the Vista-tests at a later date to see if I can get more sensible numbers.

If you add 2% performance to the Vista stock, 3% and 8% tests you get more the performance I saw when I ran graysky's test (which was apparently too short to be affected by the hard-drive stuff).

[shpitz]

Very interesting data set. Can I get you to run one at threads = 0 to be consistent with the other entries in the table as well? Also, just for my knowledge, when you ran your tests, did you just change the threads value in the jobs file, here:
<NbThreads>0</NbThreads>?


i only changed the nbthreads entry in the xml files. was i supposed to change other entries? i thought the <nbthreads> entry is a global variable for threads and will affect all commandline execution commands.

what would threads=0 do? isn't it just auto assigning the # of threads according to # of logical cpus? in my case threads=0 should be equal to threads=4...

i will also post the testing i've done with an E4300 in the next few minutes.

thanks

[shpitz]

here's another bench i've done on an E4300 running on a Gigabyte 965P-DS3 rev 2.0 mobo.
default settings, no o/c: fsb @ 200, mem @ 400.
o/c settings: fsb @ 370, mem @ 493

http://img402.imageshack.us/img402/5113/cpuz200vt8.gifhttp://img249.imageshack.us/img249/2530/mem200400as9.gif
http://img249.imageshack.us/img249/3113/excelul9.gif
http://img249.imageshack.us/img249/4400/cpuz370ee9.gifhttp://img249.imageshack.us/img249/4160/mem370493dm9.gif

very interesting data compared to my dual xeon machine.

[ditche]

Updated.

http://users.skynet.be/bk314761/megui01.png

[cbarroso]

I did an Update:

Stock:
http://img388.imageshack.us/img388/7084/result266ex7.gif

300X8:
http://img238.imageshack.us/img238/913/result300iy1.gif

Mem 1:1, 4-4-4-12
Windows Vista Utimate

[graysky]

But have no direct relationship to each other. It's like taking a 100 mile journey at 60mph then coming back home at 25 mph and you're linking the total journey time to the first 100 mile 60 mph journey.

I agree with you: they aren't directly related to each other, but they are both independently related to the clock rate. I just graphed them both independently scaling in a linear fashion with clock rate (I could have used two separate graphs).

I did a little analysis on chantmak's data to this end. Bottom line: the chips are scaling in a linear fashion.

http://img117.imageshack.us/img117/4616/itslinearjr8.gif

[graysky]

Ok, I finally finished my lengthy XP vs Vista benchmark that was inspired by graysky.. Here are my findings:

Pretty interesting that Vista is that much slower (overhead of all those UI effects perhaps?)

[graysky]

what would threads=0 do? isn't it just auto assigning the # of threads according to # of logical cpus? in my case threads=0 should be equal to threads=4...

I'm not entirely sure what it does... thought it was like 1.5x something... I only wanna put stuff in the main table that uses the same script, files, etc. If you wanna run your system with the "standard" thread = 0 scripts, I'll gladly add them. That said, the data you generated is pretty interesting. I wonder if the optimal number of threads depends on the script file or the video source you're using (i.e. some scripts would use different plugins and/or settings, different video sources, etc.)

[graysky]

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!

[ditche]

Athlon XP 1500+ Palomino, 512 Mo SDR PC133 :devil:

http://img338.imageshack.us/img338/7453/1500ik7.png

Test 1 : 11,49 FPS
Test 2 : 3,88 FPS
TET : 512 s

[jeffy]

I'm not entirely sure what it does... thought it was like 1.5x something... I only wanna put stuff in the main table that uses the same script, files, etc. If you wanna run your system with the "standard" thread = 0 scripts, I'll gladly add them. That said, the data you generated is pretty interesting. I wonder if the optimal number of threads depends on the script file or the video source you're using (i.e. some scripts would use different plugins and/or settings, different video sources, etc.)

Threads auto does set 1.5 multiple of the total of cores on E6600, the verification can be found in test-NEW.stats, that is: if you have the Tools-Settings-Delete intermediate files option unchecked.
#options: 640x480 fps=24000/1001 cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0 me=dia subme=1 brdo=0 mixed_ref=0 me_range=12 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=0 bime=0 keyint=250 keyint_min=25 scenecut=40(pre) rc=abr bitrate=2045 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30

The proof can be found in the header of test-NEW.264 as well.

[graysky]

Interesting... does that [threads=3] hold true for his xeon as well? I can enter the threads=3 data for both chips in the table is so.

[Selmer79]

Pretty interesting that Vista is that much slower (overhead of all those UI effects perhaps?)
Well, UI probably takes it's share, but that should become less as graphics-drivers are improved.. As far as I know, the Vista UI is mostly GPU and not CPU..

Right now, I think the biggest performance-reduction comes from the hard-drive interaction.. It's much more than what meGUI would produce itself, so it's either swap or SpeedFetch..

[graysky]

Dammit... I just updated MeGUI and without thinking overwrote the "old" version of x264 with the new one (r623). Does anyone have the "old" version they can upload somewhere? I have no idea how this new version compares and for the tests to be meaningful, everyone has to use the same version of the application.

The "current" version is:
x264.exe --version
x264 0.54.623

I dunno what the prev. version was... anyone?

Thanks.

[jeffy]

I dunno what the prev. version was... anyone?

Thanks.

IF I am not mistaken, r620, http://mirror01.x264.nl/x264/?dir=./revision620

[Selmer79]

Yep, r620 was the previous version.. I delayed updating to r623 for my test since I had run the first two XP-tests on r620 when the update was released..

[ditche]

Pentium M 715 GHz (Dothan) + 512 Mo DDR2100.

http://img91.imageshack.us/img91/5003/couper2lp4.png

http://img91.imageshack.us/img91/6978/couperpo8.png

[graysky]

1.5 GHz or 600 MHz?

[Kurth]

AMD Athlon XP 2400+ with 512 MB PC2100
http://img90.imageshack.us/img90/3523/computerjl0.png

Encoding Results
http://img391.imageshack.us/img391/2234/normalbp1.png

I can overclock my processor to 2267 MHZ and my computer stay stable with this overclock.
http://img391.imageshack.us/img391/9672/computeroverclockek8.png

Encoding Results
http://img391.imageshack.us/img391/723/overclockpp9.png

12%~13% more fast with this overclock ^_^

[foxyshadis]

1.5 GHz or 600 MHz?

715 is 1500 MHz max, 600 MHz min, with speedstep. It looks correct, being slightly higher than my old Banias's (1300) speed.

[ditche]

1.5 GHz or 600 MHz?
1.5 GHz. :)

[graysky]

I'm not entirely sure what it does... thought it was like 1.5x something... I only wanna put stuff in the main table that uses the same script, files, etc. If you wanna run your system with the "standard" thread = 0 scripts, I'll gladly add them. That said, the data you generated is pretty interesting. I wonder if the optimal number of threads depends on the script file or the video source you're using (i.e. some scripts would use different plugins and/or settings, different video sources, etc.)

Threads auto does set 1.5 multiple of the total of cores on E6600, the verification can be found in test-NEW.stats, that is: if you have the Tools-Settings-Delete intermediate files option unchecked.
#options: 640x480 fps=24000/1001 cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0 me=dia subme=1 brdo=0 mixed_ref=0 me_range=12 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=3 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=0 bime=0 keyint=250 keyint_min=25 scenecut=40(pre) rc=abr bitrate=2045 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30

The proof can be found in the header of test-NEW.264 as well.

Sorry it took me so long to reply to this: taking jeffy's thoughts into account it makes sense to use the threads=3 values data points. Entering them as we speak.

One thing shpitz's dedication to understanding the effect threads=x has on encoding has taught us is that the auto setting isn't necessarily optimal, but is probably good enough. I have no idea what the error between runs would be on a dual core or dual chip machine -- it hovers around 1 % on my single core machine with a n=3 comparison.

Anyway, thanks for generating those data sets!

[graysky]

@ Kurth: thanks for the data, updating the table now.

[ditche]

Nice idea... :)

http://img103.imageshack.us/img103/803/meguiet8.png

Athlon 64 X2 4200+ (Manchester - s939) 2.2 GHz o/c @ 2.53 GHz (11x230), 2 Go DDR PC3200
More details...
http://img380.imageshack.us/img380/1633/megui4di7.png

[ditche]

Updated.

http://users.skynet.be/bk314761/megui03.png
http://users.skynet.be/bk314761/megui04.png


CPU @ stock :

http://users.skynet.be/bk314761/megui02.png

[graysky]

Updated main table with new data points. Also, the award for the slowest machine goes to: me! Check out my PII-450 which is pushing 10 years old. It has an (encode time:view time) ratio of about 85:1! Anyone have a slower machine that still runs?

[lucassp]

http://img103.imageshack.us/img103/8378/x264tw5.th.png (http://img103.imageshack.us/my.php?image=x264tw5.png)

[graysky]

Thanks for the data, lucassp. Updated.

[lucassp]

http://img105.imageshack.us/img105/1823/x264defaultys3.th.png (http://img105.imageshack.us/my.php?image=x264defaultys3.png)

and these are the results using the default CPU and Memory Settings :D

[lucassp]

On my Vista Virtual Machine :D

http://img161.imageshack.us/img161/296/x264defaultrg8.th.png (http://img161.imageshack.us/my.php?image=x264defaultrg8.png)
DEFAULT

http://img170.imageshack.us/img170/9256/x264ocmu9.th.png (http://img170.imageshack.us/my.php?image=x264ocmu9.png)
OCed (the same as in XP)

[graysky]

Running it via a virtual machine? Ack, that'll cost you some fps.

[Selmer79]

I re-ran my XP vs Vista test with a smaller source and some other modifications and finally got reliable results..

http://i130.photobucket.com/albums/p270/Selmer79/meGUI/Summary2.jpg

One noteworthy thing I found was that the overclocking efficiency (ΔVET/%overclock) for XP was 80-85%, and on Vista it was 89-94%.. Maybe with some improved drivers Vista will eventually be faster than XP? ;)

[lucassp]

Running it via a virtual machine? Ack, that'll cost you some fps.

the results are experimental, not to be added in your comparison table. :P

[graysky]

I re-ran my XP vs Vista test with a smaller source and some other modifications and finally got reliable results..

Vista seems to be reliably more inefficient than XP :) Honestly, I don't see how M$ can call it an upgrade. From what I've read it's more or less a new UI at the cost of bloat and performance.

[onix]

Hi everybody,
Nice thread you have here. Reading it I've noticed something odd: all Vista benchs are lower than XP's. And I say that's odd because the only application I've tried that actually gets a tangible boost is x264 encoding.
Since I first started testing Vista with the Beta made available in June, I've seen the OS evolve and the last free version is pretty colse to the comercial one (afaik).
RC2 has been my OS of choice for the last several months, and I've conducted tests of every kind. Differences are very small, less tha 5%, and sometimes in the 1% to 2% range. They favor XP or Vista quite evenly. I'm talking about real apps as well as synthetic tests.
With that background I was amazed to see that x264 encoding was more than 10% faster under Vista. Using different clips, the speedup ranged from 10,07% to 12,91%.
The encodes were 3-pass. I don't use the 64 bit version because I don't get the x264-64 bit to work. So it's Vista 32 for the moment. I see people here use the 64-bit version of Vista (along with the 32 bit version of x264?). It's either that or the bitrate. The speedup increases when you lower the kb/s.

[check]

are you sure your commandline was absolutely identical? Also, what specs are your two systems?

[onix]

At that time I wasn't using the CLI version, but the vfw one trough VirtualDub.
The machine is the same for both OSes, an Allendale OCed to somewhere between 3,4 and 3,6.
And yes, the parameters were the same ones.
I will check with the command line, anyhow.

[zambelli]

I re-ran my XP vs Vista test with a smaller source and some other modifications and finally got reliable results.
Thanks for sharing those results! I'd love to see more. My one concern so far: the tests compare 32-bit XP to 64-bit Vista that's running 32-bit x264 under WOW64. I'm not sure that's a true apples-to-apples comparison. It'd be great to see results for a similar test comparing 32-bit XP to 32-bit Vista.

[Selmer79]

@Zambelli
Maybe, maybe not.. I don't know.. I don't have access to 32-bit Vista, so someone else would have to test that.

[graysky]

It'll be interesting to see when vista gets a bit more polished (i.e. sp2 or so) if the CPU clock cycle efficiency improves.

[onix]

CLI testing done.
I've compressed Peter Jackson's King Kong using DVDecrypter 3.5.4, DGDecode 1.4.8 (reference idct), Avisynth 2.5.7 (bicubic resize 640x266) and x264 svn 623. This time I've tried single pass encoding:
x264 VTS_01_1.avs -o *.mp4 -B (several) --threads 3 --thread-input -b 4 --b-pyramid -A all --8x8dct -w -m 6 --b-rdo --no-psnr --no-ssim --progress
Verdict: XP is about 0.3 - 0.8% faster than Vista, I guess the rest of the difference others are getting is because of the WoW "·#*¿&
The 10 - 15% difference on the vfw version (svn 573) stands in favor of Vista, for what it's worth.

[aicjofs]

This was a fun test Graysky thanks!!!

One comment I have is that for this particular .avs it's not really showing the true CPU potential for dual cores and quad cores when compared to single cores. Using the MT.dll plugin to multi thread avisynth can really improve frame rates on a multi CPU system which is what the CPU itself is really worth. Here is an example just by adding SetMTmode(2,0) which isn't necessarily the most efficent use of the MT plugin.

For your job I see almost a 14% increase by using MT plugin.

Without MT
http://home.comcast.net/~msibios/megui.jpg

With MT
http://home.comcast.net/~msibios/megui1.jpg

Not questioning the testing, just adding to the discussion.

[graysky]

mt.dll is the key, eh? So do you make the first line of the .avs read, "SetMTmode(2,0)" or what?

I googled around and found this (http://forum.doom9.org/showthread.php?t=94996) but most of the discussion went over my head. Also found this (http://avisynth.org/mediawiki/MT_support_page). Can you post a link if you have more informative ones? Also, are there any quality sacrifices when using this plugin?

Thanks for the info and I'll update the table.

Also, what kind of setup do you have (hardware specs, mb, cooling, etc.) and what kind of temps do you see w/ 11x346? (I'm assuming you're using liquid cooling). I was planning to wait for the q6600 to drop in price in Q3 of 2007 (rumored to be under $250) and clock it @ 10x333 but I'm concerned about heat since I don't wanna mess with liquid cooling.

Thanks!

[jeffy]

mt.dll is the key, eh? So do you make the first line of the .avs read, "SetMTmode(2,0)" or what?

I googled around and found this (http://forum.doom9.org/showthread.php?t=94996) but most of the discussion went over my head. Also found this (http://avisynth.org/mediawiki/MT_support_page).
Well, you have to replace the original avisynth.dll as well. It might be good to backup the original, as I saw a new one causing some weird errors like VirtualDub crashing when loading the script, but it was some time ago and a lot of things have changed.

Basically, you found both the correct resources. The AviSynth wiki (the 2nd link) is explaining differences in MT() and SetMTMode(). However, there are still some filters that cannot be used with MT() or SetMTMode(). Besides those listed in the wiki, it's everything concerning MaskTools, such as MCBob, MVBob, MVFlowFps etc. The main thread (the 1st link) already has 25 pages so far, so take your time and read :)

E6600 9x400 OC DDR2-533@600 3.6 GHz 16,832,957, SetMTMode(2,0) as the first line of the file test-NEW.avs:
http://img2.freeimagehosting.net/uploads/3daaec3002.png

E6600 9x400 OC DDR2-533@600 3.6 GHz 16,832,604, normal test-NEW.avs:
http://img2.freeimagehosting.net/uploads/7cec7d5d87.png


With my configuration, SetMTMode() is slower :p.

A note: Please do not compare my previous results, I have used a brand new r635 of x264 with this test (manually replaced in megui directory).

[graysky]

Cool man, thanks for the info

[aicjofs]

Looks like you found the info on MT avisynth. I'm suprised Jeffy got lower scores. Yes I just used SetMTmode(2,0) at the beginning of the script. More efficent usage would be changing the various modes throughout the script depending on filters. I'm not strong on avisynth myself. I have the filters I use for movies, and cartoons and my templates and I don't deviate much, but what I do know is I get alot better speed with MT avisynth. In fact my framerates are still climbing on the 1st pass of the test job but it's over too quickly so it's hard to say if it's a good average or not.

For hardware(since Jeffy and Graysky asked me for some detail):

CPU: QX6700 2.66Ghz
Motherboard: Intel BadAxe2 (975 chipset)
RAM: 2x1GB Crucial PC2-8000 (DDR1000)
Hard Drive : 3x Seagate 7200.10 320GB RAID 0
Power Supply : PC Power and Cooling 610W
Video: 8800GTS 320MB (oh boy HDCP... yippy!)
Sound: X-FI
Cooling: Water
CPU block: DTek Fusion
Pump: Iwaki MD-20 high head impellar
Radiator: Thermochill PA120.3
Rad Fans: 4x Yate Loon 120mmx25mm ML

Vcore: 1.5V
Vdimm: 2.2V
Vmch : 1.55V
Vfsb : 1.3V

Idle via CoreTemp: ~40C
Load via CoreTemp: ~61C

Here's the Guts:

http://home.comcast.net/~msibios/DCP02502.JPG

and the external water cooling

http://home.comcast.net/~msibios/DCP02503.JPG

Yeah I've heard prices of $250 for the Q6600 are coming soon. You might get 3.3 with excellent air cooling. I have been overclocking since Pentium 1/K-6 days, and I have never seen the heat these puppies can put out. I just built a water cooling rig for a friend and it has weak watercooling in it and I can't get more then about 3.33-3.4 stable on his QX6700 at it loads at 71C now.(keep in mind it's average watercooling at best).

A look at the sub par cooling for quad:

(notice how much better I made his look then my own...my theory the better it looks the worse she runs...LOL..j/k)

http://home.comcast.net/~msibios/DCP02445.JPG

[jeffy]

aicjofs, thank you very much!
Now, That's What I Call A Detailed Setup :)

[graysky]

Yeah, ditto. I'm pretty sure you have my case judging by those pics btw! I've had mine for over 5 years and can't remember the model number. Do you know?

Also, any idea what kind of temps I could expect using a q6600 @ 9x333 cooled with air? I'm planning to get the thermalright ultra-120 + scythe s-flex sff21f fan as the hsf and use it in a well ventilated case like the antec p180. Problem I'm having with a quad processor is that I know they tend to run hot and room temp will probably be 75-77F for the next 4-5 months since summer is right around the corner. I'm not looking to squeeze every MHz out of the thing, and think that the stock multiplier x 333 would be as high as I push it since I'm planning to run it 24/7.

If the q6600 is gonna run over 60C @ load with my hardware given those room temp numbers, I'm thinking either a e6600 @ 9x333 or a e6700 @ 10x333. The key for me is decent load temps whatever I end up getting cooled on air.

Thanks for any info and for that pretty detailed reply!

[jeffy]

--> pointing you all the way to the fellows at XtremeSystems.org -->

Q6600/6700 mixed

Water less than 50C/60C
http://www.xtremesystems.org/forums/showthread.php?t=126820&highlight=Q6600

Tuniq Tower 120
About 70C
http://www.xtremesystems.org/forums/showthread.php?t=126900&highlight=Q6600

Or 40C idle/70C load (http://www.xtremesystems.org/forums/showpost.php?p=1961752&postcount=22)
http://www.xtremesystems.org/forums/showthread.php?t=130549&highlight=Q6600

Even water can go to 70C
http://www.xtremesystems.org/forums/showthread.php?t=127964&highlight=Q6600

And again watercooled 40C idle/60C load
http://www.xtremesystems.org/forums/showthread.php?t=122350&highlight=Q6600

And here comes the heavyweight, air cooling "monster"
50C/full load 80C overclocked! (http://www.xtremesystems.org/forums/showpost.php?p=1986126&postcount=29)
http://www.xtremesystems.org/forums/showthread.php?t=132058&highlight=Q6600
(he used 36dB fans though)

But you should remember their TJunction is higher than C2Ds: 100C vs. 85C

A really great discussion here (p. 2, 70C Tuniq Tower):
http://forumz.tomshardware.com/hardware/QX6700-Tjunction-Tcase-safe-ftopict227618.html

[graysky]

Thanks for the links man! I'll dig into them. BTW, here's a related article (http://www.tomshardware.com/2007/03/26/the_gigahertz_battle/) that just published.

[tsp]

graysky: Do you plan to repost the test file?

[graysky]

Done: test files (http://home.insightbb.com/~pixels/test_encode/test.rar)
and
avisynth plugins if you need them (http://home.insightbb.com/~pixels/test_encode/test-plugins.rar)

Remember to read the instructions.txt in the rar file and be sure to grab the older version of x264.exe (also in the instructions.txt).

[HookedOnTV]

Opteron 165 - 2.48GHz (9 x 275) - 1GB DDR550

http://www.hookedontv.com/test_encode.jpg

[graysky]

updated

[aicjofs]

Been wondering about the Vista stuff myself...so...

Here is my Vista comparison. I tried to match the running services of XP and Vista as close as possible. Vista sidebar is turned off. Aero skin is on. XP install is 2 weeks old, Vista install 1 day old. Both using old x264 for this test, and exact same filters.

MT OFF

http://home.comcast.net/~msibios/vista1.jpg

MT ON

http://home.comcast.net/~msibios/vista.jpg

Old results of course were here http://forum.doom9.org/showthread.php?p=975017#post975017

So we have

Without MT Avisynth

XP
1st pass 121.2
2nd pass 55.01

Vista
1st pass 123.67
2nd pass 53.16

With MT Avisynth

XP
1st pass 138.16
2nd pass 54.15

Vista
1st pass 147.91
2nd pass 53.78

Looks like without MT avisynth it is a wash. Gain 2fps, lose 2fps. With MT, it would seem a huge increase on the 1st pass almost a wash with 2nd pass. Like I mentioned before I wonder how accurate the 1st pass numbers really are since it happens so fast and the framerate hasn't really stabalized. Makes me want to not believe the numbers and only look at 2nd pass in which case Vista is ever so slightly slower.

Anyway food for thought. If you believe the numbers, At least on this quadcore, at this speed, it would seem Vista and MT avisynth are the way to go if using these filters. Either that or that .1Mhz of memory is the difference. LOL

[morph166955]

ok so I lied...I ended up not going with the 1.86 or the 2.33...I went with the 2.66 :devil:

The final parts list (all of this is ordered, half is in already):

Moved to new thread @ http://forum.doom9.org/showthread.php?t=124099 because it diverged too much from this one plus its more visibile there for people looking for other non MeGUI tests.

[Selmer79]

Been wondering about the Vista stuff myself...so...

Here is my Vista comparison. I tried to match the running services of XP and Vista as close as possible. Vista sidebar is turned off. Aero skin is on. XP install is 2 weeks old, Vista install 1 day old. Both using old x264 for this test, and exact same filters.

32-bit or 64-bit Vista?

Also, if you want to expand the test (to stabilize the numbers a bit), do like me and make your own test with a larger source..

Just look here (http://forum.doom9.org/showpost.php?p=963856&postcount=192) and then here (http://forum.doom9.org/showpost.php?p=965573&postcount=223)..

[aicjofs]

Good catch. 32bit Vista, since I was using 32bit XP.

No doubt a longer source would help out for these side tests. I'll give it a go when time permits.

[Selmer79]

The reason why I asked was that some person wondered if running a 32-bit application under 64-bit Vista would be a cause for reduced performance.. I'll be repeating my test later when I feel Vista is more mature (and/or a "64-bit meGUI" comes).

PS: I know that a 64-bit meGUI won't help unless everything that meGUI accesses is 64-bit too.

[tsp]

opteron 165 8x300 MHz =2.4 GHz 3 GB ram (but windows xp only detect 2.5 :( )
http://img379.imageshack.us/img379/6404/meguihl3.png
And yes the voltage is wrong. Should be 1.4 V

aicjofs: The MT numbers on vista could be correct as the multithreading support has been improved with vista

[graysky]

@ tsp: FSB to DRAM = CPU/12? Is it 3:2 ?

[tsp]

graysky: yes 12:8 -> 3:2

[squid_80]

PS: I know that a 64-bit meGUI won't help unless everything that meGUI accesses is 64-bit too.
64-bit test results (XP64 with 64-bit MeGUI, plugins and x264.exe) for an E6600 (9x266, 5-6-6-18): fps1 = 53.33, fps2 = 17.34.

[graysky]

@tsp: sorry it took me so long but I finally updated the chart w/ your result.

@ squid_80: interesting that your XP64 results are more or less identical to other 9x266 chips such as darkstar's result.

[morph166955]

to make sure that it worked for when I want to run it on the octa-core later in the week I ran your test on my Lenovo X60 Laptop w/Core2 Duo T7200. Here are the results for ya so you can add it to your list. I tried to shut off as much as I could but I'm sure there was a few thing slowing this machine down...I'm going to format this laptop in the next month I'll rerun it once I get to that point.

EDIT: forgot to say machine is windows xp 32-bit in case that matters for you

[Selmer79]

And yes the voltage is wrong. Should be 1.4V
Updating CPU-Z might help.. ;) Latest version is 1.39, you're running 1.33.1..

Get it here: http://www.cpuid.com/download/cpu-z-139.zip

[HookedOnTV]

The memory timings listed next to my numbers aren't mine. Forgot to submit them.

1:1 @ 3-4-4-10

[graysky]

@morph166955: thanks for the first merom data point, added
@ HOT: fixed

[morph166955]

im loading xp on the 8-core tomorrow...i should have some results for you all then :-D. just for a hint...i loaded freebsd 64-bit on it just now...holy hell its fast (and seeing a 7 under the cpuid column when using top is kinda cool)

[morph166955]

ok so the test has officially been run...sadly the test didnt par up to what the computer could do. x264 only ran at 38% on the first pass...did 82.55fps. couldnt coax it to do more. it did manage to run at 95%+ on the second pass and got me 68.1fps. I'm going to try to tune this box a little to see what it can do though...i think 68.1 is kinda lacking...im shooting for 80 or so minimum.

[morph166955]

THANK GOD FOR MT.DLL!!!

First Pass: 142.59FPS!!!
Second Pass: 70.34FPS!!!

mt.dll pegged the cpu above 95% for both passes. I'm going to run it with the brand spanking new x264 to see what it does. (oh and the cpu has that speedstep technology so ignore that it says 1999MHz on the cpuinfo page...it stepped down from 8.0x to 6.0x when its idle)

http://www.benswebs.com/public/pictures/meguitest.JPG

[tsp]

hmm x264 and avisynth MT doesn't scale to well with so many cores... but still very very fast.

[morph166955]

doesnt scale well? the closest thing to that is an overclocked QX6700 which was set at 3.8GHz which was still 20 fps under that. an equivalent QX6700 at 2.66GHz hit almost exactly half of of what I hit. I'd say it scalled pretty damn well

[Blue_MiSfit]

insert insane, slack-jawed, drooling jealousy here.

You can actually encode HD H.264 in a reasonable amount of time now!

~MiSfit

[tsp]

doesnt scale well? the closest thing to that is an overclocked QX6700 which was set at 3.8GHz which was still 20 fps under that. an equivalent QX6700 at 2.66GHz hit almost exactly half of of what I hit. I'd say it scalled pretty damn well

well if we compare your result without avisynth mt with darkstar782 (core2duo 2.66 GHz) and drjay (qx6700 2.66 GHz) the framerate only increases with 66 % every time the number of cores is doubled shown in this graph:
http://img46.imageshack.us/img46/191/scalingfj5.jpg
You could try to disable some of the cores(/NUMPROC= switch in boot.ini (http://www.microsoft.com/technet/sysinternals/information/bootini.mspx)) to see how it scales with avisynth mt as there are not enough data in this thread to create a similar comparison(but going from 82.55 fps with 35 % cpu utilization to 142.59 fps with >95 % cpu utilization is not perfect scaling(should be more like 225 fps) but that must be the creator of mt.dll fault :) )

[graysky]

Is the inefficient scaling a function of an inefficient OS? I think morph166955 needs to rip a DVD and encode the mpg stream under BSD and then use the same commandline options for x264.exe under windows and compare the two results. I'll bet dollars to doughnuts the NIX will do a more efficient job... you up to it dude?

[graysky]

updated the table

[tsp]

Is the inefficient scaling a function of an inefficient OS? I think morph166955 needs to rip a DVD and encode the mpg stream under BSD and then use the same commandline options for x264.exe under windows and compare the two results. I'll bet dollars to doughnuts the NIX will do a more efficient job... you up to it dude?
well as avisynth 2.5 currently is not available for NIX it is difficult to compare this result. It would require a new test case without avisynth but I believe it is more x264 fault than windows as it is not easy to create an application that scales well when only working with 1 frame.

[morph166955]

awe ya only stuck my non mt.dll line in there...looks so weak in comparison to the others. I think that for the systems that run a significant amount of cores that mt.dll runs should be included (and labeled so people know) since its obvious that megui/avisynth is not run at anywhere near its potential and its choking x264.

[morph166955]

well as avisynth 2.5 currently is not available for NIX it is difficult to compare this result. It would require a new test case without avisynth but I believe it is more x264 fault than windows as it is not easy to create an application that scales well when only working with 1 frame.

well i suspose i could do a run using mencoder and have it set to do the resize/deint and all that the avisynth script does. i think that in comparison the actual x264 encode is doing a hell of a lot more usage wize then the resize/deint is. i'm down in florida right now but i'm terminaled into the server installing things so depending how fast they go (and let me tell you...they are going FAST...gcc 4.1.2 w/ c & c++ compiled in under 10 minutes!) i'll do my best to duplicate the tests. the other option i suspose is to resize/deint the image to raw YUV 4:2:0 file and feed that into x264 with the options used in the jobs. ill keep yall updated.

[graysky]

I don't think you need the resize in there at all since you just want to compare the two OS's ability to handle 8 cores. I think a straight encode would work just fine. I would suggest you just rip a VOB from any DVD and rename it to .mpg since it's an mpeg-2 stream which I think x264 can use as an input and simply encode it to whatever options you want under BSD and compare the encode time to the same thing under windows keeping avisynth out of the picture all together. I took this example from my logs as a suggested output:

Pass1: x264 --pass 1 --bitrate 1582 --stats "D:\work\pass1.stats" --bframes 3 --b-pyramid --direct auto --subme 1 --analyse none --vbv-maxrate 25000 --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output NUL "D:\work\input.mpg"

Pass2:x264 --pass 2 --bitrate 1582 --stats "D:\work\pass1.stats" --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-input --sar 40:33 --progress --no-psnr --no-ssim --output "D:\work\2ndpass.mkv" "D:\work\input.mpg"

[graysky]

I added the two mt.dll results we have to the first post in their own table.

@morph: what line did you add to your avs when you did your mt.dll test? For example, aicjofs used this line to the avs file: SetMTmode(2,0) and I wanna at least track the results people are getting with their settings.

[ditche]

Updated.

http://users.skynet.be/bk314761/megui03.png
http://users.skynet.be/bk314761/megui04.png

[aicjofs]

I ran some more tests since Tsp felt we didn't have enough info to draw conclusions about MT scaling.

I set QX6700 to default 2.66 and ran a quadcore test, and then disabled multiplexing(quad runs as only a dual core and will give rough dual core result) with MT.dll runs. Only issue here is RAM is now 400 4-4-4, instead of 519 4-4-4.

2.66 quad MT 103.38 37.79
2.66 dual MT 59.17 19.12

It really appears to me the gains for MT.dll are minimal for dual core and start increasing for quad core and more. At least I didn't see the benefit during this test of MT for dual core.

but going from 82.55 fps with 35 % cpu utilization to 142.59 fps with >95 % cpu utilization is not perfect scaling(should be more like 225 fps)

for 1st pass I still worry about the accruacy of this since it completes before frame rates have stabilized and I'm not sure frame rates rise in a linear fashion from start to maximum. This can skew the results. i.e. perhaps his avg framerate for a longer test would be closer to 225. Who knows...

I think that for the systems that run a significant amount of cores that mt.dll runs should be included (and labeled so people know) since its obvious that megui/avisynth is not run at anywhere near its potential and its choking x264.

Agreed. That's why I mentioned it in this thread, and we have got some good data already that shows the benefits for numerous cores. Really helps put all of this great data submitted by people into perspective we all get something out of.

I also ran some more Vista testing MT, noMT, stock speed, quad core, dual core, etc. Here is a summary of everything ran thus far.


XP

3.8 quad MT 138.16 54.15 10sec 28sec
3.8 quad noMT 121.20 55.01 12sec 27sec
2.66 quad MT 103.38 37.79 15sec 39sec
2.66 quad noMT 86.74 37.91 17sec 39sec
2.66 dual MT 59.17 19.12 24sec 77sec
2.66 dual noMT 58.78 19.28 25sec 77sec


VISTA

3.8 quad MT 147.91 53.78 10sec 29sec
3.8 quad noMT 123.67 53.16 12sec 27sec
2.66 quad MT 105.67 38.28 14sec 39sec
2.66 quad noMT 86.26 38.54 17sec 39sec
2.66 dual MT 59.33 19.22 25sec 77sec
2.66 dual noMT 58.6 19.13 25sec 77sec

[HookedOnTV]

...It really appears to me the gains for MT.dll are minimal for dual core and start increasing for quad core and more. At least I didn't see the benefit during this test of MT for dual core.

I did a test run with MT on my dual core and the total time ended up exactly the same.

[Blue_MiSfit]

MT AviSynth is only really necessary when you have enough CPU power to make non MT AviSynth the bottleneck.

It makes a HUGE difference when you are doing less intensive encoding tasks, like CCE, which can easily run 120+fps on a quad core system with a basic AviSynth script. x264 is so CPU intensive that MT doesn't help that much with most pedestrian dual cores, but with the big boys it can make a world of difference, depending on your script complexity and x264 configuration.

Now, if only it worked with MVTools :D

~MiSfit

[morph166955]

I added the two mt.dll results we have to the first post in their own table.

@morph: what line did you add to your avs when you did your mt.dll test? For example, aicjofs used this line to the avs file: SetMTmode(2,0) and I wanna at least track the results people are getting with their settings.

same line as aicjofs. I wasnt very familiar with the plugin since i rarely use avisynth so I just went with the same thing. is there anything I should change to make it faster?

[morph166955]

for 1st pass I still worry about the accruacy of this since it completes before frame rates have stabilized and I'm not sure frame rates rise in a linear fashion from start to maximum. This can skew the results. i.e. perhaps his avg framerate for a longer test would be closer to 225. Who knows...


I'm going to run some dvd rips through this thing tomorrow once i'm home from florida to get a nice stable rate. I think that for us crazy high core/speed systems we need a much longer source to run off of (and possibly an HD source). I'll do up something in the next few days (moving back to school so i may be delayed a little) for the quad core people to test on (assuming im the only octacore setup out there at the moment thats running these tests.)

[graysky]

Cool let us know how it goes.

[squid_80]

I would suggest you just rip a VOB from any DVD and rename it to .mpg since it's an mpeg-2 stream which I think x264 can use as an input and simply encode it to whatever options you want under BSD and compare the encode time to the same thing under windows keeping avisynth out of the picture all together. No way does x264 accept mpg as input.

[morph166955]

im movin back up to school today and im having an issue getting mplayer to compile in 64 bit (and im having some issues using -m32 on gcc for it also...thats probably my fault though for not having the proper 32 bit libraries floating around). I'll be tinkering with it tonight and over the next few days though. If anyones got some suggestions on what to do please let me know...im getting assembly errors that are something like "xxx is not a valid 64 bit register" or something like that. im pretty sure I have to build binutils in 32 bit mode to get those libraries but im not 100% sure. as for source, ill either pipe my source through mencoder to do x264 or I'll create a YUV 4:2:0 raw source for it to read out of or something like that.

EDIT: just got to school, and i got mplayer to compile...had to update the decrepidly old version of binutils that bsd64 comes with. I'm installing samba now so that I can copy files to the box easier. I should have results shortly on manual x264 passes with the same source.

[morph166955]

using mencoder and the settings from job 2 I am now a firm believer that the video source were using is no where near whats needed to stabilize a framerate. according to i hit 179.37 fps on the first pass which took 10.413 seconds and the frame rate was still climbing when it ended. im going to try a pass on a VOB now...be back soon

[graysky]

Interesting. Using pretty fast dualcore chips, many users have been able to get highly reproducible result with it. Your machine with 8 cores on the other hand might be the exception :)

What happens when you run the same encode several times (179.37 fps or near that each time?)

[morph166955]

i get with in 1-2 fps of that each run. what i did notice is that i am once again limited by the encoder not running in multi-thread mode (i believe its mencoder this time). im only using the cpu's at 38% total on that first pass...and thats at 170+ FPS! im converting the video into a YUV 4:2:0 raw video to pipe directly to x264...god help us all

[morph166955]

ok so heres the results using freebsd, x264 r647 and the source video in raw YUV format thats resized thanks to mplayer set as close to the settings of the avs file as I could get. the times are generated using the simple gnu time command. processes were run using "nice -n -20 time x264...". Source was stored in a ramdisk for maximum speed. I realize this isnt 100% accurate to what the offical test is running but I believe its a good source of info to base theory off of. I'm trying to figure out why x264 isnt doing threaded input on this file, its kinda weird to me and I believe its because its not using avisynth as the input source. I'm looking into avisynth 3.0 since it is written to run in linux. that may help.

pass 1:
encoded 1486 frames, 120.76 fps, 995.46 kb/s
12.38 real 29.65 user 3.76 sys

pass 2:
encoded 1486 frames, 93.30 fps, 1009.21 kb/s
16.08 real 83.08 user 2.10 sys

[morph166955]

So I got some linux runs for you guys to contimplate over. The way these were generated was by using my xp laptop and mencoder to generate the sourcefile from the benchmarks avs file (converted it into a raw yuv file for x264 to use). once I got that file built I copied it onto my linux setup (im now running fedora core 6 because of smp/thread problems with bsd) and then used x264 with the exact options (i changed the stats file location but thats it) out of the job1-2 and job1-3 files. I had a script run the two x264 passes 10 times. below are the fps/times from all the first passes and then all the second passes. You must divide the CPU % by 8 (i believe its 8 not 10) to get the average CPU usage per core. As you can see my first pass is only getting ~45% avg cpu usage and my second pass is getting ~80% avg cpu usage. I'm trying to get this to go faster but I'm not sure what more I can do. Piping the video through mencoder using the comparable video filters gets me about the same cpu utilizations and frame rates.


PASS1:
encoded 1488 frames, 189.16 fps, 989.84 kb/s
27.75user 0.42system 0:07.87elapsed 357%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 182.12 fps, 989.84 kb/s
28.00user 0.41system 0:08.17elapsed 347%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 187.77 fps, 989.84 kb/s
27.84user 0.41system 0:07.93elapsed 356%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 188.89 fps, 989.84 kb/s
27.83user 0.46system 0:07.88elapsed 358%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 188.22 fps, 989.84 kb/s
27.87user 0.42system 0:07.91elapsed 357%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 187.57 fps, 989.84 kb/s
27.79user 0.40system 0:07.94elapsed 355%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 185.17 fps, 989.84 kb/s
27.85user 0.41system 0:08.04elapsed 351%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 187.65 fps, 989.84 kb/s
27.78user 0.46system 0:07.93elapsed 356%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 185.20 fps, 989.84 kb/s
27.72user 0.42system 0:08.04elapsed 350%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 188.29 fps, 989.84 kb/s
27.77user 0.44system 0:07.91elapsed 356%CPU (0avgtext+0avgdata 0maxresident)k

PASS2:
encoded 1488 frames, 116.38 fps, 1009.85 kb/s
84.39user 0.90system 0:12.87elapsed 662%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 116.82 fps, 1009.74 kb/s
84.26user 0.91system 0:12.82elapsed 664%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 116.19 fps, 1009.75 kb/s
84.25user 0.90system 0:12.88elapsed 660%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 116.74 fps, 1009.39 kb/s
84.41user 0.91system 0:12.83elapsed 665%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 116.34 fps, 1009.38 kb/s
84.42user 0.84system 0:12.87elapsed 662%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 116.08 fps, 1009.44 kb/s
84.27user 0.93system 0:12.90elapsed 660%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 116.15 fps, 1009.78 kb/s
84.28user 0.89system 0:12.89elapsed 660%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 115.93 fps, 1009.79 kb/s
84.22user 0.92system 0:12.91elapsed 659%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 115.99 fps, 1009.38 kb/s
84.24user 0.87system 0:12.91elapsed 659%CPU (0avgtext+0avgdata 0maxresident)k
encoded 1488 frames, 115.59 fps, 1009.48 kb/s
84.33user 0.87system 0:12.95elapsed 657%CPU (0avgtext+0avgdata 0maxresident)k

[graysky]

Pretty fast numbers, too bad you can max it out. To put things in to prospective for me anyway, I'm using my Athlon XP 3200+ to encode some movies so I can watch them on my laptop. I'm getting about 23 fps on the first pass and 5 fps on the second!

[rakan]

I get an error when I try to run this on my machine. It compresses the audio file fine but runs into an error on the first pass. Here is a printout of my log...

Looking for job processor for job...
Processor found!
Starting job job1-1 at 11:44:30 PM
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:

successfully started encoding
Processing ended at 11:44:36 PM
----------------------------------------------------------------------------------------------------------

Log for job job1-1

Channels=2, BitsPerSample=16, SampleRate=48000Hz
C:\Program Files\megui\tools\lame\lame.exe --abr 128 -h --silent - "C:\work\test-new T01 DELAY 0ms.mp3"
----------------------------------------------------------------------------------------------------------
Starting postprocessing of job...
Job completed successfully and deletion of intermediate files is activated
Postprocessing finished!
Looking for job processor for job...
Processor found!
Starting job job1-2 at 11:44:36 PM
Starting preprocessing of job...
Job 'job1-2' requires bitrate calculation. Calculating now...
Found another video job: job1-3.
Found audio stream: job1-1.
The video job has a desired final output size of 16777216 bytes and video bitrate of 1000kbit/s
Examining audio jobs found...
Audio job 'job1-1':
This job completed successfully, taking size into account...The size is of this track is 906648 bytes, and the type is MP3. Taking this into account in the bitrate calculation.
Desired video size after substracting audio size is 15483KBs. Setting the desired bitrate of the subsequent video jobs to 2045 kbit/s.
Preprocessing finished!
Calling setup of processor failed with error The file C:\work\test-NEW.avs cannot be opened.
Error message for your reference: Script error: there is no function named "Spline36Resize"
(C:\work\test-NEW.avs, line 8)

It's how would I fix this? I put the appropriate DLL files in the avisynth plugins directory.

[graysky]

Interesting... it seems to be complaining about the resize step. I thought the resize functions were built into the app (i.e. didn't require a plugin). Are you using the latest version of Avisynth? If so, can you post the contents of your /avisynth/plugins dir here. Do it like this:

-open a console window (start>run type cmd and hit ok)
-cd to your avisynth plugins dir like cd "Program files\avisynth\plugins"
-type the following: dir > list.txt
then open the list.txt file and paste it in here. Here is mine for comparison:
Directory of C:\Program Files\AviSynth 2.5\plugins
12/24/2006 05:12 AM 24,576 DirectShowSource.dll
12/24/2006 05:12 AM 112,640 TCPDeliver.dll
07/05/2005 08:04 AM 7,129 colors_rgb.avsi
03/15/2007 03:00 PM 69,632 FluxSmooth.dll
03/15/2007 03:00 PM 2,541 Convolution3DYV12.txt
03/15/2007 03:00 PM 7,530 Convolution3d.txt
03/15/2007 03:00 PM 57,344 Convolution3DYV12.dll
03/15/2007 03:00 PM 53,248 UnDot.dll
03/15/2007 03:00 PM 2,640 Readme_UnDot.txt
03/15/2007 03:00 PM 6,456 readme.html
03/15/2007 03:00 PM 90,112 EEDI2.dll
03/15/2007 03:00 PM 5,301 README.txt
03/15/2007 03:00 PM 86,016 Decomb.dll
03/15/2007 03:00 PM 10,929 DecombFAQ.html
03/15/2007 03:00 PM 45,802 DecombReferenceManual.html
03/15/2007 03:00 PM 11,992 DecombTutorial.html
03/15/2007 03:00 PM 319,488 LeakKernelDeint.dll
03/15/2007 03:00 PM 7,670 LeakKernelDeintHelp.html
03/15/2007 03:00 PM 704,596 TomsMoComp.dll
03/15/2007 03:00 PM 188,416 TDeint.dll
03/15/2007 03:00 PM 36,189 tdeint.htm
03/15/2007 03:00 PM 48,285 TFM - READ ME.txt
03/15/2007 03:00 PM 1,883 TIVTC - READ ME.txt
03/15/2007 03:00 PM 444,416 TIVTC.dll
03/15/2007 03:00 PM 2,233 FieldDiff - READ ME.txt
03/15/2007 03:00 PM 5,391 FrameDiff - READ ME.txt
03/15/2007 03:00 PM 2,319 MergeHints - READ ME.txt
03/15/2007 03:00 PM 3,296 RequestLinear - READ ME.txt
03/15/2007 03:00 PM 7,396 ShowCombedTIVTC - READ ME.txt
03/15/2007 03:00 PM 44,117 TDecimate - READ ME.txt
03/15/2007 03:00 PM 27,827 DGDecodeManual.html
03/15/2007 03:00 PM 221,262 DGDecode.dll
03/15/2007 03:00 PM 7,712 Readme_SimpleResize.txt
03/15/2007 03:00 PM 102,400 ColorMatrix.dll
03/15/2007 03:00 PM 454,656 NicAudio.dll
03/15/2007 03:00 PM 1,343 NicAudio_Readme.txt
03/15/2007 03:00 PM 61,440 SimpleResize.dll

[rakan]

Thanks for your help graysky,

I uninstalled Avisynth, uinstalled MeGUI, and reinstalled both and updated the plugins as you instructions.txt said and everything works.:)

[graysky]

Cool, I'll add your results when you post them. Be sure you're using the older version of x264.exe as mentioned in the instructions.txt so your results match the others in the table.

[graysky]

Updated the table with my new quad core system (Q6600); it's literally over 5x faster than my aged Athlon XP. Thanks to all who participated in this little thread that grew into a monster here!

[graysky]

But you should remember their TJunction is higher than C2Ds: 100C vs. 85C

Jeffy: what is your source for that statement?

[jeffy]

Jeffy: what is your source for that statement?
However, there is a problem. That reading although available in °C is _relative_ to the Tjunction which is CPU specific. For some models it is 100°C for others it is 85°C.
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30222546.aspx

(I) Core Temp 0.9X Tjunction 85c or 100c is Intel’s Tj max spec, is not a temp, and doesn't change.
http://forumz.tomshardware.com/hardware/Core-Duo-Temperature-Guide-ftopict221745.html


But to be clear, here is:

Some steppings of the mobile Intel® Core™2 processor do indicate Tj to be approximately 85 or 100 via a single bit in the EXT_CONFIG register (msr 0EEh) but desktop, workstation and server processors do not. Nor is there a register implemented in those processors that software can read to get the Tj value for either the Pentium® 4 processor, Intel® Xeon® processors or Intel® Core™2 processors.

http://softwarecommunity.intel.com/isn/Community/en-US/forums/post/30230975.aspx
The above statement is (according to http://softwarecommunity.intel.com/isn/Community/en-US/forums/permalink/30222546/30231056/ShowThread.aspx#30231056): "Note that the information in the post immediately before this one came from Intel, specifically from one of our internal contacts for the processor documentation, and is what we have been working with our friends on the hardware design side of Intel to get for you."


In all implementations the IA21_THERM_STATUS[22:16] value is relative to PROCHOT assertion and not an absolute temperature.


No, quite higher than that. Tjunction is 100 C on quads.
http://www.xtremesystems.org/forums/showthread.php?t=139857&page=2



Regarding the Intel's note: there probably isn't much more available, AFAIK, for a general public/whoever who didn't sign the NDA as a company.

So until there is more information publicly available, I have to take the value shown in CoreTemp as the correct value, which is 100°C for Intel quad-cores and 85°C for most Intel dual-cores.

[graysky]

Wow, as usual thanks kindly for the very detailed reply (and with references to boot!) Too bad this small piece of info isn't officially published somewhere. I've been shooting for a TAT temp of 65C which limits my o/c to 9x333 but I'm sure it could do 9x400 or more (others are doing it). Oh well, 9x333 is over 5x faster than my old PC :p

[Blue_MiSfit]

I got a new 3800+ X2 Toledo today :)

Here's some benchies:

Old CPU (3500+, @ standard 2.2GHz)
http://img479.imageshack.us/img479/4651/3500stockmq2.png (http://imageshack.us)

New CPU (3800+ Dual Core @ standard 2.0GHz)
http://img267.imageshack.us/img267/8302/3800x2stocksl8.png (http://imageshack.us)

New CPU (3800+ Dual Core @ 2.45 GHz :))
http://img267.imageshack.us/img267/1365/3800at245ghzri5.png (http://imageshack.us)

I'm also (as a test) re-encoding some 1080p footage (QuickTime trailer, H.264 @ 10mbps) into CRF22 x264, high profile with all the usual fancy settings. Averaging 2fps using DGAVCDecode to feed AviSynth. This will be better soon (I think).

~MiSfit

[delacroixp]

A bit similar to x264 multi-core (4+) threading optimization (http://forum.doom9.org/showthread.php?t=124557) ...

I'll certainly recommend the same at AutoMKV ...

@graysky
Gr8 rig...


:):D:eek:
Pascal

[graysky]

Updated

[0gg]

Is it possible to post here the avs code of the best quality you have in Multithread (for a 8 cores, Clovertown), for a SD (720x576) video with wav sound ?

Filter :
Desenterlace
No Crop

Thx

[graysky]

@ogg: that's going to vary depending on the source. The key to using multithreads is the in the commandline for x264.exe.

The --threads auto switch should take care of it. Have a look at the job1-3.xml file in the rar to see what I mean. Have you tried the test encode contained in the first post of this thread?

[0gg]

the test encode contained in the first post of this thread

but the avs fil isn't for multithread : I don't see MT(2,0) and I don't know where I have to write it :(

I encode not very quickly with my octocore @ 2,9 :(:(:(

So, what can I do to optimise ?

My source is a Quicktime DV PAL (720x576 lower field) with .mov extension

[graysky]

Well, the avs IS for multithreaded. If you edit the job1-x.xml in notepad, you'll see the --threads auto switch as well as the <NbThreads>0</NbThreads> tag.

MT.dll will allow some plugins to go faster, but the actual x264.exe won't benefit from them.

Please post your FPS1 and FPS2 using the unmodified jobs files. If you look in the table, morph has a 8-core system with some data in there.

[0gg]

FPS1 = 81,86 / (80,17 with <NbThreads>8</NbThreads>)
FPS2 = 68,35 / (70,27 with <NbThreads>8</NbThreads>)

2x Xeon Clovertown 5330ES @2,66
2x1 Go Ram Crucial PC667 FBDIMM
Maxtor 146 Go 15k
Vista Ultimate 64b

morph has : fps1 = 143 / fps2 = 70 with the mt.dll

I will like to have the same performances by using mt.dll .... but I don't understand how to do :(

[aicjofs]

Grab MT.dll and modded avisynth here. 6th down I think.

http://avisynth.org/tsp/

then add it first line to test-NEW.avs in the "work" folder from graysky's first post of the thread.

SetMTMode(2,0)
global MeGUI_darx = 4
global MeGUI_dary = 3
DGDecode_mpeg2source("C:\work\test-new.d2v")
AssumeTFF()
Telecide(guide=1,post=2,vthresh=35) # IVTC
Decimate(quality=3) # remove dup. frames
crop( 2, 0, -10, -4)
Spline36Resize(640,480) # Spline36 (Neutral)

That's the simple way for this test. Each filter can use a different mode of the MT.dll and for true optimization would be set accordingly throughout the code on a per filter basis, but for a 4 or 8 core setup SetMTMode(2,0) is the easiest/quickest way to get a good boost. For an 8 core system in still seems x264 is limiting factor with the current implementation. There is some good work going on in that department up in the AVC section of the forum.

[0gg]

I did what you said

but I have an error :


Log for job job1-2

avis [error]: unsupported input format (DIB )
x264 [error]: could not open input file 'C:\work\test-NEW.avs'

----------------------------------------------------------------------------------------------------------
The current job contains errors. Skipping chained jobs

... what is the problem ?

[foxyshadis]

Open it up in virtualdub and find out. (DIB ) format means an avisynth error.

[0gg]

I don't understand : what files do you want me to open in virtual dub ??

[jeffy]

could not open input file 'C:\work\test-NEW.avs'


You should try to open the file 'C:\work\test-NEW.avs'.

[graysky]

@Ogg - updated the table in the first thread w/ your results. Also, did you get the mt version of avisynth to work?

[0gg]

virtualdub bugs too :
http://4u9ur.free.fr/images/VBError.gif

the mt.dll is in the avisynth plugin folder ....

[tsp]

0gg: you need to copy the supplied avisynth.dll file in the mt package to the windows\system32 directory and overwrite the default avisynth.dll file. (as the setmtfmode function is inside avisynth.dll)

[0gg]

ok so, on vista 64bits, the dll have to be in Windows\SysWOW64

job 1-1 : ok
job 1-2 :
fps up to 143.13 and at the middle of process, fps get down and then, nothing ! (with default video profile)

Starting job job1-2 at 20:45:41
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
--pass 1 --bitrate 2040 --stats "C:\work\test-NEW.stats" --bframes 3 --b-pyramid --direct auto --subme 1 --analyse none --vbv-maxrate 25000 --me dia --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim --output NUL "C:\work\test-NEW.avs"
successfully started encoding

[graysky]

No idea man... what if you use a DVD source and do nothing but x264 like this:

DGDecode_mpeg2source("D:\source.d2v")

Does it use all 8 cores then?

[0gg]

I use this .avs (yours + SetMTmode)
SetMTMode(2,0)
global MeGUI_darx = 4
global MeGUI_dary = 3
DGDecode_mpeg2source("C:\work\test-new.d2v")
AssumeTFF()
Telecide(guide=1,post=2,vthresh=35) # IVTC
Decimate(quality=3) # remove dup. frames
crop( 2, 0, -10, -4)
Spline36Resize(640,480) # Spline36 (Neutral)

But, I need to know a thing :
What "Video Profile" do I have to use ?

=> in Default : at the middle of process, fps get down and then, nothing
=> CQ Lossless : ok it is fast (about 135 first pass and 70 second pass)
=> HQ Insane : very slow

[graysky]

But, I need to know a thing :
What "Video Profile" do I have to use ?

=> in Default : at the middle of process, fps get down and then, nothing
=> CQ Lossless : ok it is fast (about 135 first pass and 70 second pass)
=> HQ Insane : very slow

If you're doing the test the way you're supposed to, you don't need to use a video profile at all - it's hard coded in the jobs files.

[tsp]

ogg make sure you're using the latest version of MT:
http://www.avisynth.org/tsp/MT_07.zip

[0gg]

So, now, with many soft open and only 2x1 Go Ram dual channel :
http://4u9ur.free.fr/images/MeGUIMT07.gif
with MT07

2x Xeon Clovertown 5330ES 2,13 @2,9 Ghz

I think it could be better if it doesn't stepped down from 8.0x to 6.0x but always in 8.0x

[0gg]

And now :

MeGUI 0.24.1041
Avisynth 2.5.7
MT.dll v0.7
x264r655

http://4u9ur.free.fr/images/mt07x264r655.gif

8 cores are used between 97% to 100% !!


greeeeeaaattt

thank you everybody ;):thanks:

[0gg]

With same configuration hard & soft, but :
MeGui set in task manager to priority > Real Time
x264 set in task manager to priority > Real Time (twice : one for the first pass, one for the second pass)

http://4u9ur.free.fr/images/mt07x264r655RT.jpg

Next week, I update to 4x1 Go Ram Quad Channel (FBDIMM Memory on i5000x chipset)

[graysky]

I'm in the process of making a new test that uses no filters except the DGDecode_mpeg2source and loop. My plan is to upload a 7 second 720x480 23 fps progressive clip and have the avs loop it out to like 5-10 min. My curiosity is how the octa core systems (Ogg this means you) will handle it with no filters. MT.dll shouldn't help with this since all the processing power comes from x264.exe. Lemme work it out and upload it here.

Ogg: are you game to try it?

[0gg]

yeahh, with pleasure !

is it possible to play with these files too :
http://4u9ur.free.fr/procotest/index.mht

??

Quicktime 1'20" => .mov 230 Mo
Source : HDCAM, downscaled in QuickTime DV Lower field 25 fps

SetMTMode(2,0)
DirectShowSource("C:\procotest\LAOS.mov",fps=25,audio=false)
ConvertToYV12()
edeintted = last.AssumeBFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=0,full=false,edeint=edeintted)
#denoise

Video profiles = HQ Insane

FPS1 = 15,65
FPS2 = 15,41

[graysky]

OK.. here's the link to the new work file (it's just like the original): click here to download (http://home.insightbb.com/~pixels/test_encode/work2.rar)

Here is my result (q6600 @ 9x333 = 3.0 GHz). I'll make a table if we get some other results:
http://img375.imageshack.us/img375/5269/9x333hj0.jpg

My CPU usage was >99 % on the 2nd pass. Was yours on your 8 core system?

[mitsubishi]

Hi, I see you are talking about making some changes, should I be OK to run these tests tomorrow?

Well I say tomorrow, I rang up who I ordered some RAM off today and they hadn't noticed I'd sent in my payment, so hopefully I'll get it tomorrow, or it'll be Monday.

My mobo supports DDR and DDR2 (only upto 667 though)

But right now I have 2x512mb CL2.5 DDR400 and the new RAM is OCZ platinum DDR2-800 2x1GB. So I should be able to get some results showing the effect of memory speed on the whole thing. CPU is E6300, nice and cool with the zalman CNPS9700 I have on it, but won't get much of an overclock with this board.

Any suggestions what I should run? Stock at DDR-266,333,400 and DDR2-533, 667 with best and LCD timings and the same at max OC?

[0gg]

http://4u9ur.free.fr/images/work2.gif

8 Cores usage was between 86 -> 96 % on the 2nd pass.

[graysky]

Any suggestions what I should run? Stock at DDR-266,333,400 and DDR2-533, 667 with best and LCD timings and the same at max OC?

I dunno man, experiment with it would be my suggestion. I find that DRAM:CPU should be 1:1 for the best results. YMMV.

[graysky]

@Ogg: ok... the 2nd pass is really showing the power of those extra 4 cores. What was your CPU usage on the original (rich with filter) test?

[0gg]

As I said : http://forum.doom9.org/showpost.php?p=1004344&postcount=318
8 cores are used between 97% to 100% !!

[graysky]

Missed that, cool

[0gg]

http://forum.doom9.org/showpost.php?p=1004480&postcount=322 kill the workstation

[mitsubishi]

I dunno man, experiment with it would be my suggestion. I find that DRAM:CPU should be 1:1 for the best results. YMMV.

Yeah the plan was to run at 533 with as much OC as I can get (600 hopefully) and hope to get 3-3-3-10 timings out of the RAM at that until I get a better mobo.

But It'll be interesting to see what is best for x264 as that is the thing that most needs optimizing.

[0gg]

http://4u9ur.free.fr/images/MeGUI4Go.gif

and with 4x 1 Go (quadchannel mode on i5000x), 2x Xeon 5330 @ 2,9 ^^

[morph166955]

Hey all, not sure how but I some how got unsubscribed to this thread a while back so I haven't seen the updates for it in my box and kinda forgot. Graysky, I noticed that you were wanting some 8-core benches from Ogg, anything I can do to help out with that on my 8-core? I'm running linux but I could either run avisynth via wine and then just pipe that to a raw x264 cli. I realize the results wont be perfectly identical but since megui is just a frontend for the x264cli/avisynth i dont see any reason that it wont work good enough for our purposes. It could also nicely show the linux vs windows differences on the same source/settings. I'm also contimplating loading XP64 into a vmware console on the linux box although I dont know if that will let me pass more then 2 CPU's to the system (my windows box only shows options for 2 CPU's as of right now). Lemme know!

[graysky]

I think if you run it through WINE you won't get a true read since WINE has overhead associated with it. Plus I dunno how I'd comment your data in the table so that people who don't know about WINE/LINUX could understand it.

If you're game though, give it a shot and post your results. I'd be interesting to see.

[graysky]

http://4u9ur.free.fr/images/MeGUI4Go.gif

and with 4x 1 Go (quadchannel mode on i5000x), 2x Xeon 5330 @ 2,9 ^^

I'd like to update the table with this result, but I don't understand it. You o/c'ed to 2.9 GHz from 2.6 GHz and went from 82 fps on pass 1 to more than double that?

[anahita]

Cool ;)

[0gg]

You o/c'ed to 2.9 GHz from 2.6 GHz
My Xeon are 5330 = 2,16 Ghz
With BSEL Modification = 2,66 Ghz => http://forums.2cpu.com/showthread.php?t=77937
+ with Systool = 2,93 Ghz => http://www.techpowerup.com/systool/

went from 82 fps on pass 1 to more than double that
Before I had 2x1 Go = Dual Channel
Now : 4x1 Go = Quad Channel (on chipset i5000x)

FPS1 = 81,86 => without mt.dll, without last x264 (r655), without 4x1 Go (only 2x1 Go), no set priority

FPS1 = 163,13 => with MeGUI 0.24.1041, Avisynth 2.5.7, MT.dll v0.7, x264r655 set in real time in the task manager

[morph166955]

mt.dll is the key to the whole thing. its equally evident on my passes. w/o mt.dll my system ran almost identically to ogg's non mt.dll pass. with it i hit double what I did with out it.

also Ogg, while the ram is running mildly better in quad channel mode, i doubt it did a whole lot speed wize. Also FYI, running x264 in realtime mode is actually bad and can slow it down. if x264 is preceding avisynth process wize it has the potential to slow down the whole thing instead of speeding it up! if your going to attempt to adjust processor priority I would kick x264, avisynth and megui (prob not important but cant really hurt) up to AboveNormal...MAYBE High although I think that would cause some issues also. Setting things in realtime while it sounds like it should give it the most priority actually can cause issues. Its not the equivalent of setting somethings nice value to -20 in linux at all if thats how your thinking it works. I normally just leave my stuff alone to handle itself becaues as long as your not running anything else thats a cpu hog when your doing the encode then the processes will get all the cpu time they need anyway.

[mitsubishi]

Had a knightmare trying to get it to work, kept getting DGdecode mismatches. Didn't work until I deleted all traces of DGdecode (WTF!) yet still works now I put the included dll back.

Got 42.78 / 13.82 with current x264, and 40.3 / 13.18 with correct version.

Will do it all properly now I got it set up correctly and report back later.

[mitsubishi]

Finished the DDR1 tests, not doing any overclocking with DDR.

Motherboard: ASRock 775Dual-VSTA
CPU: Intel E6300 B2
Gfx: 6800GT AGP
Ram: 2x512

Tested at SPD and lowest common denominator for each speed.

http://img504.imageshack.us/img504/3572/ddrresultsxa7.png

Clearly a difference at the lower speeds of DDR, will swap out the ram for DDR2 later and test. The only odd one is the first pass on the last test...

[graysky]

http://img504.imageshack.us/img504/3572/ddrresultsxa7.png

Clearly a difference at the lower speeds of DDR, will swap out the ram for DDR2 later and test. The only odd one is the first pass on the last test...

Do you really think there's a difference here? One thing I never did was to run it like 10 times and calculate a SD and range to give error bars. At a first glance, it seems the DDR-400 is faster than the DDR-333 but without the error calculated, it's a tough call.

[mitsubishi]

There certainly seems to be trend in the right direction. I did consider running a few iterations with the test being so short, the first pass in particular is bit too quick and will be knocked off by anything in the background, perhaps I should have set priority to high to be on the safe side.

If you look at the last three results for 2nd pass,

266 > 1.5% > 333 > 1.8% > 400

It's not much, but I think enough to say it is not experimental error, no-one would expect it to be much on such a CPU intensive operation. Even a few percent is welcome on long jobs.

I'm not expecting there to be a noticeable difference between 533 and 667, but we'll see.

[graysky]

Could be statistically significant. I dunno for sure since I'm no statistician. I just wanted to raise the question with nothing implied either way. I think the major speed differences come from RAM timings but I don't have any data to back that statement up, just a hunch.

[graysky]

So I ran the test 10 times and found when the hardware is unchanged, the results were all within 3% of each other for pass1 and within 1-1/2% of each other for pass2. If your machine is like mine with those errors, if the delta FPS is within 3% on pass1 and/or 1-1/2% on pass2, the results are identical.

It'll be interesting if you do that same n=10 experiment and calculate your errors as well.

[vjHeaven]

My first desktop PC

CPU Type: AMD Athlon XP, 1666 MHz (12.5 x 133) 2000+
System Memory: 896 MB (DDR SDRAM @ 333Mhz)
http://img91.imageshack.us/img91/5493/56098685if1.jpg

My second desktop PC :D

AMD Athlon Thunderbird @ 1.20GHz (12.0 x 100.2)
Memory: 384MBytes (SDRAM @ 100Mhz)
http://img145.imageshack.us/img145/3934/72619801ro4.jpg

My Notebook (Acer TravelMate 2492NWLMi)

Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
Memory: 512MBytes DDR2, PC2-5300 (333 MHz)
http://img143.imageshack.us/img143/6949/12783526sg5.jpg

[graysky]

Cool, thanks for participating. I'll update the table in tonight or tomorrow.

[graysky]

...updated

[morph166955]

@graysky
On the mt.dll image at the bottom of the first post it says "morph166955 used this avisynth line" but has nothing next to it. I used the same line aicjofs used to keep things uniform for the tests "SetMTmode(2,0)". Just figured I'd let ya know for the next time your updating the images if you wanted to include that.

[graysky]

I'll correct that, thanks for catching it.

[simonhowson]

I'm considering upgrading my computer so that it is faster at backing up DVDs to x264. I have over 1000 DVDs, so I want this process to be as fast as possible.

Specifically, I intend to use the MeGUI iPod video 5.5 profile, with the image 640 pixels wide, and an average bitrate of 1000 Kbps for the video, and ~100 Kbps AAC for the audio.

I'm wondering which of the following CPUs would be faster for encoding with these settings, either the Core 2 Quad 6600 (4 X 2.40 GHz) or a Core 2 Duo E6850 3 GHz (specifically the 9 x 333 MHz bus version, set for release on July 22nd).

Apparently on July 22nd both of these two CPUs will be the same price ~US$266. I'm just unsure if I should go for 2 cores @ 3 GHz on a 1333 MHz bus. Or 4 cores at 2.4 GHz, on a 1066 MHz bus. I don't intend to overclock, I just want the best performance at stock settings.

The closest comparison I can find shows the C2D E6700 at 9 x 333 has an encode ratio of 1.38:1. Whereas the C2Q 6600 at stock settings has an encode ratio of 1:1.06 (i.e., slightly faster than real time), which means the Core 2 Quad 6600 is about 31% faster.

Would encoding using the iPod 5.5 profile have similar results? Or does the benefit of Quad Core really depend on what encoding settings are in use at the time, thus making it hard to predict how much benefit the 2 extra cores are, and how this would compare to a faster dual core CPU?

[ditche]

C2Q. :p

http://img402.imageshack.us/img402/7949/couper6dr7.png
http://img525.imageshack.us/img525/8574/couper7ge5.png

[graysky]

I'm considering upgrading my computer so that it is faster at backing up DVDs to x264. I have over 1000 DVDs, so I want this process to be as fast as possible.

Specifically, I intend to use the MeGUI iPod video 5.5 profile, with the image 640 pixels wide, and an average bitrate of 1000 Kbps for the video, and ~100 Kbps AAC for the audio.

I'm wondering which of the following CPUs would be faster for encoding with these settings, either the Core 2 Quad 6600 (4 X 2.40 GHz) or a Core 2 Duo E6850 3 GHz (specifically the 9 x 333 MHz bus version, set for release on July 22nd).

Apparently on July 22nd both of these two CPUs will be the same price ~US$266. I'm just unsure if I should go for 2 cores @ 3 GHz on a 1333 MHz bus. Or 4 cores at 2.4 GHz, on a 1066 MHz bus. I don't intend to overclock, I just want the best performance at stock settings.

The closest comparison I can find shows the C2D E6700 at 9 x 333 has an encode ratio of 1.38:1. Whereas the C2Q 6600 at stock settings has an encode ratio of 1:1.06 (i.e., slightly faster than real time), which means the Core 2 Quad 6600 is about 31% faster.

Would encoding using the iPod 5.5 profile have similar results? Or does the benefit of Quad Core really depend on what encoding settings are in use at the time, thus making it hard to predict how much benefit the 2 extra cores are, and how this would compare to a faster dual core CPU?

Bus speed really doesn't matter; see the first post of the thread. If you do a lot of x264, and it sounds like you do, the quad is the tool you want and will out perform the dual every time since there are 4 cores vs. 2 cores, and since x264 does a great job using all 4 cores in parallel.

Also, why get a Q6600 and run it @ stock values of 9x266? I've had mine clocked @ 9x333 (1333 quad pumped) for months. A long as you have decent cooling and keep your vcore low it should be fine.

[graysky]

Thanks for the graphic, ditche!

[dancho]

http://img528.imageshack.us/img528/9884/cpubb3.jpg (http://imageshack.us)

http://img403.imageshack.us/img403/7609/memko1.jpg (http://imageshack.us)

http://img201.imageshack.us/img201/4456/resultfs7.jpg (http://imageshack.us)

memory is DDR2 2*1GB PC6400 (800MHz) OCZ platinum XTC

mbo is Gigabyte N650SLI-DS4

all default and slightly better results....:rolleyes:

[chainring]

Nothing special here:
Acer Travelmate 8204 (laptop)

Tests done with "work2".

[ditche]

Thanks for the graphic, ditche!

Edited. :)

[legoman666]

finally got around to running this. Results could probably be better, computer hasn't been rebooted in 22 days.

http://img76.imageshack.us/img76/6677/cpuspeedkl3.jpg

http://img233.imageshack.us/img233/9499/meguioz2.jpg

As a side note, the .d2v file you included in the test rar was made using an old version of dgindex. To make it work with the new version, just open up the .d2v file in notepad and change the first line from "DGIndexProjectFile13" to "DGIndexProjectFile16" Besides that first line, the files are idenical (the one made with the new version and the one made with the old version.)

[graysky]

@legoman: yeah, I think you're using the "dev" version of MeGUI. It downloads, and updates to version 0.2.4.1041 and if you notice when you run an update, all the plugins,apps, etc. are the dev (unstable) versions. Perhaps a bug?

I'll add the most recent results from you, chainring, and dancho in a few...

[ditche]

I want to restart the test... but which version of x264 file have I to use ?
And where can I found this file, lapse of memory... :p

[deets]

download the older version of x264.exe from the below url and then manually copy it into your MeGUI\tools\x264 directory

http://mirror01.x264.nl/x264/?dir=./revision620

from the instructions :P

[ditche]

Yep, thank you, but it seems I've an old version of the file instructions.txt (02/25/07), because I don't see what you say. :)

[ditche]

Graysky, I think you can erase my bench with my A64 X2 4200+ @ 2.53 GHz...
RAM and CPU weren't synchronised...

Now RAM & CPU are at the same FSB : 220 MHz (before A64 @ 230), and the results are slightly better :

http://img354.imageshack.us/img354/6889/couperyd7.png

http://img354.imageshack.us/img354/7863/couper2ms2.png http://img354.imageshack.us/img354/7433/couper3um9.png

:)

[graysky]

OK! Finally updated the table... except for you, ditche. I'll get yours in there tomorrow when I have time.

[Dr.Khron]

Here you go. First my new work laptop:

http://img528.imageshack.us/img528/8048/notebookrun3st5.jpg

http://img148.imageshack.us/img148/6135/cpuzlaptop1hs4.jpghttp://img201.imageshack.us/img201/82/cpuzlaptop2wg7.jpg


Now for the old Athlon desktop, with 0% OC and 25% OC:

http://img149.imageshack.us/img149/4082/desktop0ocev9.jpg
http://img149.imageshack.us/img149/9654/desktop25oczp5.jpg

http://img244.imageshack.us/img244/5744/cpuz0oc1wt0.jpghttp://img505.imageshack.us/img505/8638/cpuz0oc2mg0.jpg


EDIT:
Both OC settings were with the memory = 100% of FSB

[ditche]

Dr.Khron : We need to see exactly the duration of your first test. :)
So, your 2100+ oc is @ 2,17 GHz ?

Graysky : OK, now I'm trying with a Sempron 2600+. :cool:

[Dr.Khron]

Um, why would you need to see the duration?

The FPS calc has more sig figs then the whole seconds provided by the start/stop times... just multiply by the number of frames to figure the the time elapsed.

If its that important to you, I'll have to run the test again.


As for the OC speed, I dunno, I didn't take a screenshot of CPUZ for OC'ed state. I would imagine its just:
(133 + 1/3 ) x 13.0 = 1,733
(166 + 2/3 ) x 13.0 = 2,167

As I said, I just cranked up the FSB and left all the other timings at stock, including the mem bus = 100% FSB.


Edit:
Oh DUH! 2,167 Mhz = 2.17 Ghz.... your euro-style use of commas as decimals confused me.

[ditche]

http://img523.imageshack.us/img523/1073/nouvelleimagemm3.png

http://img523.imageshack.us/img523/7079/nouvelleimage1ig2.png http://img523.imageshack.us/img523/7586/nouvelleimagerg5.png

[ditche]

Um, why would you need to see the duration?

The FPS calc has more sig figs then the whole seconds provided by the start/stop times... just multiply by the number of frames to figure the the time elapsed.

If its that important to you, I'll have to run the test again.
OK, don't run the test again, 53 sec and 158 sec for the 2 tests. :)

[delacroixp]

Um, why would you need to see the duration?

The FPS calc has more sig figs then the whole seconds provided by the start/stop times... just multiply by the number of frames to figure the the time elapsed.

FPS as in indication of speed is only valid if it's entirely constant...
A car (automobile) travelling at 90 kmh (55 mph) for 30 minutes and then 50 kmh (31 mph) uphill for another 30 minutes has an average speed of 70kmh (43mph).
For short encodes it's probably irrelevant but longer encodes are rarely consistent or constant...

I'm actually looking for an app that maps FPS over time... during H264 encodes... in the form of a graph.


:):D:eek:
Pascal

[simonhowson]

Bus speed really doesn't matter; see the first post of the thread. If you do a lot of x264, and it sounds like you do, the quad is the tool you want and will out perform the dual every time since there are 4 cores vs. 2 cores, and since x264 does a great job using all 4 cores in parallel.

Also, why get a Q6600 and run it @ stock values of 9x266? I've had mine clocked @ 9x333 (1333 quad pumped) for months. A long as you have decent cooling and keep your vcore low it should be fine.

Yeah the Q6600 is the better choice. But now the new penryn 45 nm core is on the horizon, so I'm thinking of waiting for that (133 MHz bus, 6 MB cache per core + SSE4 extensions)

[graysky]

@simon: SSE4 is sort of an unknown. Might take a while before x264.exe uses them. 2 extra megs per core might translate into to something tangible... tough to say. Finally, 1333 MHz FSB is doable on today's hardware.

[simonhowson]

@simon: SSE4 is sort of an unknown. Might take a while before x264.exe uses them. 2 extra megs per core might translate into to something tangible... tough to say. Finally, 1333 MHz FSB is doable on today's hardware.

Intel are claiming that all SSE instructions will receive some speed boost, but who knows if that is just marketing hype.

I have looked at some early penryn benchmarks, and it looks like it will be 10 - 20% faster at the same clock speed when compared to current Core 2 Duos. Add to that the fact the 45 nm process means that the CPUs will start at higher frequencies means this could be a great CPU for video encoding.

I just hope they introduce an entry level quad core part, like the Q6600. Since Intel only have 1 45 nm fab, I fear that they will introduce those CPUs at the high end, but keep the lower end parts as 65 nm CPUs, well, at least until their two new 45 nm fabs open (one in Arizona and one in Israel).

[graysky]

I've seen those data as well. I think it may take 6-9 mo. after their launch before you see SSE4 incorporated into x264. Have a look at this (http://forum.doom9.org/showthread.php?t=124885&highlight=SSE4) thread for example.

[legoman666]

@legoman: yeah, I think you're using the "dev" version of MeGUI. It downloads, and updates to version 0.2.4.1041 and if you notice when you run an update, all the plugins,apps, etc. are the dev (unstable) versions. Perhaps a bug?

I'll add the most recent results from you, chainring, and dancho in a few...

I set MeGUI to download beta versions of the tools because I knew there were newer versions of several of the apps out there and the MeGUI auto update wasn't downloading them. For example, the new version of DGIndex has support for .ts files.

[delacroixp]

Intel are claiming that all SSE instructions will receive some speed boost, but who knows if that is just marketing hype.

The speed boost may only amount to 1% in certain instances... but even 1% is worth pursuing... in the quest for the edge...


:):D:eek:
Pascal

[simonhowson]

According to this page (http://www.fudzilla.com/index.php?option=com_content&task=view&id=1548&Itemid=1) the first lot of Penryn Quad Core CPUs (code named Wolfdale) are going to run on the 1066 MHz bus, whereas even the new Conroe based Core 2 Duos (due for release on July 22nd) are going to run on a 1333 MHz bus. I wonder if this means early Penryn based Quad cores are going to run significantly slower than Penryn based dual cores?

[graysky]

@simonhowson - I dunno man. Just because the FSB is faster doesn't mean the chip will be faster. I will be very interested in seeing someone w/ one of these new chips run the MeGUI test...

[Ronin-7]

My results done on Vista x64|Q6600 at 3Ghz|4GB DDR-2 800 {4-4-4-12}|MSI P35 Platinum. I used the MT.dll as well for these.

http://homepage.eircom.net/~rock2002/pictures/MeGUI-Bench.JPG

http://homepage.eircom.net/~rock2002/pictures/CPU-Z%20Bench.JPGhttp://homepage.eircom.net/~rock2002/pictures/CPU-Z%20RAM%20Bench.JPG

[graysky]

You did have mt.dll enabled for these results? They are inline with my 9x333 numbers wo/ mt.dll; when I ran it w/ the mt.dll enabled, my pass-1 jumped up to about 114 fps. What was the syntax you used?

[Ronin-7]

Yeah I was using the mt.dll 0.7, the first time I ran it I got 97fps but I forgot to take a screen shot, the second time I ran it I got 92fps on the first pass wondering if there was some sort of variable in performance I re-ran the test 4 more times and it always came back at 92.xx fps

Do you need to do anything special for mt.dll I thought you just dropped it in over avisynth and MeGUI takes care of the rest or am I misunderstanding it's usage ?

[graysky]

You need to correctly install the mt.dll (/avisynth/plugins) as well replace the avisynth.dll in /windir/system32 and add the following to the avs as the first line:

SetMTmode(2,0)

[Ronin-7]

You need to correctly install the mt.dll (/avisynth/plugins) as well replace the avisynth.dll in /windir/system32 and add the following to the avs as the first line:

SetMTmode(2,0)

I see thanks for the heads up, a new bios for the MSI P35 is out as well which improves things a small bit more so I might give that a go too.

[graysky]

I was just going through the data and noticed that we have no FX-60 or FX-anything examples... anyone out there w/ this chip care to be the first?

[ditche]

True, and there is not A64 X2 w/ 1 Mo L2, like 4400+ or 4800+, nor of A64 X2 AM2 > 4600+... :(

[dansus]

wow that comparison graph of the chips is music to my eyes, i was debating whether to get a QX6600 or 6700, but it seems the 66 OC is good enough to do the job and its not really worth splashing out the extra cash for the 67, especially now the intels are round the corner.

Im running 3700+ at the mo, with 25/7 fps. Hope i can see something near the 100/45 fps mark.

[graysky]

Glad you found it useful. I was thinking about re-doing the table... errr adding an additional simplified table that just shows the scalability of a single chip:

core 2 duo 6600-6700 up through clock ranges
core 2 quad 6600-6700 up through clock ranges

Like that. Really there 6600 or 6700 is just a model number. It might be easier to think of in terms of the model (c2d or c2q) and a clockrate.

[ditche]

Updated.

http://img508.imageshack.us/img508/5475/couper9ah5.png
http://img508.imageshack.us/img508/7747/couper10zg5.png
http://img508.imageshack.us/img508/964/couper11ot3.png

(*) = OC


And without oc :

http://img508.imageshack.us/img508/8092/couper12nx9.png

[dansus]

im wandering why the xeon's have a more even fps over the two passes compared to the others?

[aicjofs]

Those are 8 CPU core systems. This leads to the first pass not scaling as it does for a single/dual/quad system. Some discussion if x264 is not entirely optimised for such a setup here.

http://forum.doom9.org/showthread.php?t=124557

I haven't read that thread in awhile but I think there was a few test builds that made the 1st pass for the 8 core system more on par with what we are use to seeing in the other data.

[Escaflowne]

Hi, I find this thread is very interesting and I appreciate your efforts. I alwalys looked for benchmarks showing the capabilities of CPUs in encoding videos. I hope this thread will be continuously updated also for future generations of CPUs.
After running the test I got no FPS results in the queue tab but I found them in the log. So I will add the log instead of a screenshot. Sorry for that.

My Notebook (Asus Z53M series )
AMD Turion 64 X2 TL-50 2x1600Mhz - stock speed - 1024 meg DDR2-667

FPS1 = 34.10
FPS2 = 10.90


My old desktop PC:
AMD Duron 1200Mhz - stock speed - 640 meg SD-Ram PC-133

FPS1 = 9.59
FPS2 = 2.74


My second Desktop PC:
Intel Pentium 4 1800Mhz - stock speed - 512 meg DDR-Ram 333Mhz

FPS1 = 10.01
FPS2 = 3.03


I was stunned when i saw the result of my old Duron compared with the result of the P4. The AMD Duron is much more efficient... . Seemingly the Intel CPUs were really not that powerful at that time.

[ditche]

x264 r620 ??

[miglet]

Someone help me fix this error I get, fresh MeGUI install, replaced the x264.exe with correct version, log:

Calling setup of processor failed with error The file C:\work\test-NEW.avs cannot be opened.
Error message for your reference: MPEG2Source: DGIndex/DGDecode mismatch. You are picking up
a version of DGDecode, possibly from your plugins directory,
that does not match the version of DGIndex used to make the D2V
file. Search your hard disk for all copies of DGDecode.dll
and delete or rename all of them except for the one that
has the same version number as the DGIndex.exe that was used
to make the D2V file.
(C:\work\test-NEW.avs, line 3)

[graysky]

Yeah, you're using a newer version of DGDecode than the one that was used at the time I started that test. If you download evrsion 1031 of MeGUI and make sure you auto update to the stable version, not development version it should work.

[miglet]

Got it sorted now, and with my new Q6600 posted times on a par with other Q6600s, so I'm damn pleased.

[graysky]

@miglet - glad to hear it... do you know which revision your q6600 is? Load up CPU-Z and have a look at the first screen: mine is a B3 as you can see.

http://img263.imageshack.us/img263/4551/ooey0.gif

[legoman666]

Updated results again. I dropped my HTT multipler to 3x so I could ramp up the CPU speed some more. Running at 2750mhz now as opposed to 2600mhz previously. Ram is also at 229 instead of 217mhz. It'll post all the way up to 2790mhz, but won't boot into windows. I guess that's the limit of my poor little 3800+ AMD X2. When I set it to 2800mhz, it doesn't even post at all. Not too shabby for a chip that runs at 2.0ghz default though.

http://img63.imageshack.us/img63/479/meguitest3ox2.jpg

[ditche]

legoman666 > I don't understand...
Your 1st pass equal ± a CD2 E6700, and your 2nd pass equal ± a C2D E6700 @ 3,7 GHz...

:confused:

[legoman666]

I know. I was curious about that too, but I ran the benchmark 3 times to confirm what I was seeing.

[ditche]

Up. :)
graysky : You don't update your results ? :)

[Episodio1]

Here with a x2 +5600.

Waiting for links to be repost (send me a PM to alert me). ^_^

[graysky]

@episodio1 - I have released a newer, "better" benchmark that the people at techarp were kind enough to host for me. Here (http://www.techarp.com/showarticle.aspx?artno=442&pgno=0) is the url to download it/see results. If you don't wanna reg. over there, just PM me your data here.

[ditche]

Fun, see you there. :)

[legoman666]

pm'ed ya my results.

[graysky]

Thanks for the results all. I started a new thread here (http://forum.doom9.org/showthread.php?p=1044126#post1044126) so you don't have to PM me the results... feel free to post them in that thread.