Home › Forums › General Discussion › req: Multithreading – performance issu large map
Tagged: large map, multithreading, performance
- This topic has 47 replies, 17 voices, and was last updated 8 years, 5 months ago by Krogoth_mk2.
October 10, 2014 at 11:12 #11332kockopesParticipant
game needs completely new multithreading rewrite of core
there were massive freezing every new month, since last updated it comes sometimes about 17th, but still, game is almost unusable related perhaps to traffic jams in cities or just big cities expanding and recalculating routes in same time in same cpu core…
same performance issue can be reproduced while building, buldozering, after each operation game freeze for seconds (up to 30s) so even if game is paused, slow recalculating after each change in infrastructure (roads/trains) making game totaly unusable
i have i4790 with 16G ram. (win/linux/mac – same performance issue) and only one core is in use, thats cleary first step what you should do – multithreadingOctober 10, 2014 at 14:01 #11348EnzojzParticipant
Multithreading is not an easy thing, because you need writing lock to prevent data loss.
However, compress save file can be perfectly done in another thread.
Perhaps a better solution is change the algorithm I think the dev can use some quick estimation to take the place of too exact 20min rule. If not, even with BFS it can eat up resource of computing very quickly.
October 10, 2014 at 14:15 #11350kockopesParticipant
- This reply was modified 8 years, 7 months ago by Enzojz.
i know it not ‘easy’ but we have 21. century…. multicore cpu are everywhere even in mobile and as i developing for ios/wp/vb… threading is basicaly required just becouse speed of results. so game like this 100% needs to use all cpu power.
btw. i hope that Train Fever will be best game ever soon 🙂October 10, 2014 at 15:21 #11361gGeorgParticipant
Multihreading a single task is not as easy, make task pathing for one vehicle to work in multiple threads is pain. How ever, complex simulation program like this another thing. There are few easyily separated tasks, who could share one data cube. each task could go his own way than send results to the cube. Separated proceses dont need to wait each other or know the status of another task. For example – taks pathing of your vehicles, pathing of people, task simulation grow of cityes, task user interface, and so on so forth. These are pretty independent. Could be programed like separate modules and run in separate threads.October 10, 2014 at 18:38 #11370benczeParticipant
“cleary first step what you should do”
i love the confidence 😉October 11, 2014 at 01:54 #11402bvParticipant
“cleary first step what you should do”
i love the confidence
Certainly – but he is right. I wrote threadsafe programs over 20 years ago, and it has not become more difficult since then. I suppose the main problem is limitations in game engines, which seem to have been hobbled by console hardware.
If you write today, you’d better be able to make use of 16 cores and 64GB RAM, because tomorrow some of your users will have that.October 12, 2014 at 23:36 #11504mikas24Participant
I can only agree that in face of perfomance issues, we have to consider using extra available hardware. One way or the other, they have to improve the code.
I wonder, if a faster graphic card will help. I have an aging HD 6950.
I doubt it, because I have no trouble moving around, zooming in and out even with big maps at 1900×1080 …the trouble is when we reach the XXI century an the cities begin to grow in population.
MichaelOctober 14, 2014 at 22:22 #11702CornughonParticipant
A faster graphics card doesn’t really help at all. I have an R9 290X and it still blows late game. I don’t know if nVidia users have better luck, some say nVidia has better OpenGL drivers but I think it doesn’t really matter in this case.October 14, 2014 at 23:18 #11704PaladinSMDParticipant
I have an GTX 680 and every first (or last) of the month when the maintenance cost are calculated i get a short freeze so better card is not solution. Also every year that the game safes is an pain in the *ss even when installed on an SSD.January 1, 2015 at 14:02 #15464
The problem is still around 🙁 . I’ve made it to the year 2055 and have been able to create a nice and profitable map. But for the last decade the performance has simply dropped significantly to a level where the game on that map has become unplayable. While i know i have a high resolution and an aging graphics card, the performance up to early 21st century is actually pretty good.January 1, 2015 at 16:35 #15482simonmdParticipant
I’ve been saying this all along and have just posted something similar in another thread. The OP has an i4 790, well I have an i7 920 and STILL have huge problems late game!
It amazes me that people are getting all exited about ‘main connection roads’ or ‘auto update’ or even ‘DLC packs’ when most of us can’t run the bloody game at all after 100 years or so!
As far as I understand it though, there is not much the Devs can do now though except totally rewrite the game to make use of hyperthreading, ie, ‘Train Fever II’. Despite all the problems this has had, I WOULD buy that!!January 1, 2015 at 16:52 #15485uzurpatorParticipant
As far as I understand it though, there is not much the Devs can do now though except totally rewrite the game to make use of hyperthreading, ie, ‘Train Fever II’. Despite all the problems this has had, I WOULD buy that!!
No. No, no, no, no, no. Just no.
Software is built incrementally. You don’t scrap a huge deal of your software to rewrite it unless you want your company to fail. The approach to this is to incrementally identify performance hot-spots and fix them untill you get the desired performance.
For example, at this point I work on a software that was first written 17 years ago and still gets sold. But it received a continuus stream of updates, patches and fixes over the years and while there are some issues in it, most problems from it that existed 15 or so years ago were fixed.
But that requires an actual software engineer behind this. Afair all people in Urban Games are academics.January 1, 2015 at 18:03 #15486
To go slightly off topic here uzurpator: a job title is meaningless to me. I’ve seen people with all the right degrees and verry nice papers that are capable of using some verry nice words in their feild of work, but when push comes to shove they fail miserably. And i’ve seen the opposite: people without the correct qualifications that really do know what they are doing. Knowledge and experience are important, not a piece of paper that tells you that you can do it.
But I do agree that if the coding behind the project is done in a proper way, it should be possible to trace the performance killers and attempting to rewrite those areas should be possible without the need to rewrite the entire engine behind the project.January 2, 2015 at 05:36 #15517simonmdParticipant
Well, if it CAN be fixed in its present format to allow hyperthreading FANTASTIC! I have been lead to believe this is very hard to do though and is basically a rewrite of the entire game.January 2, 2015 at 05:59 #15518
well unless someone from the studio who knows what they are doing makes a comment about it, it’s all just speculation on weither or not it is possible.
- The forum ‘General Discussion’ is closed to new topics and replies.