Spring is running in SMP

[zerver]

No here it is: [CBFGroundDrawer::DrawShadowPass()]

Actually, i already tried this and the results were good.

[ZellSF]

Is this something that has a chance of being included in any state in 0.77?

[AF]

As far as I can tell not all of the original threading code has been put into the svn although a branch was created not long ago to hold it.

I do know though that some code was committed by kloot that sped up the pathfinder calculations during loading using multiple threads.

Look at the svn log for more details.

[Vadi]

Map pathing was sped up too. Yay

[vraa]

For us laymen, how do we try this out and help with testing?

[clericvash]

Map pathing was sped up too. Yay

Well i hope some of these changes go into the next version of spring, as i will have a dual core amd within a few weeks.

[zerver]

Hi!

Tobi has given me SVN access [thanks!] and I will upload something maybe this week.

The likely outcome is that at the next Spring release there will be one single threaded exe (default) plus one experimental that is SMP enabled and can be downloaded from somewhere (this website, I suppose).

SMP adds too much complexity and bugs are very likely, unpredictable, and hard to debug. Because of increased overhead, the SMP enabled version will also run SLOWER on a single core machine. Therefore, two separate versions is a good idea. The next step would be to bundle the two exes into one and, depending on configuration settings and hardware, select the proper file to execute at runtime. If someone wants to work on this, fine. Right now I'm doing MT stuff only.

So far the following is multithreaded:
UnitDrawer::Draw()
UnitDrawer::DrawShadowPass()
BFGroundDrawer::Draw()
BFGroundDrawer::DrawShadowPass()

[AF]

Perceived performance and actual performance may mean that despite running slower on a single core machine it may appear to run faster due to the increased responsiveness.

[imbaczek]

AF: true, but the fps meter won't lie to anyone. 2 exes is probably the best idea for now.

[Tobi]

I have my doubts about a slower Spring with threading even being more responsive then single threaded Spring. (in particular because the same amount of code must still be executed the same amount of times (but with more overhead), and because of the strict requirements of when something needs to be finished executing, I don't think the first sign of a user input being accepted by the program will be any closer (in time) to the same thing in single threaded Spring. (and this is what defines responsiveness)

If you want more perceived performance then threading is a way over the top solution; just making orders show up in queues and giving unit acknowledged sounds before network roundtrip is probably way easier, doesn't actually reduce performance on single core systems, and has a bigger effect on responsiveness. (the orders ofc with a flag so they don't really exist for the simulation yet)

[vraa]

Excellent, I am very anxious at testing this out.

Are you only working to get this on dual cores, or completely expandable to eight cores (if there were that many things needed)?

I can't wait for an easy Windows exe, I'd love to help with debugging.

[clericvash]

If it is multithreaded that means it will go across many cores i think, i don't think there is an actual way to only code for 2 cores, if something is multi threaded that is just it.

[LordMatt]

If you want more perceived performance then threading is a way over the top solution; just making orders show up in queues and giving unit acknowledged sounds before network roundtrip is probably way easier, doesn't actually reduce performance on single core systems, and has a bigger effect on responsiveness. (the orders ofc with a flag so they don't really exist for the simulation yet)

That seems like a good idea regardless of what happens with the multi-threading. When lag gets above 500ms the host starts to have a significant advantage over any clients in high skilled games because of the delay in updating the viewport with orders.

[Vadi]

It depends on how many cores you have / how many threads your machine has. So if you got 8 cores, but the program made only 2 threads, only 2 cores will be used (but it'll be a lot better than the previous of one).

But I do think that kloot's threaded stuff for pathing maps will max out your cores (from reading the changelogs he did).

[Pxtl]

That seems like a good idea regardless of what happens with the multi-threading. When lag gets above 500ms the host starts to have a significant advantage over any clients in high skilled games because of the delay in updating the viewport with orders.

Oh? Is this where the nasty "I clicked but it thinks I dragged" issue comes from? Or is that poor processer performance. Either way, that one drives me nuts. When performance is hitting the crapper, I'll click on a spot, but because the mouseup and move events are being handled at the same time, somehow it thinks I dragged and I end up with a line of fusion reactors in my orders queue.

[zerver]

AF: true, but the fps meter won't lie to anyone. 2 exes is probably the best idea for now.

Actually, it does lie a bit. Or it has bugs.

Above I claimed a 50% increase in FPS for multithreading the map drawing, which was incorrect and partly due to bugs in the FPS system. It depends on the map, but the actual FPS gain is more like 25%.

The thing is that if you view one scene and read the FPS, then zoom into one corner of the map so the FPS jumps up to 300 and then go back to the scene that you originally viewed, you sometimes get a much higher FPS than at the first reading.

My multithreading code for some reason made this bug occur much less frequently, so I made the wrong conclusions about the frame rate boost.


To "gain responsiveness" threading the GUI could possibly work but that is not at all related to what I am doing right now. So, for a single core machine, like Tobi said, this SMP version means absolutely no advantages.

[Vadi]

Well, over half of spring players should see improvements anyhow (viewtopic.php?f=1&t=14353&start=0)

[jK]

AF: true, but the fps meter won't lie to anyone. 2 exes is probably the best idea for now.

+1

also I think there are ~40% with 1core systems in the community,
and some #ifdef ..#endif aren't that much work (atm the pathfinder
use 2 threads by default what will slow down the process for a lot of
ppl and won't use the full power a 4 or 8 core system).

[Kloot]

jK:

You think, or you know? Throwing out random percentages is
quite easy, so here are some of mine: 10% slower pathing by
default for 40% of all users and 40% faster estimation for the
remaining 60%, for a net speedup of 20% (the formula being
1.0 - (0.4 * 1.1 + 0.6 * 0.6)). If your 40% userbase all set the
configuration variable that controls the number of threads to
1 for optimal performance, then the gain will be 24% (formula
1.0 - (0.4 * 1.0 + 0.6 * 0.6)). The difference? 4%. Is that worth
dramatizing? Not quite.

[jK]

the 60% have to wait for the 40% to finish pathing

to be honest:
no, I don't see a think your code is a huge issue, cos afaik you only
multithreaded the pathing at start, but not the dynamic ingame
pathing (when terrains change etc.).
But, if you would use threads ingame, which need to synced a lot of
times (nearly everything needs to be synced...), it would become a
problem.
Also I think someone wants to multithread ingame pathing someday
too and won't improve the seperation of single core and multi core
systems then, so it is _now_ the time to do so.