Nothing definate at this time. All in all the multi-core plan works a little like this, let's create a game first and then see how much time we have over for things like multi-core support.
So, anything definite on multi-core support for Vicky2?
- Thread starter delra
- Start date
-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Showing developer posts only. Show all posts in this thread.
there again perhaps we aleady have multi core support in our code but had to disable it due to problems and the only thing we need to do is find the time to try and fix these problems during development? There again what do I know?
"Just" code a new engine? Do you know what you just said?
He said no Victoria 2 thank you very much. The masses have spoken; time to Europa Universalis:Total War.
I'd actually prefer to wait till we have a working game before making such claims, there again I am a little stupid now amn't I?
It is not that easy, no. In theory, sure, but have you tried? We have hundreds of thousands of lines of code that have to be handled. We have to make sure that we do not get a lot of strange bugs that can easily occur when you do something like this. It's not like it's a yes/no situation though. We could have multi core support for some features and not for others. We'll see what works, and what there is time for.
Last edited:
So you effecively describe a two thread model... Mind telling how you move from that to four cores? Furthermore, all the heavy game calculations is on your 'server' part so the client will not be displaying any updates until the 'server' is done. Nothing wrong with that (it does prevent interface lag), but it doesn't magically scale up either to utilize multi core CPUs. Unless you'll add that the game server should be run by multiple threads, in which we're back to the "how to break up heavily data dependent calculations"-problem.
delra said:
I thought people with computers too slow to run EA games had single core computers?
Last edited:
its not as simple as you make it out to be. Good overall usage of multithreading that dont actually end up slower on a lot of users computers is a hard problem (threading parts and specific algorithms is much simpler).
here are two possible problems I can see with the approach you suggested.
- client interface thread is only a small fraction of the total cpu usage, and a lot of that is offloaded on the graphics card (so this is concurrent processing too), splitting like this gives no large benefit, and due to point two might be detrimental:
- a lot of the data will need to be accessed from both programs client/server so the memory use of the system will be much higher. requesting data across network will take time if we try and get around the memory usage. (which freeciv might do, turned based gamplay gets a lot more leeway here).
We do keep this stuff in mind when code is written. Performance is important and there are areas where multithreading can be very helpful but its not the perfect solution to every problem and it does give a lot of development overhead.
its not an all or nothing issue and nowhere near as drastic as functional/oop swap but it is something you have to think about. Not all problems are solvable realistically in a multi-threaded way and some problems lend themselves really well to it. example:
bad problem: very inter-dependent supply calculation system
good problem: particle system simulation with lots of independent calculations
Last edited:
there was a thread
D) up requesting CUDA support a few weeks ago massive threading CPUs will be here sooner or later yes. People are still looking at good solutions for games due to the heavy shared data problems they have. Most current games on PC I know about still seem to run gameplay single threaded and offload physics/graphics/animation etc simulation on multiple cores, e.g all stuff that have a lot less strict requirements on it (e.g you can cheat a lot) than say calculating if your farmers in england are rising up in revolt about the lack of good gin on the local market.
Last edited:
the unix model works yes, but its solving different problem otehr than scalabilty really, namely: many cheap slim client computers + a big server (your normal computer student lab at university), also being able to easily supply many different possible interfaces (text based, windom manager 1/2/3 etc (blackbox is still best)) I noticed freeciv also has a whole bunch of different interfaces. So the actual problem of speedign up the heavy calculation remain.
Lets just say we'll add as much as is needed for good performance.
I don't think you can say either for certain.
Yes AI depends a lot on speed of computation but any predictions from our side are likely to be off.
What he pointed out is that you can't execute a computation faster than its longest serial part. So that means that 1) we'll see diminishing returns on increasing number of cores (even if you have an infinite number of cores latency won't be better than the limit set by the longest serial operation), 2) AI may be improved through refined serial algorithms that might offset the opportunity cost of parallelizing existing algorithms.
We simply can't know here without seeing into engine internals... Actually, I doubt the dev team themselves can - thus parallelization is an uncertain investment and that's why they put it low on the list of priorities.
Yes AI depends a lot on speed of computation but any predictions from our side are likely to be off.
What he pointed out is that you can't execute a computation faster than its longest serial part. So that means that 1) we'll see diminishing returns on increasing number of cores (even if you have an infinite number of cores latency won't be better than the limit set by the longest serial operation), 2) AI may be improved through refined serial algorithms that might offset the opportunity cost of parallelizing existing algorithms.
We simply can't know here without seeing into engine internals... Actually, I doubt the dev team themselves can - thus parallelization is an uncertain investment and that's why they put it low on the list of priorities.