Number of Cores vs. GHz
#21
Just to be sure, the QX9300 (quad) with GTX 260M (laptop) should be able to play most of the games on the emulator right? It only has 2.53ghz and will only be able to use 2 cores. But I think the video card should help out.

any thoughts?
Windows 7 - Asus G73jh-a1 - 17-720qm @ 1.6 GHz (2.8 GHz)(2.4ghz)(1.73ghz) - ATI Mobility Radeon HD 5870 @ 700/1000 (sometimes oc to 800/1100) - 8 gig ram
Reply

Sponsored links

#22
So, are there going to eventually be ways to code programs more effectively for multiple threads? If not, what is the point of pushing for more and more cores? Other than the obvious marketing ploys.
www.twitch.tv/krazytrumpeter05
Want to stream your games? Let me know and I can help you get set up with Open Broadcaster Software.
Reply
#23
(09-16-2009, 06:16 PM)Xellon Wrote: Just to be sure, the QX9300 (quad) with GTX 260M (laptop) should be able to play most of the games on the emulator right? It only has 2.53ghz and will only be able to use 2 cores. But I think the video card should help out.

any thoughts?

I haven't met a game my 2.2 won't play at at least 30fps (beside SvR) so a 2.5 should be fine
Reply
#24
Quote:So, are there going to eventually be ways to code programs more effectively for multiple threads? If not, what is the point of pushing for more and more cores? Other than the obvious marketing ploys.
You know, personal computer are only small part of computer market, and it's development could be compared with working stations development on 70-80-90. Their power was low, so nowadays usual office task was stress on such platforms. And, as you could observe, multithreading was usual toy for big Unixes. Dual-cores analog (two-processor systems) was highly available, but more (4th processor SMT) cores was used almost only for servers, and massive mutiprocessing -- for scientific needs. Why? Because there is no way to made a linear algorithm multithreaded. If you have a big for cycle, you could use power of multitasking, but in user-oriented filed such cases are rare (and even in this case threads with number 3 and more would be better use unused power of second core, uinstead additional one).

You should understand, that if program has a small part of memory, where it wrote and read from different threads, than multiple cores would de HIGHLY ineffective. Because such memory could not be effectively cached (cache would be synced all of the time), so it's recommended that data space of thread will be separated. Memory sync is not uniq -- user input, vsynced frame creation (or other time-specific sync).

So the better CPUS is sigle-cores, with multithreading programs on them. But, CPU clock is limited (right now 3.3GHz is maximum market clock's, i7 could turbo boost even more, but no more than 3.6GHz), so it's usefull to get a second core (as in past -- second CPU). But more CPU is needed ONLY if you know, what are you gain from it.
Reply
#25
Big Grin 
I know the reason for the current limitations and ineffectiveness of multithreaded apps, but my question was if there are programming techniques or languages on the horizon that would overcome these pitfalls.
www.twitch.tv/krazytrumpeter05
Want to stream your games? Let me know and I can help you get set up with Open Broadcaster Software.
Reply
#26
(09-16-2009, 09:00 PM)KrazyTrumpeter05 Wrote: my question was if there are programming techniques or languages on the horizon that would overcome these pitfalls.
a few games have 64bit and multi-core support, it's being worked on apparently, but it's not in its best shape right now.
Reply
#27
Two cores are always best IMO, the cache's also only shared between two cores, instead of 4..

The E8600 will destroy ANY quad in games that only support 1 or 2 cores.
AMD Phenom II 940 @ 3.6GHZ, 4GB PC8500 @ 1100MHZ, 4870x2 @ Stock.
Reply
#28
(09-16-2009, 09:00 PM)KrazyTrumpeter05 Wrote: I know the reason for the current limitations and ineffectiveness of multithreaded apps, but my question was if there are programming techniques or languages on the horizon that would overcome these pitfalls.

It's not as if there is a lack of language constructs or techniques, it's just that programming multithreaded programs is plain ol' hard work and very few applications are worth the effort of re-writing to use multiple cores.

In most complicated applications (such as PCSX2), everything is connected and inter-dependent in ways that hurt the brain. Many of these potential hazards are avoided in single-threaded programs because you can be absolutely certain of the order in which operations will execute, with multi-threaded and multi-core programs it all goes out the window. You must explicitly write control mechanisms to handle access to shared memory resources, and make dead sure the correct signaling code is in place to maintain program sanity.

Take your average 3D PC game. The physics engine (in whatever form) depends on the game state, and the game state depends on the physics engine. Attempting to separate these onto different processes or cores is ridiculously hard because they are so tightly coupled that any 'gain' you would achieve by them executing in parallel is utterly negated by all the overhead you'd generate attempting to keep them in sync.
"This thread should be closed immediately, it causes parallel imagination and multiprocess hallucination" --ardhi
Reply
#29
(09-16-2009, 09:35 PM)Sythedragon Wrote: Two cores are always best IMO, the cache's also only shared between two cores, instead of 4..

The E8600 will destroy ANY quad in games that only support 1 or 2 cores.
With PCSX2 using dual core support, plus gsdx being able to use a core to itself, it's getting to be a case of quad core being preferrable these days. Also, it comes down to instruction efficiency per core that determines the best performance in gaming or any other CPU intensive application. I'd be willing to bet that my i7 would crush an E8600 in any benchmark, be it gaming or otherwise.Wink
Intel Core i7 920 @ 3.4 Ghz | 6 GB DDR3 RAM in Triple Channel | GeForce GTX 285
2.5 TB Hard Drive Space | Windows 7 Ultimate x64

Official betatester of PCSX2
Reply
#30
(09-16-2009, 09:00 PM)KrazyTrumpeter05 Wrote: I know the reason for the current limitations and ineffectiveness of multithreaded apps, but my question was if there are programming techniques or languages on the horizon that would overcome these pitfalls.

Not really.

I mean there are things you can do to utilize more cores in apps that aren't well suited for it, but the gains aren't going to be significant. Like GSdx's software renderer, the real returns will diminish with added cores, such that adding more cores only gives a few %'s real speedup. Finding useful tasks for 3-4 things isn't too hard. Finding useful tasks for 6-8 things in parallel is much more difficult. And looking to the near future, when we have 16 core/thread CPUs? Good luck!

I suspect games in specific will find ways to utilize more cores, by planning the design of the games around the theories of having those cores for use. Mostly this means increased numbers of particles in particle effects, and more complicated AI processing per "intelligent" entity in response to the environment. But even these can fail: they rely on having a set of non-nterdependent entities that update themselves based on a static set of data (usually the state of a level).

... but if you have a fully dynamic environment with intelligent entities that interact with each other, then you may not be able to process them in parallel because their order of logic processing may be dependent on sequencing and hand-shaking.

So what you'll probably see is more superficial candy coating added to newer games. Non-ininteractive stuff being updated and displayed in the background of levels, and you probably won't even notice 2/3rds of it. Wink And even then most of your cores will be under or un-utilized, because processing that sort of stuff can only make up so much of the workload of updating a game's state.
Jake Stine (Air) - Programmer - PCSX2 Dev Team
Reply




Users browsing this thread: 1 Guest(s)