PCSX2 Problem With Cor i7+GTX275
#31
(11-22-2009, 04:13 AM)bkwegoharder Wrote: The way the i7s cache and memory was designed was to keep down on cases like that. Also, cache doesn't really effect performance for me in gta 4. I ran prime 95 small ffts test(the test that says it uses up cache and also maximizes FPU stress) and I ran it to run on threads 1, 3, 5 and 7, while I let gta 4 run on 0, 2, 4 and 8 using task manager. I saw no performance difference.

Well it's true that "cache threashing" is an overhyped drawback of multi-core CPUs. There's little evidence to support it, except in very specific controlled scenarios. This is largely due to the fact that caches over 2MB are neigh useless anyway (except for specific applications, namely zip archivers and databases), so as long as you have approx. 1.5MB per core L2/L3 cache, you're golden for anything that matters.

Furthermore, the concepts of HT actually favor smaller caches, and make up for cache contention (more in a second on that). So in fact, high amounts of cache thrashing will often actually perform better with 8 HT threads than 4 core threads.

That said, it's still a bogus test: While HT is reported as multiple CPUs in windows, it doesn't actually behave that way. This is especially true of Windows7, which does lots of clever tricks to maximize HT effectiveness. So even if the pretty graphs make you think the HT threads are being scheduled independently of the core threads (and thus they should be running as uncontested processes), they're not really.

So thread scheduling will still play a part, and this is a problem because even if the game doesn't force itself into the 'Above Normal' priority tier (not sure if games still do that--they used to), Windows automatically boosts priority of programs based on several factors:

* if it's in the foreground
* if it's fullscreen / maximized / minimized (fullscreen gets priority boosts, minimization gets the opposite)
* Direct3D APIs typically gets process priority as well

And if the game itself also boosts its thread priority to Above Normal, it compounds on top of those factors to the point where it'll make almost dead certain that stuff running in the background isn't going to slow you down much (instead the stuff in the background will run only in idle time).

Now, back to how HT works: One of the best things for HT is memory accesses (cache misses). When one thread misses and must stall for memory, the partner thread will execute instructions until the memory is ready. If both threads miss at the same time then you'll get a full stall, but typically that's very rare in practice, and I suspect it'd only happen with any real frequency if both apps being run on the same core have been intentionally coded to exploit that weakness (ie, special benchmark tools that don't give relevant feedback anyway since they've created a controlled condition that never happens in practice).

Bottom lines: The cache thrashing argument doesn't fly as a merit against HT. But you don't need a wonky benchmark to prove it -- just need some concrete analytical science. Wink
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply

Sponsored links

#32
Wow thanks. I like it when you post I always learn more.
Reply




Users browsing this thread: 1 Guest(s)