no, just two

Too bad then... I wonder when games will start taking advantage of this? BTW, thanks for the answer

When quad cores represent a sizeable fraction of user-end computers, pretty much the same way dual cores have only just become standard for gaming. (If you can call it "standard" when all to many games don't support them in any real manner)

*applause*

Here's what I say to the "quad-ers"....... "sucka"!

I like to keep my money in the bank, where it might actually do something for me.

Instead of clocking-back cores, packing more of them together and then hoping/praying the software industry will enter an entire structural rewrite to the tune of excluding all but those with multi-moneypit cpu's......the manufacturer's should be pumping their R&D money into a complete rewrite of the basic cpu instruction interpreter. That way we could actually "move forward" and do more with less!

My 2 cents!   

the Monk

So, the information indicated in the recommended settings is redundant:

System Requirements:
Recommended - 2.2 GHz Dual- or Quad-Core Processor, 1 GB RAM (2 GB for Windows Vista), 256 MB DirectX 9 3D Video Card (Radeon X1600 / GeForce 7600 and above)

If it doesn't make a difference, the "2.2 GHz Dual" reference should be enough...

That can be found at the "STORE".

EDIT: Anyway, for something more meaningful, SINS is a game that's being advertised as limited only to the kind of hardware a player has. It would seem reasonable for the game to be not only scalable to the kind of display card one has (such as in the excellent GalCiv series) but also scalable in the number of processors one has (beyond dual-core).

Although at its first steps, Quad-core processors and up are the way of the future. SINS, due to the sheer scale of playability, would be a perfect candidate for the implementation of this kind of scalability, looking well beyond into the future.

But, of course, technological breakthroughs are costly and one can only hope...

That's my point. A real technological breakthrough would be for the chip makers to rewrite how the cpu interprets instructions instead of the "band-aid" of adding more clocked-back cores. Of course the "band-aid" fills the corporate coffers now, and is only inconvenient *insert sarcasm here* for most software code.

btw.... I've always loved that corporate lingo "scalability".......love it!   

Intel tried that approach with the Itanium and lost a LOT of money.

Most of us don't in fact succeed the first time.   

I'd would love to see the CEO say that at the share holders meeting   followed by group hug and some doughnuts   

Multiple cores is a very good way of enhancing system performance while avoiding all the nasty cooling issues that come from a high clock speed. Heck that's how very powerful industrial computers do it. The nice thing about my Quad is that when I do something intensive I can assign a whole 2.66GhZ core to the task, which is a hella lot of CPU time. The beauty is that I can encode video or fart around with Photoshop while playing CoD4 or something. I don't know how multiple-cores can be considered a "band-aid" when I can do multiple CPU intensive tasks on one computer that I couldn't do before on a single core machine.

BTW, as far as the game's requirements reading "dual core" I think thats an attempt to help people understand that a 3GHz P4 is not going to cut it, even though a 2GHz Core2Duo will. People don't understand that architecture is even more important than clockspeed when it comes to gauging performance.

architecture

The trouble with true multi-threaded applications would be that they probably wouldn't run at all on a single core machine.

Which is something makers of software will have to keep in mind for a long time to come.

Well I from experience can tell you going Dual from single is A HUGE improvement at least in general system responsiveness while going Quad the effect isn't.
its still there but on single/dual core(rare) aplications its not that large of an impact Vista runs smooth .. well sortof smooth ... i find HDD is usually the bigest bottleneck especialiy for multithreading.
Still Quads are quite Cheap these days - yes they cant OC a lot, but as far as gaming goes avarage joe usually runs out of gpu juice before cpu.
ofcourse unleass you do something crazu like
here

The important thing about multithred aps and why they run much slower on single cores then dual cores is thread switching. cpu has to jugle OS + background apps (if any) + game thread(s) and switches do take time\cycles

A few facts you should be aware of, then.

1) Intel is, in fact, working on a new architecture - what they call the "Teraflops research chip", where the lowest-level product will have 80 cores. (Probably 64, with 16 disabled to increase yield, but meh. It goes up from there.) This is not an x86-compatible cpu, although *this* time they're going to bundle an x86 emulator. See intel.com for details.

Anyway, the individual cores will be much slower than current x86 cores, although this is somewhat made up for by being able to use higher clock frequencies. You probably won't want to run it at full speed all the time, though - power usage is roughly proportional to the square of the clock frequency.

2) AMD is, instead, working on a new architecture with a low-count multicore x86 CPU in the center, surrounded by dedicated hardware such as physics chips, GPUs, etc. etc. - business as usual, basically. I really prefer Intel's approach.

3) Ad-hoc thread-level parallelism, such as.. pretty much every game that uses parallelism at all uses, is not the future. The future is in automatically dividing tasks at a *much* finer granularity, giving you enough fractions to feed 80 cores, 320 cores, any number of cores the user wants to throw at it. Ideally the (potential) number of divisions will be proportional to the amount of work that has to be done, so you can always handle a double-size simulation by doubling the number of cores. This is actually unusually simple for games, because they have a time axis; it shouldn't be too hard to design the code so the game state at time T is only dependent on its state at time T-1 (or T-n for n>0. The point is not to have state at T depend on /other/ state at T.) Then the order of the operations doesn't matter, so you can in principle do all of them in parallel.

This is made much easier by using fully functional languages such as Haskell. Sure, there's a performance cost (less of one as the compiler is improved; about 50% increase in cost now, if you're lucky), but who cares if you can use four times as many cores and take less time to write the game in the first place?


I hope you enjoyed this introduction to CS 3201.
Any questions?