Spring MT

Original post: http://pastebin.mozilla.org/1631995

Spring MT is a collection of hacks originally designed for BA.
Not to repeat someone else words wrong, you can read difference between OMP and MT here: http://springrts.com/phpbb/viewtopic.php?p=514080
There is a fact that you may get greater performance with it while spectating or catching up game. Especially, if bottleneck (reason of bad performance) is because spring don't use available threads of your cpu.

The developer branch had a hang (crashing) issue fixed, so it is possible to play a ZK match with MT without crashing/hanging (but desyncing in the end of every ~12th match).
A bit more info in the first link of this message.

Spring MT in it's current state is unsupported by Zero-K developer team. And will never be. So if you decide to compile fresh version with patches from developer branch, use it at your own risk and know that probably no one will fix bugs you may find.

If you want to know the future of spring multi-threading you may contact jK.
If you have something to ask about my spring-mt (zerver's implementation) experience you may contact me in lobby.

I hope I understood everyone's voice I heard right. That's the reason this post looks like this now.

EDIT: if you play only small/silly maps. I don't think you really need to prefer mt over omp at all, lol.

It is you! What you say!? Launch all "zig"! For great justice!

I mean, what is "not supported"? :P The thread seems not to be a bug-report one, but rather a win-report.

I used MT for about a week. My experience:

Overall framerate not improved much, but framerate while reconnecting was MASSIVELY improved. When rejoining a game, I typically get 2-3 FPS on my GTX580. With MT, I achieved the same FPS as if I was plying game at normal speed: anywhere from 40-150 FPS.

I desynced in around 10-20% of all games played. This is what caused me to give up after a week of trying it.

>HiKitty
I was getting hanging (freezing) issue too. Did you apply patches before compiling? Since it was fixed in developer branch, not in general master. (so that's why it requires applying cherry-pick at master version)

git clone -b master git://github.com/spring/spring
cd spring
git cherry-pick c9c1f42 # mt fix 1
git cherry-pick 02191c7cbe # gcc 4.7 fix
git cherry-pick 71f0272a25 # mt fix 2, the one that fixes hanging
and compile with cmake spring-multithreaded

you should use bastard cherry-pick. it causes less desyncs.

>you can get random visual artefacts, you wont get significantly better performance and desync breaks the game for eveyrone.

And this differs from regular spring how? :D

Seriously though, Licho's right. I had way too many desyncs to make using MT worth it.

quote: Seriously though, Licho's right. I had way too many desyncs to make using MT worth it.

Presumably, there have been recent fixes to that.

Besides, without testing, how can you find the bugs and fix them?

quote: desync breaks the game for eveyrone.

I'd argue that wider testing - as long as it's made clear to everyone involved that Bad Things Might Happen - could in fact fix the game for everyone by improving engine performance.

Also, while rendering isn't that faster, simulation in MT is really turbo, which is all the more visible when either catching up on fast-forward, or in all those 32x32 zombiegames.

Oh.

Wait, we're heading for multithreaded rendering? Yay for profit!

(i thought it was just sim that could be mt'd)

As far as engine devving goes you can't just assume something is implemented properly unless jK wrote it.