Dominions 3 on Dual Quad core machines

[MaxWilson]

No chance. Dom3 is written in C, which is almost intrinsically sequential and thus single-core for the next few years. Take advantage of your dual core machine to play music in the background instead.

Making proper use of many-core machines is a problem the software industry is very much struggling with.

-Max

[Agrajag]

Play music? What a waste.
Just play two games simultaneously.
(unless it's a quadcore)

[JimMorrison]

Well they better hurry, Intel has promised to bring their 80 core processors to the consumer market within the next 4 years or so.

[Loren]

MaxWilson said:
No chance. Dom3 is written in C, which is almost intrinsically sequential and thus single-core for the next few years. Take advantage of your dual core machine to play music in the background instead.

Making proper use of many-core machines is a problem the software industry is very much struggling with.

-Max

There's nothing about C that precludes doing things in separate threads. It's just an app not specifically designed for it generally takes a lot of work to convert.

There's also my opinion of C:

Programs, like ships, sink in the C.

[Aezeal]

That has got to be the very rare programmer humor. However rare it might be it's still not that funny though.

[NTJedi]

MaxWilson said:
No chance. Dom3 is written in C, which is almost intrinsically sequential and thus single-core for the next few years. Take advantage of your dual core machine to play music in the background instead.

Making proper use of many-core machines is a problem the software industry is very much struggling with.

-Max

Well anyone playing multiple large SP games could run them both at the same time and use the 'set affinity' so each game can use different CPUs. Another idea is maybe running one MP game and one SP game using 'set affinity'.

[Griefor]

While converting the entire application to multicore might be a huge amount of work, I'd think that converting just the battle resolution (which is the only thing that takes a lot of time anyway) shouldn't be that hard. As long as you know what you're doing (this is probably not a good first attempt at multicore usage) and the battle resolution is programmed the right way in the current state.

I mean, think about it. Every turn there is a bunch of battles, and they're all mostly independent from each other. The flow of the program might have to be changed somewhat ( prepare all battles first, then resolve them all), but the subsequent multitasking is basically just resolving multiple battles at the same time rather than one at a time.

[Agrajag]

I'm pretty sure it won't work.
IIRC Dominions uses tables of prerandomized numbers, and to show a battle again just means starting at the right place in the right table and recalculating the whole thing all over again.
If you simulate more than one battle at once, you can't tell which random numbers belong to which battle, since they'll all be taking random numbers randomly.

I'm not really explaining this well, but I hope you understand anyway

EDIT: Just to be clear, I'm not saying "impossible!"*, I'm just saying "harder than you think."
*-obviously it is impossible, even if at the worst case scenario it would take rewriting the entire source code from scratch

[Griefor]

Actually, random numbers are a good point. I hadn't considered those.

Unless the reverse engineering I did in my mind is wrong, Dominions relies on the deterministic nature of its code to produce the same battle results on every machine a game is played on. Without prerandomized numbers, a random number generator (one of those pseudorandom generators which produces the same results if you seed it with a static value) would still suffer from the same problem - it's only deterministic if all the calls to it occur in the same order every time.

As you said I'm sure it's still a solvable problem, but it's definitely something that would have to be thought about.

I *still* think it wouldn't be incredibly difficult to implement this, but I also don't think it's really necessary enough to warrant the work anyway. In my big SP game experience loading times were really not all that horrible. Although if it's just for SP, a simple pseudorandom generator that isn't deterministic would probably be sufficient anyway.

[thejeff]

There are no simple non-deterministic pseudorandom generators.
In fact pseudo-random is pretty much equivalent to deterministic.

I believe Dominions does use a pseudo random generator not a pregenerated table.

The simplest implementation that comes to mind for doing the battles in parallel would be for each thread to work with it's own RNG and for the main process to generate the seeds for each battle before spinning off the thread.