Wait on buying comp? Dx10 not ready?

[ket222]

From things I've read here and elsewhere, it sounds like it might be better to wait about 9 months to a year to really get optimal use of a quad core and vista/dx10. is that so?
- will lots more games be out for quad core by that point?
- will the next TW game use quad or at least dual 2 core? will it have a new engine? how much better will it look, and how many more soldiers/detail/improved landscapes will there be if it's a new gaming engine?
- if a new top of the line quad is worth 4000.00 now, how much would the same comp be 9-12 months from now approx?
- what will be out there in a year? more than quad core? how much improved will comps be and will any games catch up? will there be anything better than crysis by that time?
thanks!

[Dick]

will lots more games be out for quad core by that point?

Some games will use quad core probably, but as dual core is only being used now, it is unlikely it will be an everday occurrence.

will the next TW game use quad or at least dual 2 core? will it have a new engine? how much better will it look, and how many more soldiers/detail/improved landscapes will there be if it's a new gaming engine?

It's likely the next engine (which will probably be used by the next full TW game if things go as expected) will have dual core support. I can't see a reason why it wouldn't. I'm not going to guess at graphical features, but only say they will be better than M2TW.

if a new top of the line quad is worth 4000.00 now, how much would the same comp be 9-12 months from now approx?

Depends on a lot of factors such as competition, new models, stock numbers. It will be cheaper, but how much is anyone's guess. It is certainly not worth buying a £4000, or even $4000 processor right now.

- what will be out there in a year? more than quad core? how much improved will comps be and will any games catch up? will there be anything better than crysis by that time?

Comps will be better as normal, more games will use DX10. Quad core might be improved upon but it's unlikely, and almost impossible that it will be used properly.

You're asking alot of questions that require conjecture, so pretty much everything above is my opinion and there's little hard fact to back up anything I say.

[Hadrian]

Some games will use quad core probably, but as dual core is only being used now, it is unlikely it will be an everday occurrence.

@ket222
Since KR did such a good job of breaking down your post, I'll work off of his if thats OK. Almost no games currently utilize even dual core and they've been out for well more than 2 years now so games using quad core are probably at least 4 years out, if not more.

It's likely the next engine (which will probably be used by the next full TW game if things go as expected) will have dual core support. I can't see a reason why it wouldn't. I'm not going to guess at graphical features, but only say they will be better than M2TW.

It would be shocking if the new TW engine didn't utilize dual core processors because RTS games are the perfect gaming genre to make use of them. RTS games work the CPU harder than any other type of game whereas your typical FPS works the GPU the most.

Depends on a lot of factors such as competition, new models, stock numbers. It will be cheaper, but how much is anyone's guess. It is certainly not worth buying a £4000, or even $4000 processor right now.

I am a lover of top end components, but all those super expensive top end components get alot cheaper if you wait a little and let the drivers mature. I just bought an FX-60 processor for $299.00, they were $1,012.00 just 11 months ago. Wait on the high end quad core, you won't regret it.

Comps will be better as normal, more games will use DX10. Quad core might be improved upon but it's unlikely, and almost impossible that it will be used properly.

As Richard said, since were talking conjecture we can only guess, but a Conroe, some DDR2 memory, and a sold 680i mainboard with some type of 8800 GPU should keep you in gaming heaven for quite sometime to come....

[Simetrical]

Some games will use quad core probably, but as dual core is only being used now, it is unlikely it will be an everday occurrence.

I'm betting a lot of developers who start writing multithreaded code will go ahead and use a relatively large number of threads, not just two. (Code written for many cores will work just as well on fewer cores or a single core: the threads will just take turns as processes normally do.) But I haven't ever done multithreaded programming, so that's just conjecture from me. Could be that writing a game using ten or twenty threads would be either harder or less performant than doing it with just two, given a one- or two-core setup.

[ket222]

wow, it sounds like there is no point in going quad core even a year from now, if the games don't catch up by that point. Strange. Frustrating!

i'm encouraged to hear you guys think the next TW game will involve a new game engine using dual core. i'd love to hear your perspective about how much better that will be visually, but it sounds like no one knows. I assume the new game engine/game will come out by next Christmas (I don't like saying holidays!), and that game is what we will hear about on august 23 with the big announcement?

I just wish I would hear of some real WAR games coming out using dual core--WWII tank simulations, naval simulations etc? does anyone know of any of these? it's troubling that realistic wargames always seem to be way behind graphically

[numerosdecimus]

I'm betting a lot of developers who start writing multithreaded code will go ahead and use a relatively large number of threads, not just two. (Code written for many cores will work just as well on fewer cores or a single core: the threads will just take turns as processes normally do.) But I haven't ever done multithreaded programming, so that's just conjecture from me. Could be that writing a game using ten or twenty threads would be either harder or less performant than doing it with just two, given a one- or two-core setup.

It's different from what you said in some ways.

Here's an example:

You have four processing units, right? You have a program that's divided by 8 tasks, be those sound, general processing, loading geographical data, etc, etc, etc.

The first 4 task will go to each core seperatly, the first core to finish it's task will be vacant, thus the 5th task will go to that core, after another one has also finished it's first task it will be the one to process the 6th task, and so on.

I think it's all a matter of the complexity of the task, more detailed and complex it is the longer it will take for the core to finish it. But multicore processing software won't lead to a world full of wonders, it's will just substancialy increase the performance, at least with first generation software and hardware using this processing feature.

[Simetrical]

It's different from what you said in some ways.

Here's an example:

You have four processing units, right? You have a program that's divided by 8 tasks, be those sound, general processing, loading geographical data, etc, etc, etc.

The first 4 task will go to each core seperatly, the first core to finish it's task will be vacant, thus the 5th task will go to that core, after another one has also finished it's first task it will be the one to process the 6th task, and so on.

That's not really how it works. All eight tasks are allotted time slots by the scheduler, which also decides which cores to put each on. It might be something like core 1 gets tasks 1-2, core 2 gets 3-4, up to core 4 getting 7-8, distributed according to how busy each one is: if thread 1 is using a lot of CPU time, the scheduler might put it on its own core with relatively few other threads.

Then each thread gets a time slice. Assuming the simple thread distribution given above, and a time slice length of (say) 10 ms, we would have thread 1 getting 10 ms of CPU time; then thread 2 getting 10 ms of CPU time; then back to thread 1 again; and so on. On a single-core system, an eight-threaded application would work identically, except that all eight threads would alternate on the same core. So thread 1 might get 2 ms, thread 2 would get 2 ms, then thread 3, etc., until you get to thread 8 and then back to 1 again.

In practice you'll have interrupts as well, which mean they won't necessarily use their whole time slice at once, and of course they all have to share with other programs that are running. Plus every once in a while the scheduler will tweak which cores get which tasks. But the basic idea holds.

As a side note on why this doesn't give fourfold performance improvement, since each thread is getting four times as much CPU time. First of all, threads won't always use their entire timeslices, since they're partly I/O bound. That is, an AI thread has to figure out what your enemy should do next, but once it's figured that out, it has to tell the other threads and wait for them to finish, print the decided actions to output devices, and wait for player input before it can start processing again. (This is not the case in purely CPU-bound applications, such as something that calculates the digits of pi for five hours straight. That will do twice as well given twice the CPU power, although of course it might be difficult to multithread.)

Even to the extent that threads are purely CPU-bound, they probably aren't going to be equally so. Threads 3 and 6 might need a lot more CPU time than the other threads, say. They'll probably get cores mostly to themselves, which they might be using to 100% capacity, but the other two cores will still just be waiting on them. That's why you get diminishing returns for adding more cores. The ideal multithreaded application would have a very large number of threads, each of which can run for a long time without waiting for the others, but in only a few cases is it possible to really scale CPU performance linearly with the number of cores. Threads almost always have to wait on each other's results at some point.

I think it's all a matter of the complexity of the task, more detailed and complex it is the longer it will take for the core to finish it.

Yes, pretty much. The whole idea of multithreaded code is to split up complex tasks into subtasks that are as close to independent as possible, but that's not always feasible.

But multicore processing software won't lead to a world full of wonders, it's will just substancialy increase the performance, at least with first generation software and hardware using this processing feature.

That's certainly true.

[numerosdecimus]

That's not really how it works. All eight tasks are allotted time slots by the scheduler, which also decides which cores to put each on. It might be something like core 1 gets tasks 1-2, core 2 gets 3-4, up to core 4 getting 7-8, distributed according to how busy each one is: if thread 1 is using a lot of CPU time, the scheduler might put it on its own core with relatively few other threads.

Then each thread gets a time slice. Assuming the simple thread distribution given above, and a time slice length of (say) 10 ms, we would have thread 1 getting 10 ms of CPU time; then thread 2 getting 10 ms of CPU time; then back to thread 1 again; and so on. On a single-core system, an eight-threaded application would work identically, except that all eight threads would alternate on the same core. So thread 1 might get 2 ms, thread 2 would get 2 ms, then thread 3, etc., until you get to thread 8 and then back to 1 again.

In practice you'll have interrupts as well, which mean they won't necessarily use their whole time slice at once, and of course they all have to share with other programs that are running. Plus every once in a while the scheduler will tweak which cores get which tasks. But the basic idea holds.

As a side note on why this doesn't give fourfold performance improvement, since each thread is getting four times as much CPU time. First of all, threads won't always use their entire timeslices, since they're partly I/O bound. That is, an AI thread has to figure out what your enemy should do next, but once it's figured that out, it has to tell the other threads and wait for them to finish, print the decided actions to output devices, and wait for player input before it can start processing again. (This is not the case in purely CPU-bound applications, such as something that calculates the digits of pi for five hours straight. That will do twice as well given twice the CPU power, although of course it might be difficult to multithread.)

Even to the extent that threads are purely CPU-bound, they probably aren't going to be equally so. Threads 3 and 6 might need a lot more CPU time than the other threads, say. They'll probably get cores mostly to themselves, which they might be using to 100% capacity, but the other two cores will still just be waiting on them. That's why you get diminishing returns for adding more cores. The ideal multithreaded application would have a very large number of threads, each of which can run for a long time without waiting for the others, but in only a few cases is it possible to really scale CPU performance linearly with the number of cores. Threads almost always have to wait on each other's results at some point.

Yes, pretty much. The whole idea of multithreaded code is to split up complex tasks into subtasks that are as close to independent as possible, but that's not always feasible.

That's certainly true.

The thing is, the "interruptions" would be the "commands" for distribution of tasks. So in other words you would have info/parameter processing in order to perform further processing actions. A solution for this would be to have a "hidden core" or a "secondary core" which would decide when and to what cores which task give.

Actually, if you look carefully you will notice that I did not say anything wrong however you ADDED another feature (which on the other hand you could point out that my post was incomplete rather than wrong) and that's task distribution according to parameters. A good way to think of it would be by imagining a tetris game. It' a matter of optimization of task distribution by having in mind the complexity and thus the time the task will take to be fully processed.

Concerning my first post, have in mind that I went through more general lines of thought.

[Hadrian]

I personally don't think we'll see a new engine for the TW series for a couple of years as it took them 2 years to revamp the original engine and give us M2TW. It will almost certainly utilize dual core though. The imbedded DX10 of Vista and the new graphic principles that DX10 utilizes could offer some exciting possibilities, especially if the new engine was based on operating in that new OS.

An August announcment is probably about a new expansion for M2TW.

I would personally love to see a great naval game based on the glory years of the British navy between about 1775 and 1825. Sails II was as close as they ever came and that game was a disaster.

[Simetrical]

wow, it sounds like there is no point in going quad core even a year from now, if the games don't catch up by that point.

I think they will have, personally.

i'm encouraged to hear you guys think the next TW game will involve a new game engine using dual core. i'd love to hear your perspective about how much better that will be visually, but it sounds like no one knows.

It will make no difference visually. The CPU doesn't handle graphics. The difference will be in terms of non-graphical processing, like physics and AI.

I assume the new game engine/game will come out by next Christmas (I don't like saying holidays!), and that game is what we will hear about on august 23 with the big announcement?

CA always releases its new Total War game in the fall, then an expansion the next fall, then a new game the next, etc. At least, that's what it's done for eight years.

I personally don't think we'll see a new engine for the TW series for a couple of years as it took them 2 years to revamp the original engine and give us M2TW.

What they've done so far is use a single engine for two games while simultaneously working on a new one for the next generation. Shogun used a new engine, Medieval used an improved version of Shogun's engine; meanwhile they had been making a new engine for Rome, and then Medieval II used an improved version of that. I expect a new graphics engine for the next game.

[Roman Clone]

I think they will have, personally.

It will make no difference visually. The CPU doesn't handle graphics. The difference will be in terms of non-graphical processing, like physics and AI.

CA always releases its new Total War game in the fall, then an expansion the next fall, then a new game the next, etc. At least, that's what it's done for eight years.

What they've done so far is use a single engine for two games while simultaneously working on a new one for the next generation. Shogun used a new engine, Medieval used an improved version of Shogun's engine; meanwhile they had been making a new engine for Rome, and then Medieval II used an improved version of that. I expect a new graphics engine for the next game.

Sound The Retreat General, we are doomed. NO NOT THE MEDIEVAL 2 ENGINE!


psst! Rome 2 was due for this Spring.

[Arakorn]

Alan Wake will use Quad Core...

[ket222]

if they use the Med II engine (rather than new engine), how much will the graphics improve if it is for dual core and vista, and in what way? were you saying there might be more soldiers and explosions, but graphics of the uniforms, faces of soldiers, landscape may not change?
sorry for my ignorance on these matters!

[Simetrical]

Vista or not will make no difference unless they allow DX10, in which case the graphics might be prettier on high-end Vista computers than similar XP computers. Dual core or not will not affect graphics, but it would possibly allow (for instance) smarter AI, or shorter AI turns, or more accurate physics, depending on what they use it for (I'm betting not physics).