Multi-Threaded Version

[Jazcash]

Spring is one of the most powerful RTS engines out there and is by far one of the most "Mass scale RTS's" in existence. However, it's also one of the only engines which doesn't have proper multi-processor functionality. If Zerver hadn't have come to this community then we probably still wouldn't be using Multi-threading.

Don't get me wrong, Zerver's done a great job but I just feel that the Multi-threaded Spring deserves more priority and could use some proper support instead of being a standalone app which has to be changed by Zerver himself to suit Spring.

However, as Zerver states and as is pretty obvious, MT Spring is unstable and has it's downsides. In all honesty, I'm only making this thread because MT Spring crashes for me in 75% of games that I play. However, I feel it does need more attention.

Most people nowadays use multiple processing, yet, the MT version of Spring is very hidden away under the "other" section of the downloads page. There's a lot of people out there who would want to use a multi-threaded version of Spring that have no idea it exists. There's probably also a lot of people out there who have no idea that Spring only uses one core and are suffering because of it when they don't need to be.

In my personal opinion, the Multi-threaded version of Spring should be fixed properly with some help from others and not just Zerver working on it. Then it should be made optional in the installer for a while and after a while it should be made default if there are no problems with it.

If there are any major reasons why we can't use multi-threading as default then I can understand but when there's no compatibility problems with it, I just don't see why it shouldn't be used. I mean, it can double, triple or if not quadruple FPS and allow high graphical settings to be used where with one core it simple wouldn't be possible.

[Masure]

...
I don't see that the single threaded build could be replaced by MT anytime soon, mainly because it has issues related to LUA. Solving the LUA issues would require that the synchronization interface be exposed to LUA. I.e. all LUA programmers would suddenly have to be multithreading aware, to lock and unlock resources and so on.
...

[aegis]

global interpreter lock?

what would cause lua to be called from different threads?

would it just be rendering thread(s) and sim thread?

[Forboding Angel]

+1 to OP

[MidKnight]

could we add a SetMTSupport function that, if not called, just runs the Lua on 1 thread? It'd be a nice quick workaround, no?

PS: Lua, rather than LUA.

[aegis]

give lua access to the interpreter lock, so a script can release it if it's thread-safe

[Machete234]

I really like the MT exe, just had a bigger game and Im pretty sure the performance doesnt go down as much when there are many units on a battlefield.

So I think it would be good to develop more in that direction,(almost) everybody has more than one cpu core today.
And if we can get perormance for the big battles out of it I think its worth it.
And multicore is the future for five years now.

I think as many people as possible should test the MT exe.

[Hobo Joe]

Agreed. I used the MT version for a while, it ran better than the standard release, but it was also unstable, it caused my luaui to crash many many times per game, as well as fairly common full game crashes.

[TheFatController]

I've never found the performance of single core spring to be a problem myself and don't see the need to sacrifice stability.

But also I am looking into stabilising BA's widgets for MT version.

[Master-Athmos]

The main problem around MT probably is that you cannot "add" this to something but you completely have to redo it and maybe even more than that. That's one of the reasons things like the pathfinder didn't get multithreaded alhough it most certainly would offer quite some opportunities for optimizations. When talking about what zerver did the real problems usually were about AIs and Lua stuff with LUPS being a good example. If I understood jk right LUPS would need half of a rewrite to completely stop bitching with MT and that's probably not better for the AIs...

At the same time I can imagine this work being an extremely boring job so you probably have a hard time at getting people motivated to do serious work on this...

[Beherith]

I dont know what widgets yall are running, I run a fair few ( but almost none that draw into the game area, except defencerange) and besides some occasional GML error spam, it hasnt crashed in the last 30 games on Throne. And all of those are really taxing games (regularly 1.5k+ unit endgames).

[very_bad_soldier]

but almost none that draw into the game area, except defencerange.

You mean DR draws in sim thread?

[gonpost]

I dont know what widgets yall are running, I run a fair few ( but almost none that draw into the game area, except defencerange) and besides some occasional GML error spam, it hasnt crashed in the last 30 games on Throne. And all of those are really taxing games (regularly 1.5k+ unit endgames).

Yeah, now that I've got windows 7 pro x64 and the multithreaded .exe, I NEVER crash spring any more. It's really nice. And I have a lot of widgets. :D

The only weird bug I get is an odd 1FPS bug when I load the map, but I found out that that is related to using two monitors. I just disconnect the second and it goes away.

[Sausage]

MT runs fine for me, in fact I can't play without it tbh.

I also get GML error spam. Something about simpleparticles2. Happens when people start bombing with bombers.

I'm happy to say that is my only problem :]

I personally think that MT should be the default but I guess if some people crash 75% of the time then it needs moar fix. I bet it's that IceUI crap lol

[Beherith]

but almost none that draw into the game area, except defencerange.

You mean DR draws in sim thread?

I wasnt blaming, i dont know if it does. Its just the only widget I use that draws into game. (not ui buttons etc)
I also get the simpleparticle2 error.

[very_bad_soldier]

You mean DR draws in sim thread?

I wasnt blaming, i dont know if it does.

I did not think you were blaming. I really was just interested if you found an evidence that DR draws in sim thread because I would like to fix if it is so (AFAIK it does not do that). But if there is no evidence it is ok also

[lurker]

give lua access to the interpreter lock, so a script can release it if it's thread-safe

Lua itself isn't thread safe (for a particular lua_state). You.. can't do that at all.

[Pxtl]

This is probably going to eliminate all gains of multithreading WRT speed, but could all Lua be executed in a Rendezvous?

[aegis]

oh right, lua is register-based?