Spring is running in SMP

[Tobi]

Great you're looking at this!

For synced simulation, I'd keep that all in one thread, syncing multiple threads will be a HUGE PITA, and I mean really huge.

However, what you can do, and what will probably help quite a lot, is split up the ProjectileHandler into a SyncedProjectileHandler and an UnsyncedProjectileHandler (I once made a start with that by moving the projectiles in separate directories, see SVN).

Then you can keep the SyncedProjectileHandler in the single sim thread, and run the UnsyncedProjectileHandler safely in a second thread. (And sim could produce new unsynced projectiles using consumer/producer system too.)

Since a lot of projectiles are unsynced (and probably quite much are synced but could easily be made unsynced, hint hint ) this could move quite a big chunk of the simulation time to the second thread, with the additional benefit of better code design.

Also feel free to factor out Sim GL calls, since ideally the sim doesn't do any GL calls at all.

[zerver]

Hi Tobi!

That is a good suggestion!

I have more generic question on code optimization.

In lots of places in the code, there are repeated calculations. For instance:

tempMem[(y*xsize+x)*4] = (unsigned char)light.x;
tempMem[(y*xsize+x)*4+1] = (unsigned char)light.y;
tempMem[(y*xsize+x)*4+2] = (unsigned char)light.z;
tempMem[(y*xsize+x)*4+3] = 255;

In most cases, I believe the compiler will optimize to calculate the value in question only once. Still, I find it very ugly.

Is there some reason the code is written in this inefficient manner, or is it ok correct it whenever I see it (also in synced code)?

[AF]

I would be wary of the compiler if it did not auto-optimize that with a temporary variable, but in my opinion it would be clearer and more concise to clean that up. Whether it optimizes or not this is more about code readability and prettiness.

[Tobi]

If it improves readability, sure, make the change.

No need to do it for speed tho, as AF says the compiler will optimize that away anyway. (unless the involved vars have been declared volatile ofc)

It does much more aggressive optimizations at times...

[SJ]

For synced simulation, I'd keep that all in one thread, syncing multiple threads will be a HUGE PITA, and I mean really huge.

Im not sure if that is true. The data you operate on will have to be independent from other threads anyway or you will risk data corruption that could be fatal on non synced data as well (just somewhat less likely).

For example from what I have seen in other threads on this board LOS calculations is a problem in some cases. By relaxing the requirements for this from being updated directly to being updated next simulation frame (which wouldnt be noticable since the visuals updating is defered up to a second anyway) a lot of the cost could easily be spread over a number of CPUs (some sort of job interface would probably be very usefull here). This wouldnt provide any speedup on single core machines but by delaying the updates there also there wouldnt be any problems with syncing.

Sorry for interupting when I have no intentions of coding anything :)

[Peet]

Sorry for interupting when I have no intentions of coding anything :)

Hey, of course your input is useful though. That said, would you like to hop into this nice big black van? There is candy. And no chance of being kidnapped and forced to code or anything like that, of course.

[Tobi]

Problem is you have to make 100% sure the LOS update is finished at exactly the same frame on each client, otherwise units could be in LOS on one client and outside LOS on the other.

In short you need to put barriers in a lot of places and having experienced how hard it is to find sync bugs without threading issues, and having experienced how hard it is to find threading bugs without needing to care about sync, I don't think it will be much fun to debug sync/threading bugs in multithreaded synchronized code

When stuff is properly encapsulated and tested a producer/consumer like systems with barriers to ensure updates only start when unit LOS statusses are finished updating and main sim thread waits till LOS thread is finished before starting next unit LOS map read it could work (plus having 2 LOS maps and swapping LOS map pointers after each LOS update to prevent inconsistent reads etc.) yeah, but I don't think it's worth the trouble. (in particularly not before all code that's easier to make multithreaded is made multithreaded )

I don't mind you interrupt btw, I didn't do much coding lately either

[SJ]

When stuff is properly encapsulated and tested a producer/consumer like systems with barriers

Well my point was that the LOS updating system would be quite simple to turn into this sort of system given that you dont require the update to go live until the next frame. It would require a copy of losmap, heightmap and the position of the units needing LOS recalculation (possibly some more stuff that i have forgotten). Copying the maps do of course cost a bit but at least its a fixed cost and could be avoided on single core systems if one wanted to do a special case for them.

This should in my estimation be a lot easier than say trying to create a threadsafe interface between rendering and update code.

[Pxtl]

Because everything is so inderdependant, you'd have to do a lot of rendezvous-and-copy stuff. Basically, you rendezvous a thread, copy a bunch of crap over to it, and then let it do it's stuff in parallel to your stuff. Then, when you're done your stuff, you rendezvous again with the thread and read back the results.

Not easy, not necessarily optimal, but pretty safe since you make sure that X is exactly in parallel with Y - no race-conditions. The trick is that you have to copy EVERYTHING that isn't read-only, so it is potentially slow.

[jK]

Problem is you have to make 100% sure the LOS update is finished at exactly the same frame on each client, otherwise units could be in LOS on one client and outside LOS on the other.

In short you need to put barriers in a lot of places and having experienced how hard it is to find sync bugs without threading issues, and having experienced how hard it is to find threading bugs without needing to care about sync, I don't think it will be much fun to debug sync/threading bugs in multithreaded synchronized code

When stuff is properly encapsulated and tested a producer/consumer like systems with barriers to ensure updates only start when unit LOS statusses are finished updating and main sim thread waits till LOS thread is finished before starting next unit LOS map read it could work (plus having 2 LOS maps and swapping LOS map pointers after each LOS update to prevent inconsistent reads etc.) yeah, but I don't think it's worth the trouble. (in particularly not before all code that's easier to make multithreaded is made multithreaded )

I don't mind you interrupt btw, I didn't do much coding lately either

heard of OpenMP? (wiki)

ps: it is included with >=gcc4.2 and uses pragmas

[zerver]

I want to upload my multithreaded version.
Someone please give me write access to the SVN.

Thanks

[Vadi]

Edit: nvm. Can't wait.

[Auswaschbar]

I want to upload my multithreaded version.
Someone please give me write access to the SVN.

Thanks

I can't give you access, but I could commit your patch if you would upload it somewhere.

[zerver]

I just multithreaded CBFGroundDrawer::Draw() as well and initially there is a whopping 50% higher FPS (60 instead of 40) with max terrain detail when displaying the whole map on Small Supreme Battlefield.

[Kloot]

That sounds about right, when drawing the entire map
no vertices are culled (since all big texture squares are
visible) so it comes down to the LOD tessellation steps
alone how many are inserted into the VA. With two (vs.
one) threads the number of iterations per thread and
thus the thread vertex count would be halved.

[clericvash]

I just multithreaded CBFGroundDrawer::Draw() as well and initially there is a whopping 50% higher FPS (60 instead of 40) with max terrain detail when displaying the whole map on Small Supreme Battlefield.

Wow will this get commited?! I only have single core but will get a dual core soon probably so these changes will be great.

[Vadi]

I just multithreaded ... as well and initially there is a whopping 50% higher FPS (60 instead of 40) with max terrain detail ...

You're a freaking hero.

[AF]

I assume you all have threaded optimizations turned off? Perhaps with these improvements threaded optimizations may actually have a performance benefit rather than the opposite.

[Myg]

How about an official list of all the sections which can be made multi-threaded easily and safely without any locks/unlocks?

[Kloot]

sure, here it is: []