Where's MT Going?

[Argh]

But can't all the non-synced stuff just fight over mutex lock of data B, while sim just uses data A? We don't care if data B changes, after all, so long as data A matches across all sim states.

If the issue is simply bandwidth, I guess it's just not practical, but I don't know enough about these things to judge.

[SpliFF]

Well as I said you can't just over-simplify like that. Mutexes stop threads from running which basically defeats the purpose of having extra threads in the first place. You do need them and the system can often do other things while they wait but the point is the more mutexes you have the more "serial" you code becomes until you start to lose the gains or worse (like lockups - see "race condition" on Wikipedia).

Any sentence in this discussion that starts with "can't you just..." is probably going to be a silly question. Everything about MT is complicated which is why zerver deserves praise for what he's managed to acheive so far.

I happen to agree with him that Spring ST has no future and sooner rather than later we have to accept the multi-thread is the only way forward. Of course that doesn't mean it needs to be rushed or that there isn't lots of room to improve.

[jK]

If you don't have knowledge about something (in particular the mt implementation in spring and spring's multithreading problems) then it is better to say nothing ...

PS: I did my thread in dev-only forum, because of this type of discussion.

[Argh]

Fair enough. I'm just trying to understand what the fighting is about, really. I want this to succeed.

[jK]

I mainly meant Spliff, who just wanted to say that he "purchased a 6-core Phenon" and wrote a wall of text just about Multithreading in general while we are talking of applied Multithreading in current Spring.

[SpliFF]

jK, my post was for Argh's benefit.

The specifics are what you and zerver are arguing about whereas Argh's original topic question "where's MT going" is much more general, as in what is the plan for multi-threaded support, what are the issues etc. You'll notice he didn't specify any timeframe on the question.

The point of what I wrote was to highlight the longer term need to go further than we are now. There's a lot of talk about 2 Lua threads, 2 processors etc as though that's the problem but really by the time these developments settle down we'll have people asking why their 3rd, 4th, 5th, ... Nth core isn't being utilised. I'm an early adopted but the overall direction of the industry is clear. We need to look beyond quad-core if we want spring to scale.

What I was alluding to is the need for something like this:
http://www.inf.puc-rio.br/~roberto/docs/ry08-05.pdf

Or this:
http://lua-users.org/lists/lua-l/2006-11/msg00368.html

Or this:
http://luaforge.net/projects/helper-threads/

Or this:
http://kotisivu.dnainternet.net/askok/b ... rison.html

Or this:
http://luatask.luaforge.net/

The issue of Lua threading is not unique to Spring, and it is something I've looked into in the past and something that's the focus of a considerable amount of effort outside of Spring. I am quite confident there will be solutions we can implement or adapt born out of these efforts.

There is no simple plug-in solution that I know of but generic "inter-state" Lua IPC based on threads is ultimately a more scalable option than a single synced / unsynced split.

[Argh]

It isn't just Lua, though. Really, that's just the tip of the iceberg.

The real issue is getting OpenGL in general off of processor 0, and eventually splitting it up into further parallel jobs.

I really don't know how we're supposed to see things that zerver's current stuff has totally broken (unitRendering via Gadgets, for example) until this is what people focus on. Lua code that isn't actually OpenGL operations is not a bottleneck unless you're doing it wrong.

[AF]

Reread what SpliFF said and look at the docs, OpenGL isnt something you can just divvy up into multiple threads. Its not a maths problem that can be partially calculated and combined in the end, the order of function calls matters in many cases, and having them spread across 2 threads or more would lead to nondeterministic behaviour based on how long each one took to execute.

[zerver]

This example shows changes needed to LUPS in BA 7.19 to support dual states.

[hoijui]

aehm...
i though the plan was clear zerver...
either do your stuff in a branch, or in an other repo. now you applied to the the master branch on the main repo again...
why do you do that, after we other devs have stated that they are against this?

[SpliFF]

Argh, the idea that OpenGL itself requires multithreading is incorrect. OpenGL is NOT CPU intensive unless you're running it in software mode (ie, Mesa). Even the world's shittiest modern laptop is going to have some form of GPU. OpenGL itself is primarily involved in moving data to the GPU. It is sufficient to run it on one thread and if any multithreading is required there it will come from the Mesa library and GPU vendors - in other words, it will happen in the driver.

zerver's work is about how to get the OpenGL calls to the driver in the correct order when interacting with it from other threads. In that sense it should not matter if there are 2 threads or 2000. OpenGL does not know what to do when many threads are sending it instructions. It's like having 2 people talking at once. It looks like zervers GML queues the instructions so related actions happen in sequence. This may involve locking threads until others have released the queue.

The performance issues in MT have nothing to do with OpenGL itself. They are a consequence of the fact calls must be proxied and queued so that related actions (like setting a texture and using it) happen together - which introduces latency and other overheads. zerver could explain it better but I believe that's the core of it.

[Niobium]

This example shows changes needed to LUPS in BA 7.19 to support dual states.

The changes you've made look simple enough, though what are the technical details of SendToUnsynced? Does it add it to some queue which is worked through the next time unsynced goes to do something? I couldn't find any details on the wiki so..

In addition, I see you've reasoned about :GameFrame working well enough, but what about other callins like :UnitCreated/:UnitDestroyed? I have a few widgets which maintain a list of alive units via :UnitCreated/:UnitDestroyed, and then drawing stuff on them on :DrawScreen. The important part is that I don't need any alive-checks in the :DrawScreen code because of the single thread, but moving to a multithread there is the potential for this to be broken, and as such quite a few more widgets would need to be updated.. So what exactly happens in this case?

[zerver]

why do you do that, after we other devs have stated that they are against this?

jK is against this. I'm not so sure about you and tobi, as long as single thread is unaffected.

I'm the only one qualified to determine what is the natural evolution of MT, simply because no one else is working on it. The changes required for MT are small (and work with ST too), and no one else presented a solution that tackles the problem. Any solution that works will have dual states in one way or another.

[zerver]

This example shows changes needed to LUPS in BA 7.19 to support dual states.

The changes you've made look simple enough, though what are the technical details of SendToUnsynced?

Bascally you draw a big line though the middle of your widget/gadget and make sure not to share any variables across the line. DrawXXX() and Update() are unsynced, the rest are synced. All synced needs to forward the data using SendToUnsynced() if the unsynced side needs to know about the event. In MT, SendToUnsynced is delayed and therefore the unsynced side needs a ValidUnitID() check or similar.

Also make sure to put all Add/RemoveSyncAction() calls on the unsynced side. (Not in GameFrame if it's a widget.) UpdateCallIn/RemoveCallIn must also be on the same side as the call-in in question.

[hoijui]

jk, Tobi and me all clearly stated that you should use a topic branch, jk and me repeatedly so. that is the thing at stake, not your actual changes. soo.. we will just revert it again. why don't you do it in a branch?

[zerver]

I spent two full days testing and improving this. Please give it a try before reverting.

[hoijui]

we agree that we do not agree on how to handle the problem at stake. jk does not agree, i don't know about this stuff (undecided), and Tobi did not take a very clear stance, or i did not see it at least. what the majority decided though, is that you should us a branch, no matter how good your way of doing this is. even if there is no other way at all, use a branch! you know that we think so, still you choose to ignore it, which i think is rude. we even offered help there.

[zwzsg]

changes needed to LUPS in BA 7.19 to support dual states.

Cool! Now do the same for S44, GRTS, EvoRTS, KP, Cursed, CA!

[SirMaverick]

I spent two full days testing and improving this. Please give it a try before reverting.

git checkout master
git branch zerverbranch
git revert .... // revert in master

Done in way less than 2 days, nothing will be lost. Woot!

use a branch!

Bascally you draw a big line though the middle of your widget/gadget and [...]

To ease mod devs work on adopting/testing this, placing documentation near the source code would help much (in contrast to spread it over forum).

[smoth]

thread is gonig pretty off topic. Split perhaps?