Dancing Hoskuld
Deity
From what I understand it is no longer linear. The increase in early times is the base turn time plus a small amount for cities and units. Later times have that base turn time plus a larger amount for cities and units.
Yes, V24 is rather slow compared to anything since V19. I haven't really been on Koshling's case about it though because I know he is very busy with Viewports and AI enhancements. That said, it would be nice *hint hint* to get turns in the early to mid game to go faster.
There are indeed no low hanging fruit that I am aware of. Some optimizations are possible but all come with programming time investment that I am not sure is worth it.Early turns on larger maps have increased due to the property system. Not sure it's tractable unless we lose plot sourcing of properties, or do some significant optimization work on the property solving ( I had a quick look and I didn't see any low hanging fruit really, though it's not code I am very familiar with).
Maybe city build evaluation would be a good target for some multithreading experiments. If I get it correctly most of it consists of information gathering that is stateless and finally results in a number that could then be compared in the main thread.I would dispute later eras being any slower than before - all the most significant factors are reduced according to every measurement I have made (at given map size and civ count). The only aspect I know that has grown in processing time is city build evaluation, which is pretty much a direct function of building and unit count (which have gone up a LOT in recent versions). More can be done, but whatever we do, the more stuff we add, the slower things will get as compared to if we had not added more stuff.
No idea - only the outer fucntion has a profiling tag (which I added to check the overall contribution of the solver). Will need profiling adding to all the significant interior methods to determine more.There are indeed no low hanging fruit that I am aware of. Some optimizations are possible but all come with programming time investment that I am not sure is worth it.
One possibility would be short cutting some of the property manipulators so for instance diffusion is not instantiated for a plot if the property value is 0.
Which step of the property solver actually takes the most time?
Yes, that was my thought also, though I think there are other things in terms of caching that are slightly lower hanging that would be natural first.Maybe city build evaluation would be a good target for some multithreading experiments. If I get it correctly most of it consists of information gathering that is stateless and finally results in a number that could then be compared in the main thread.
I am not a C++ person, and I don't understand the code very well, but I have an idea that might help with turn times. Would it be possible to cache the build lists and AI evaluations on city construction options? Then, you would only need to recalculate the build lists and AI evaluations when a city is done with whatever it is building. It would also make it so that the build lists would only have to be remade when a new tech is discovered or a new resource is acquired. Would this be at all possible? Or am I not understanding the code at all? (this is likely)![]()
I tried that now but it stops diffusion from 0 to negative value plots so it does not really work that simple.No idea - only the outer fucntion has a profiling tag (which I added to check the overall contribution of the solver). Will need profiling adding to all the significant interior methods to determine more.
I strongly suspect short-circuiting the 0-contributors would be a big help (at least early on wheich is when it is relatively significant)
I decided to do a test of performance with Talin's GEM save from the Gameplay/AI balance thread. The world in it is almost completely colonized, and it is a very mature save. For me, the results were the following.
Hardware:
-My old and crappy Core Duo @1.86 Ghz, so one core at ~1.86 Ghz for Civ.
Performance:
-An end turn, with Minimize AI turn times and Viewports, took 297 seconds for me, or almost five minutes even.
This game was at Medieval, so I'll bet that things will get worse in the Industrial and beyond, as there will be far more build options. It'll be interesting to see what others will have for performance.
@AIAndy: OK, that makes sense, it won't be that much of a gain anyways.
@AIAndy:
Hmm, You're right. I tested an early save with one, two, and three concurrent BtS Processes, and it did not scale linearily. With a 75 by 50 Viewport and all graphical settings on high, running one instance took 990 MB of RAM, two instances took 1443 MB of RAM, and 3 instances took 1801 BM of RAM. I stopped there becuase my processor was having trouble with that many C2C instances plus a program installing in the background. I have no idea why this is or how it could be important, but there you are.
That's not what AIAndy meant. He meant that a SINGLE instance with 'multiple' on took less than the same single instance without. What you are seeing is just single-imaging of the code, which is entirely expected.
That's not what AIAndy meant. He meant that a SINGLE instance with 'multiple' on took less than the same single instance without. What you are seeing is just single-imaging of the code, which is entirely expected.
In that case the difference I saw was probably just a fluke or due to it messing around with my settings as it unfortunately sometimes does (deleting my old ones ...).This is odd. Running the game with AIAndy's shortcut code, Talin's old and very advanced save, and a 75 by 50 viewport, the game used 1,670,912 KB of memory. Running it without the multiple in the shortcut increased it only to 1,674,332 KB of memory usage, according to the Task Manager.