Problems? See this thread at archive.org.
Guys run 3D Mark 05 instead. It isn´t as heavily CPU bound like 3D Mark 06 is and see what scores you get there. I agree with former that SLI really shines with resolutions of 1600x1200 and above. I mean just look at my score I have 10600 in 3D Mark 06 1280x1024 and 10100 in 3D Mark 06 at 1920x1200 that tells you something. On the lower resolutions these GPU´s really bottlenecks the CPU.
-
^LOL
Dexs magnanimous consesus after 11 pages
-
Working on the Crysis will try to update today or Monday.
Here are a couple new 3D Mark 06 scores to view that scored very well.
(Mid score out of 3 Runs). These are both with:
-Fresh Install of Ultimate 64 w/ SP1
-Q9550 Quad Core CPU
-4GB of Ram
-SLI 8800's
This is with a new driver version 174.82 that has started pre-loading on new orders and will be updated on Sager's website later tonight or next week. I will report back after Crysis is complete.
1st Run @ 1920x1200 and 2nd Run @ 1280x1024Attached Files:
-
-
Nice score at 1920x1200!
Just for fun... I'll bet a penny that the dual beats the quad by 6-7% in SLI.
Thanks in advance for doing the tests. -
Here is Crysis, everything high 1920x1200
Attached Files:
-
-
These tests have all been completed nearly immediately after the OS was installed and updated. I think there would be little variation if tested after it was broken in or used for a little while.
-
Any chance for some Xp results Justin?
-
Sorry if I missed it, but is that the quad?
If it is, it's a step in the right direction, because the minimum FPS numbers are higher than what Swiftnc got, even though he ran at a lower resolution.
I'd love to see the dual and the quad compared (remember, you can make a penny ), for a few of us do have the dual.
-
Nice results Justin. If we compare against my benchmark in the same resolution no tweaks though with my GPU overclocked and with DX10 high it looks like this:
!TimeDemo Run 3 Finished.
Play Time: 55.32s, Average FPS: 36.15
Min FPS: 9.15 at frame 144, Max FPS: 47.40 at frame 86
Average Tri/Sec: -23192520, Tri/Frame: -641478
Recorded/Played Tris ratio: -1.43
Your min is higher than mine, though my max is higher most likely due to my overclock on the GPU´s. It would be nice to see some overclocking on the GPU´s on this Clevo beast and see what the score would be then, should probably beat my machine at least
-
There are some overclocking results in this thread:
http://forum.notebookreview.com/showthread.php?t=236240
It ain't pretty!
-
Eleron Warning (sorta like a Miranda Warning
):
EDIT: Ok, Ok, I know I've posted another rambling monstrosity. Instead of trying to rewrite the entire thing (even Hercules couldn't have accomplished that task, I'm afraid), I'll just try to give the Cooks' Tour version here:
Begin Cooks' Tour version:
Basically, because the current Quad-core Intel CPUs are really two Dual-core dies stapled together, the processors on Die1 do not share cache with the processors on Die2, and, thus communication between the cache on Die1 and the cache on Die2 must take place over the shared-memory bus the four processors share. As a consequence, cache coherency functions, including even cache copy invalidation, take bus time in addition to the bus time that is normally taken to reread an invalidated cache copy from main memory.
As a result, on a per-processor basis, the current Quad-core CPUs are devoting a lot more shared-memory bus time to cache coherency tasks than are the Dual-core processors. Since each bus access is exclusive, and since the bus is slower than intra-cache access (in the case of shared cache) is, this all adds up to a much greater performance hit from cache coherence than you would expect solely on the basis of the Dual-core CPUs.
In addition, because each time the cache coherency function accesses the bus, even if only to invalidate multiple cache copies, access to the shared memory bus is denied to any other function that might access it, including any access that a GPU or a streaming audio application might want to make.
As a result, the performance of the two-die architecture of the current Quad-core processors is significantly below where it should be as a result of the cache coherency mechanisms used by the CPU.
EDIT: End of Cooks' Tour version.
I think I might have an idea why some folks have noticed that the Quad-core CPUs are underperforming the Dual-core CPUs being tested in these postings - performance degradation due to the overhead required to maintain cache coherency across the cores and, in particular, the overhead associated with maintaining cache coherency between the two pairs of processors out of which the current Quad-core is built.
Without getting into too many of the details (most of which I haven't mastered yet in any event), in any multithreaded or multiprocessor system, there are frequently multiple copies of data in cache that have to be kept consistent so that, e.g., two threads that are supposed to be accessing the same data item actually do so - if processA and processB both need to access Data1, and thus there are two copies of Data1 in cache, one each for processA and processB, each time one process accesses Data1, the copy kept in cache for the other process must be updated (or invalidated, so that the second process suffers a cache-miss and must read a fresh copy from memory).
For example, suppose that Data1 starts with the value 10. If both processes have started, then there is a copy of Data1=10 in cache for ProcessA and another copy of Data1=10 in cache for ProcessB. If ProcessA then changes the value of Data1 to 15, the ProcessorA cache copy of Data1 is now Data1=15. If cache coherency is not maintained, however, the cache copy of Data1 in ProcessorB cache is still Data1=10, which means that if ProcessorB then performs a computation that depends on Data1, that computation will be in error without cache coherence.
However, maintaining cache coherency takes up cycles and, if applicable, time on the memory bus the processors involved share - this is particularly onerous in the case of current Intel CPU designs because use of the bus by one processor excludes the other processors. Thus, if cache coherency requires use of the shared-memory bus, the system will suffer a hard performance hit as other necessary access to the bus is blocked for the duration of the coherency transaction.
Typically, the shared-memory bus is occupied for cache coherency purposes only after a cache copy has been invalidated and the processor accessing that cache copy has a cache miss and has to reread the invalidated data copy from memory. This causes a performance hit because (a) the bus is slow relative to the CPU, (b) it may have to pass a big data chunk, and (c) the bus is not available for anything else.
In the case of the Dual-core processors, cache coherency only monopolizes the bus when an invalidated copy is subsequently accessed by its owner processor, and thus has to be read back from memory. The invalidation process itself, however, takes place within cache because the two cores in a Dual-core Intel CPU share all of the L2 cache.
By contrast, in the case of the current Quad-core processors, cache coherency monopolizes the bus, not only when an invalidated copy must be reread from memory, but also when the invalidation process itself takes place. The reason for this is that the current Quad-core processors are not true quad-core processors, but two dual-core processor dies stapled together so that they appear to be a quad-core processor. However, L2 cache continues to be shared only by the two cores on each die, and thus communication between the cache on die 1 and the cache on die 2 must necessarily pass across the shared-memory bus.
To see this, I've attached a screen copy of Figure 2-9 on page 2-44 of the Intel 64 and IA-32 Architectures Optimization Manual, Order No. 248966-026, November 2007.
What this means is that each time a cache coherency invalidation task takes place, the Dual-core CPU takes care of it within cache, and doesn't tie the shared-memory bus up until an invalidated copy has to be subsequently refreshed. On the other hand, each invalidation task on a current Quad-core necessarily ties up the shared memory bus both when the invalidation is done as well as when the invalidated copy is later refreshed.
Now, obviously, a certain amount of bus-use for cache coherency is necessary and contributes to the overall performance of the quad-core; however, there are other multi-core logistical functions that can lead to so-called false-sharing, in which a data item in cache appears to be a shared item, the coherency of which must be maintained, even though in reality the item is not shared. One of the chief trouble-makers in this instance is so-called thread migration - the process whereby the scheduler moves a thread from one processor to another, frequently for load-balancing purposes. In that case, not only is the thread itself moved, but its cache is duplicated in the cache available to the other processor to which the thread has been moved. Until the original in the cache of the original processor is removed, the system will see two copies of a data item that need to be kept consistent with each other, and cache coherency overhead will be incurred to maintain that consistency even though it isn't needed because the data item really is not a shared data item.
This process is bad enough when it occurs on a Dual-core processor, or between the two processors on the same die of a Quad-core processor; however, it becomes a horrendous drag on performance when a thread is moved from a processor on one die to another processor on the other die. In that case, the effort expended to maintain the consistency of the false-shared data item necessarily results in monopolization of the shared-memory bus during the time that process takes.
Thus, at bottom, one of the sources of the problems everyone's been having with benching the quad-core NP9262 against the M1730 with a dual-core (or even, as Justin did, benching an NP9262 against itself with a quad-core and with a dual-core) is most likely the fact that the benchmark program is either not policing itself carefully enough in terms of avoiding any unnecessary migration across dies (as opposed to processor cores) and probably also the fact that Windows (as far as I know) does not recognize the difference between cores and dies and, in pursuit of its overall load-balancing service, is probably willy-nilly moving threads across dies in pursuit of performance gains that are, in fact, illusory because the performance hit taken by the concommittant cross-die cache coherency is greater than the performance gain obtained by moving the thread in the first place.
This problem may also explain some of the problems with the 8800M in real-world situations such as running graphic-intensive games or even other heavy-duty I/O tasks such as audio streaming. Problems would arise to the extent that the GPU (or the audio player in the case of audio streaming) had to access main system memory - each cross-die cache coherency task will block the memory bus, not only for the CPU cores, but also for any other function that needs access to memory.
I don't know to what extent this problem can be mitigated using the current quad-core processors. At the level of overall load-balancing, only changes to Windows itself would permit the functionality to distinguish between cores and dies, and to take into account the performance loss arising from cross-die thread migration when determining how to balance the then-applicable load; however, even at the application/driver level, and even if Windows' load balancing cannot be controlled, the losses due to cross-die migration and cache coherency could be reduced by, e.g., assigning a forced affinity to each thread created that kept each thread from crossing from one die to the other (to the extent possible, obviously) - that might also entail limiting the extent to which driver workload is offloaded to system worker threads instead of being completed on a thread owned by the driver process(es) itself.
This also suggests that the NVidia unified driver system is inadequate to the task in this case because the unified driver that suffices for the dual-core systems is, at least right now, insufficient for purposes of running on a current quad-core system.
Unfortunately, I doubt if this problem (if it in fact exists) will really get addressed by either Intel, Microsoft, or NVidia given that Intel will, sooner rather than later, be releasing native quad-core processors to replace the current ersatz 2x2 "quad" cores.
Fig. 2-9 Core 2 Duo/Core 2 Quad Architecture Diagram (click for bigger pic):
-
Wow!
I really like your ideas, Shyster. I don't have any idea if this one is true, but, it doesn't matter, it's really nifty.
-
I know that I write long posts but you are a marathon writer Shyster. Will print it out and read it in thr train to tommorow
+1 for a well formed technical explanation of ones point of view. But I need to spread points before giving it to you again
Stay cool,
Trance. -
@Shyster1 , I dunno wth you just wrote there but I had to scroll 5 min to get the end of it.
I give you that much , you are a man of patience.
Must call Dance of Patience, if only I would know native american...
I am at a loss though,why is this a fiasco in the first place? it`s not like the difference is that huge.
Thanks for the cones,my brakes work fine now
Found it : Your name is EwGsf(chaw la chee sss gee) of Sorry, That word was not found in the dictionary. :twitcy: -
-
This was also shown with Justin's run using the E8400 processor, interesting isn't it.
Can't wait to see SLI performance with OC CPU and OC GPU.
I would do it, but i don't have the guts
-
cummon. do it bud.
FUN
My temps are well within range.
67 at max with TAT and even playing crysis only goes to 56 degrees. -
-
Probably another question out of sheer ignorance (or lack of ability to keep up with all your posts ), but have you tried overclocking just the FSB to see what sort of performance gains that alone nets?
The 9262 vs XPS1730 3Dmark06 score fiasco
Discussion in 'Sager and Clevo' started by WackMan, Apr 2, 2008.
