Intel Q9450 vs Phenom 9850 - ATI HD3870 X2

[JumpingJack]

what do you think?
Do you think that the code is unimportant in order to know why some application behaves in a specific way?

No, I think you don't know what you are talking about ....

Look, your claim in this thread is that in high res gaming, that the FSB cannot handle all the little threads poking around and that Intel's CPU performs poorly because of the FSB, thus Phenom is best.

I will not argue that high res gaming shows them neck and neck based on the data. But if your FSB argument is true, you do not need to see the code to make an emperical observation. Based on your hypothesis, the FSB is saturated, so if I lower the FSB speed I should take a performance hit....

What you are really observing is the GPU is limiting the FPS, you have hit the GPU limited regime.... the load variation on the GPU is deterined by the resolution you select and the oversampling chosen for the aliasing. You reject this notion, yet I showed you data that proves this notion.... so what I am asking you to do is explain the data.

My suspcion is that any time someone provides you with the data that refutes your claims you will fall back on "I need to see the code", which is in and of it's self code for "I don't know".

jack

[gosh]

Look, your claim in this thread is that in high res gaming, that the FSB cannot handle all the little threads poking around and that Intel's CPU performs poorly because of the FSB, thus Phenom is best.

I will not argue that high res gaming shows them neck and neck based on the data. But if your FSB argument is true, you do not need to see the code to make an emperical observation. Based on your hypothesis, the FSB is saturated, so if I lower the FSB speed I should take a performance hit....

If you are talking about games you should test a game that is communicating with the GPU and is using memory at the same time (there will be conflicts in the FSB that increase latency, amd has no conflicts there). Then you will see big improvements for AMD. More and more advanced games will run better and better on AMD. If the game is using more than one thread to render data then AMD will perform better.
I haven’t read what you have written about Lost Planet. I need to check some tests before I can tell you something about that game. How it scales, how it is using threading etc

EDIT: Checked two tests on Lost planet

Here is one: http://techreport.com/articles.x/14424/4

Comparing QX9650 and QX6850, isn't the main difference cache size? That would mean that Lost Planet likes a big cache (is there other differences between these two processors?)

[JumpingJack]

If you are talking about games you should test a game that is communicating with the GPU and is using memory at the same time (there will be conflicts in the FSB that increase latency, amd has no conflicts there). Then you will see big improvements for AMD. More and more advanced games will run better and better on AMD. If the game is using more than one thread to render data then AMD will perform better.
I haven’t read what you have written about Lost Planet. I need to check some tests before I can tell you something about that game. How it scales, how it is using threading etc

Pick the game. I will test it.

Core scaling for Lost Planet:

[gosh]

Pick the game. I will test it.

Race Driver Grid

[JumpingJack]

Race Driver Grid

Ok, I downloaded it... how do you want me to test? There is no way to record a demo, not that I have found. How do you want me to get reproducible results?

Ok, I tell you what ... i will do it similar to what your link provides. I will gun it for 15 seconds straight ahead and capture frame rate... this won't be hugely representative, but should suffice.

If I do this, will you accept the result even if it contradicts your link? Because I am gonna test both the Phenom and QX9650 both at 2.5 GHz with identical configurations, not that scatter configuration data that is in the other forum.

[JumpingJack]

Ok, I downloaded it... how do you want me to test? There is no way to record a demo, not that I have found. How do you want me to get reproducible results?

Ok, I till you what ... i will do it similar to what your link provides. I will gun it for 15 seconds straight ahead and capture frame rate... this won't be hugely representative, but should suffice.

If I do this, will you accept the result even if it contradicts your link? Because I am gonna test both the Phenom and QX9650 both at 2.5 GHz with identical configurations, not that scatter configuration data that is in the other forum.

Ok, here you go.....

First some details. The two compare systems are documented here: http://forum.xcpus.com/motherboard-c...d.html?garpg=7
Here is a pic of the details of the HW:


There is one significant difference in the HW described in the above link, I had to replace the Dell 17" monitor with a HP 2207 to access the 1680x1050 resolution. Also, read through the entire build setup -- I am using profile 1.1, which has DDR2-1067 however, all tests were done with DDR2-800 CL4 timings.

GRID does not have a demo record or replay save option that I could find, therefore, I had to do everything consistently as possible. It worked better than I had imagined. First, I installed the GRID demo and ran my first test simply going to the graphics options screen and selecting Ultra. This actually defaulted the resolution to 1024x768, so I tested there. I then repeated the test by forcing the resolution to 1680x1050 (the max of the monitor). All other game options were default as installed, I did not change any other settings other than as described by the graphics screen setup above. Finally, on the QX9650, I rebooted and set the FSB to 200 Mhz, and the multiplier to 12.5 to achieve 2.5 GHz.

All clocks were the same, 2.5 GHz (default stock for the Phenom 9850).

First I launched FRAPs version 2.9.4, I then launched a game and started a race. At the initial prompt screen, I hit enter for the first race track, enter again to select the default setup (car, driver, etc). The loading screen then appears, I wait for the first hint of the screen coming back after the loading completes to press F11 to start counting FPS with FRAPs. This allows the first 3-5 seconds to capture the fly through to the start of the race. I then allow the race to count down as normal, and press and held the up arrow key. After about 2 seconds I tapped the right arrow key twice (if you don't you crash in 10 seconds) then the left arrow key once, all this time keeping the up arrow key depressed. I allow the car to crash into the what ever car it hits as the group takes the first right turn. After the crash settles, I then press the F11 key to complete the logging of FRAPs.

The Excel file is attached (EDIT: i forgot, vBulletin doesn't allow XLS files, so I saved as tab delimited text). The first run on the QX9650 had one extra entry in the log file due to a delay in hitting the F11 key, that was removed. All other log entries are as they were collected.

Fraps output to ascertain reproducibility.


Here is the statistical summary:

Phenom 9850@2.5G 1024x768 Ultra Ave FPS = 64.75
Phenom 9850@2.5G 1680x1050 Ultra Ave FPS = 47.61
QX9650 @ 2.5G 1024x768 Ultra Ave FPS = 75.96 (NOTE, the very last entry is 108 FPS, if this is removed the average is 74.78)
QX9650 @ 2.5G 1680x1050 Ultra Ave FPS = 48.64
QX9650 @ 2.5G and 800 MHz FSB 1680x1050 = 47.54

This actually turned out to be another great example of GPU vs CPU limited domains. At 1024x768, QX9650 is 17% faster clock for clock (or 15% faster throwing out the last FPS entry in the QX9650 -- let's count it as an anomaly). At 1680x1050, both CPUs perform identically -- GPU limitation naturally.

Changing the FSB from 1333 Mhz (333 Mhz system clock, stock for the QX9650) to 800 Mhz (200 Mhz system clock) had no effect on the observed FPS -- as expected.

Tab delimited raw data is attached.

EDIT: Just for fun, I repeated the 1024x768 and 1680x1050 but at 3.0 GHz on the QX9650, and at 3.0 GHz on the Phenom, the results below (did not plot):

QX9650 @ 3.0G 1024x768 Ultra = 75.70 FPS
QX9650 @ 3.0G 1680x1050 Ultra = 49.68 FPS
Phenom 9860 @ 3.0 G 1024x768 Ultra = 71.94
Phenom 9860 @ 3.0 G 1680x1050 Ultra = 47.44

So at 2.5 GHz, an intel quad is enough to satiate a 8800 GTX at low resolution, ultra settings. At 3.0 Ghz, the Phenom can satiate the 8800 GTX at lower resolutions ultra settings.



Jack

[gosh]

All clocks were the same, 2.5 GHz (default stock for the Phenom 9850).

If you investigate how these processors work you will find that AMD is gaining speed with faster I/O and bandwidth communication.
Intel QX9650 = 12 MB L2 cache at 15 clocks
AMD 9850 = 2 MB L3 cache at 43(?) clocks running at 2 GHz (?) and 512 KB L2 cache for each core.

If these processors worked similar then Intel should win these tests and it should win by some margin. The HUGE L2 cache that is so much faster will do a lot on the work that is done by the processor (games normally loves cache). The L2 cache is about three+ times faster compared to L3 cache and also very big. AMD will need to go to memory more often than Intel so there is also one performance hit. Fast memory will do more to AMD because of this.
Now if these results are that similar on 1680x1050 and the FSB isn’t a problem, then the only solution would be that the GPU is very slow. So slow that it isn’t possible to notice the difference between these processors because Intel should win.
The performance hit by lowering the FSB to 200 MHz seems ok, I have tested this to and what I have noticed is that lowering the FSB doesn’t seem to change bandwidth as much as it changes latency.
I am pretty sure that you will find more and more speed improvements when you are using fast video cards on high res with AMD when the resolution goes up and you have high settings. Doubling the I/O load on the FSB will do some damage to the total speed. AMD will not notice this on memory because it handles the I/O with hypertransport.
Besides that you have the problem if threads are shifting cores on Intel.

About this list
LIST - Processors Bottom to Top

They are running Grid at 640x480 and AMD seems to perform better on that very low resolution. The reason for this might be that on that VERY low resolution the cache (L2) for AMD is enough. Maybe you don’t need that very LARGE L2 cache then and that makes AMD even to Intel. AMD synchronize threads faster and that might be the reason why you get a bit better performance.
When you increase the resolution the game is needing more memory and AMD is going to the memory sooner than intel, it is first going to the L3 cache but there is one performance hit for more than 3 times slower. Going to memory the performance hit is even larger. If they had tested on 800x600 intel would probably win, it would win on 1024x768, as the resolution goes up AMD will gain performance again and at some point it will pass Intel.


gOJDO Do you have any other explanation?

[gosh]

If I do this, will you accept the result even if it contradicts your link?

If you find something that contradicts what you are saying I don't think that you are going to inform about that(you have invested to much pride in that "FSB doesn't matter") . But I am interested in how Race Driver Grid performs. It performs well on ATI so if you have one new ATI card then please use that. If you are able to get 48xx in crossfire then this is VERY interesting.

When I have looked at tests it seems that the older nVidia 8800 serie (GTX and Ultra) have high latency externaly. But very fast internally. That may be the reason why there are cards with 768 MB ram

EDIT: If you are interested in comparing GPU here is a nice test comparing 8800GTX and ATI 4870
http://www.nvnews.net/vbulletin/showthread.php?t=115791

[Hornet331]

If you find something that contradicts what you are saying I don't think that you are going to inform about that(you have invested to much pride in that "FSB doesn't matter") . But I am interested in how Race Driver Grid performs. It performs well on ATI so if you have one new ATI card then please use that. If you are able to get 48xx in crossfire then this is VERY interesting.

When I have looked at tests it seems that the older nVidia 8800 serie (GTX and Ultra) have high latency externaly. But very fast internally. That may be the reason why there are cards with 768 MB ram

EDIT: If you are interested in comparing GPU here is a nice test comparing 8800GTX and ATI 4870
http://www.nvnews.net/vbulletin/showthread.php?t=115791

you dont get this in your thick skull, dont you?

It doesnt matter if you use a 8800gtx/4870 or even a 280gtx. The only thing that happens is, that you push the gpu limit into a higher resolution region.

Your now trying to shift the topic away from the cpu to the gfx...

[JumpingJack]

EDIT: Checked two tests on Lost planet

Here is one: http://techreport.com/articles.x/14424/4

Comparing QX9650 and QX6850, isn't the main difference cache size? That would mean that Lost Planet likes a big cache (is there other differences between these two processors?)

Just saw your edit...

I don't understand your point here nor what it has to do with your assertion that we are working on ... of course a larger cache is going to yield better overall, because Cave in Lost Planet is CPU bound, thus it responds to CPU performance. IPC goes up with cache size (as explained above), and because the CPU is the throttle in Lost Planet for this particular scene, you would expect (and you in fact point out as an observation), that it should show a response. I have always had a bad taste in my mouth when I see someone post "games love cache" ... anything loves cache, cache will improve just about anything, some more than others, some hardly noticeable... but larger cache usually means good (until it gets so large, latency negates the advantage).

The difference in the QX9650 and a QX6850 is cache size and a few other architectural tweaks, but the influence here is completely based on the difference in cache most likely. I can link several citations for you that show how cache improves performance. As explained above, and as you obviously agreed, the miss rate in cache varies with applications and the functionality of the cache size to miss rate goes as a power of the size. For example, miss rate = k*X^(-power) where k is a proportionality constant, X is the cache size, and power is a number (typically between 1 and 1.8, cannot remember I can dig up the reference) ... EDIT: though the rule of thumb has always been 1/sqrt(size), but this is not really accurate today. It depends on the associtivity, whether it is exclusive or inclusive, yada yada. and does not always track a sqrt(2) proportionality. Just wanted to make that clear. (I think it is this one http://portal.acm.org/citation.cfm?id=327132 but am not logged into my server at work to view it).


Now, using your same link as a reference ...



I have shown (see prior posts) and I have argued vehemently that Snow is GPU bound. This data also shows that same trend. Look at how interesting this is... for changes that address CPU performance there is a FPS response in Cave, but not for Snow .... this is what makes this particular game so good to use to study difference between CPUs and GPUs, I have scripts within two different regions of the game that stresses the two computational sources in the same benchmark run.

Your edit more or less helps make my point.

A side point here is to take a careful take home message. Each script is only about 2-3 minutes of game play in two different levels/locations within the game, in one case I would see CPU's all look the same even at 1152x864 (which is what Techreport used) -- i.e. GPU limited -- yet if I concluded based on Cave then I would be able to make a statement between the relative performance of the two CPUs in question. In other words -- if I only took the Snow data, I would make a false conclusion of the relative performance of various CPUs -- I would think they all are basically the same; however, Cave shows this is not true ... I would have fooled myself.

Games and benchmarks can be selectively created to force a situation if one does not pay attention, questioning what you read is a good habit.

Ok -- so how do I evaulate the game/code/BW/etc concerns of a CPU to make an honest assessment? Well ... take the GPU completely out of the equation. Doing so allows me to see how the two CPUs behave based on the way they run the code necessary to make the game work. Is this realistic ... nope, not really ... but I do want to know this information such that, for example, if I want to upgrade to a faster video card in the future... I don't need to re-address my CPU choice, I will now what performance to expect. Ideally, a good review for a CPU will show both the ultra high res stuff -- like they way we want to play the game as well as the ultra low res stuff so I can 'future' proof my rig.

EDIT2: I am sorry, last edit and one last point. I do not have a test from my experiments that mimics the QX9650 runs that Scott did in his review, so I cannot compare directly. Nor do I mimic his graphics settings ... (if you read the link in pages earlier to my LP article, I document the exact settings). With this in mind, I am matched at stock condition for the Phenom 9850 and I did collect a screen shot many moons ago for that article I linked above, and so here is my 1152x864 run:



As I said, the Graphics settings are not the same -- so Snow will be different - again, because Snow is GPU bound. However, Scott (the TR link you provided) gets around 79.2 FPS, I get 77.7 for the Cave segment ... that is within 1.5 FPS (1.9% difference)... this is what I would consider, within the margin of error ... the same. The point is ... I can reproduce the Tech report values for both the Phenom series and the QX9650 as well as the QX6850 .. though I have not done them all, I did do a few spot checks informally (no screen dumps, just checks to see if I could match that data) which was just a few tests and his numbers are spot on to what I can get with the same HW -- I have 99% confidence that, as he reported his settings, that his numbers are accurate.

What I am demonstrating and the point I want to make with this is that unless you can match configurations, ensure everything is the same, and account for the details ... then a direct compare is not possible .... THIS is why I call your GRID data bunk. I cannot reproduce it. No matter how hard I try there is no information in that thread that allows me to take the same HW, set up the same settings, and reproduce the 'hodge-podge' of results. As such, this invalidates the data set. This is also why my posts get so long, especially the lost planet experiment I produced for you ... I want to ensure that there is more than enough detail such that anyone who wants to and had the capability can reproduce my result... this provides credibility to the data by that fact alone. I was the same level of detail and verbosity in the GRID experiment, and so yes I expect you should believe my numbers over the other guys.

Without reproducibility, there is no truth.


Jack