Present: hoijui, jk, Tobi, zerver
_Agenda_____________________________________________________________________
- Welcome
- Release plan (unitsync fix)
- communication enhancement with mod-devs
- dual/single lua states - mod option?
- git rules
- Next meeting
- Anything else? (WVTTK)
_Topics_____________________________________________________________________
Welcome
hoijui: hello everyone!
hoijui: :D
zerver: hi
Tobi: hello :)
hoijui: to the agenda..
hoijui: do we need all the stuff thats on there?
hoijui: especially the old one
hoijui: unitsync improvement?
hoijui: abma told me he will be here but afk
hoijui: so.. i guess we should leave that out
Tobi: ok
Release plan (unitsync fix)
hoijui: jk, how is your fix?
jk: working on it right now
jk: fixed it mostly already
hoijui: ahh cool
jk: I assume to finish it today
hoijui: mm
hoijui: nice
hoijui: goo so.. if that works out, .. we should do a 0.82.6 i guess
zerver: indeed
zerver: too many people crashing because of this direct control thing
hoijui: with the snake move fix, this one and a real fix for the FPS crash
hoijui: .yeah
hoijui: lets leave that for tomorow evening then
zerver: yeah, should i send u list of commits to include?
hoijui: jk, and zerver telling me what they want in, and ill do the release stuff including a bit of testing and the post
hoijui: yeah please
zerver: ok
hoijui:
main points:
- jk nearly fixed the unitsync issue (aka Satiriks bug)
- new release (0.82.6) will come these days
communication enhancement with mod-devs
hoijui: thats the questions in the etherpad
hoijui: looks like jk and me are missing something.. and .. well kloot who is not in there at all :D
jk: I need a week to finish me examples
hoijui: ok :D
hoijui: me too then..
hoijui: i will write a PM to kloot.. i guess he was never informed about it?
Tobi: pretty sure he was, in the meeting a few weeks ago
hoijui: mm ok
hoijui: will remind him again then
hoijui: or should we live with what we have?
hoijui: maybe more/better ideas will come up when it is running
Tobi: yeah
jk: answering those example questions will be the most difficult ^^
hoijui: :D
zerver: yeah, im pretty unsure if there are answers
zerver: "sorry, u can't"
main points:
- let's see again in a week
improve unitsync
hoijui: this is what abma is workign on, and he is AFK, os we skip this
dual/single lua states - mod option?
hoijui: lets get ready to RUMBLE!!
zerver: yeah, it looks like we are finally getting somewhere now that jK put his suggestion on paper
zerver: we are basically fighting over nothing
zerver: jK's and my suggestion are very similar, he wanted to use more batching, which is perfectly OK
zerver: more work, but less chance of broken widgets
hoijui: mm ok
jk: the thing is as said your way doesn't solve anything
jk: I understand the problem very well, but I also know how current Lua works in Spring
zerver: it solves MT slowdown, that for sure
jk: and your changes show, that you have totally wrong impressions
jk: no it doesn't solve the slowdown
zerver: come on, please stop this...
jk: you aren't listening, fine ...
jk: then move it to a branch please
zerver: explaing why it does not solve the slowdown, even though i confirmed it does
jk: confirmed how?
zerver: by reading the cpu load under identical conditions
jk: you broke 100% of the lua, the lua does nothing in your code, that's why it is faster
zerver: i broke lua, but it is faster because of less locking
jk: less locking?
jk: you didn't removed the mutexes
jk: it is still locking the same amount of time
zerver: i did, with macros redefinitions
zerver: sim thread has its own lock, and draw thread another lock
zerver: so they are not blocking each other
zerver: luadrawmutex, luasimmutex
Tobi: zerver: random question: unsynced-draw LuaUI has no access to GetUnitHealth etc. right?
jk: it has
zerver: ok, i actually have no idea
jk: but the simthread is writting to it at the same time -> boom
jk: your knowledge of the lua handles is very limited
jk: so e.g. the unsynced LuaRules
Tobi: if it has, locks are still needed and too much responsibility will be at the widget writer (i.e. if he accidentally uses any LuaSyncedRead method it can cause random crashes indeed)
Tobi: s/and/or/
zerver: unit deletions cannot happen during draw call-ins, there are locks that prevent it
Tobi: if it hasn't, then the dual state solution as it is now (as I understand) is moving responsibility of buffering/queueing data from C++ to Lua
zerver: well, the lua state split really does not affect concurrenty in any other way than that the thread will no longer fight for the single lua handle
zerver: *concurrency
jk: for callouts as GetUnitHealth I would propose mutex with a lifetime, so all those callout share 1 mutex, but just reset it's lifetime
Tobi: so then there is only a chance for reading a half written value (I've never seen that in practice) or an inconsistent set of values
jk: this way the overhead by mutex creation is limited to a minimum
zerver: Tobi: yeah, MT reads plenty of incomplete values
zerver: this is thy signaling nans have to be disabled
Tobi: ok, so it does happen
jk: and still it wouldn't lock the other threads from running while lua does it's work
zerver: basically, we should discuss the lua split only
Tobi: zerver: sim thread never needs to touch LuaUI
jk: zerver, it has to do with the lua split!
Tobi: just LuaUI needs to access sim data
jk: as your lua split is bugged!
jk: and we discuss solutions
jk: e.g. a 2nd bug: http://github.com/spring/spring/blob/f0 ... d.cpp#L303
Tobi: I think splitting LuaUI is putting responsibility at the wrong level (i.e. at the widget writer)
jk: this function initialize the basic Spring unsynced LuaRules enviroment
Tobi: while the engine could quite easily make sim call LuaUI in async way
jk: note the LightCopyTable in line 304?
jk: you know what it does?
jk: it _copies_ lua objects from the synced enviroment (in the same LuaState as the unsynced one!) to the unsynced enviroment
jk: obviously this doesn't work anymore after your split
jk: and there are multiple of those issues
jk: also you don't need to touch the LuaHandle.cpp at all
jk: you just need to split the LuaState in LuaHandleSynced
Tobi: and even that isn't needed to decouple LuaUI from the sim thread
jk: still it would be a huge parallization increase when doing so
jk: you could even run multiple unsynced LuaStates at the same time (except the render callins)
zerver: my split means two copies of everything essentially
jk: e.g. so you could run UnitCreated in LuaRules(unsynced) & LuaUI at the same
Tobi: yeah, but `just' for gadgets, and I recall usually LuaUI uses the most CPU?
zerver: so I don't understand why the stuff you pointed out would not work
zerver: i have two luaRules (complete), and two luaGaia
jk: yeah, adding a event queue to LuaUI will be enough and fix the performance problem
zerver: they both work!
jk: zerver, you aren't listening
zerver: and im doing the event queue as we speak...
jk: I am really pissed off, I explain things over and over .. and you don't listen and just say "it works period"
Tobi: zerver: the 2 luarules, how do they relate to synced/unsynced code?
zerver: both have synced and unsynced, they are complete
zerver: only sim thread invokes one and draw thread the other
Tobi: ugh
Tobi: design wise that becomes very ugly imo
zerver: so communication is severed ...
Tobi: so from modder point of view there would be 4 luarules :/
Tobi: draw-synced draw-unsynced sim-synced and sim-unsynced
Tobi: with half of the call-ins randomly not working in one or the other
jk: zerver, obviously synced LuaRules can't render ...
zerver: no, because one half of each is "dead" :)
jk: and obviously the current unsynced LuaRules implementations doesn't get any synced events
zerver: im making batching for that
zerver: it goes directly into synced, then batches it into unsynced
Tobi: [LCC]jk: the last thing isn't that obvious, as user questions indicate in my experience
Tobi: [LCC]jk: it's just a technical limitation because of lack of trepan-style state split
jk: I know that it isn't obvious to the user
jk: and I know it is a very bad limitation
Tobi: ok
jk: and I want to really fix it
zerver: jK, but you also suggested state split for LuaSyncedHandle, right?
jk: yeah
jk: but in a toally different way
zerver: so basically, you have nothing against gadgets needing some re-working
jk: gadgets wouldn't need any rewrite!
Tobi: I think the issue is that state *split* is what is desired, and not state duplication
zerver: if you have two states, they *will* need a slight fix
jk: no
Tobi: the trepan-style state split wouldn't need any changes to Lua code afaik
zerver: i made this topic on the agenda to discuss whether the state split should be a mod option
zerver: this way, lazy modders can use their old code too
jk: it shouldn't be in spring at all in the current form
Tobi: it's separated well enough atm to be able to do the change transparantly to the Lua code.. (unsynced Lua never has direct access to synced Lua object)
hoijui: so in short..
Tobi: don't make it an option, that will mean double amount of code paths on which bugs can appear
hoijui: lets get zervers changes into a branch?
hoijui: and jk does what he wants to do in an other branch
zerver: mod option is real easy to implement
jk: my change can be in master even, because it doesn't break anything
zerver: if so, it will not fix the MT performance issue
jk: the performance issue will be fixed with an event queue for LuaUI!
hoijui: i would say.. as zerver still does not believe you can do it better, maybe to it in a branch.. and when done ..
hoijui: zerver can verify it..
zerver: event queue is good
zerver: but there are gadgets too
jk: gadgets use <10% cpu time
jk: and they can be parallized already
hoijui: so.. both of you work in branches, and nobody will make changes in master Lua stuff
hoijui: so no problems
Tobi: I think that is best for now
zerver: kk, but both of us doing the event queue is kind of bad
jk: doing the event queue is a bit more work
jk: (needs more thinking)
jk: work can be shared there imo
zerver: and i dont understand how LuaHandleSynced can be "parellelized already" when it has a single state
zerver: let me do the queue, i already started
jk: yeah, I meant it can be parallelize after the state split
jk: and yeah, do the queue
zerver: ya, and i have split it :)
Tobi: *trepan style state split, I assume
jk: yup
hoijui: zerver, will you revert the 3 or 4 commits in master then, or should i do it?
zerver: i can do it, but it work as i see it so no need really
hoijui: i though we just decided that we do it?
zerver: sure
hoijui: as for jks version, it is not needed
hoijui: ok
Tobi: putting it into a branch needs a little bit of thought too though
hoijui: hm?
Tobi: I think branching & then reverting in master will give huge conflicts on merge?
hoijui: yeah.. maybe better to revert, then branch, and re-revert
Tobi: so maybe revert, branch, cherry-pick to branch might work better?
hoijui: yeah
zerver: can u explain the difference between Trepan split and mine?
jk: your's is done in LuaHandle
jk: trepan wanted to do it in LuaHandleSynced
Tobi: trepan intended to run LuaRules unsynced in one state, and LuaRules synced in another state, instead of both in the same state
zerver: but now tweaked so unsynced luahandles use a single state...
jk: also a lot enviroment creation functions need to be adjusted in LuaHandleSynced
Tobi: without the other half being present in each other
jk: zerver, you created 4 States
jk: trepan wanted just 2 and still use all the old interaction functions
zerver: yeah, but the other half present, does it hurt really, except eating some memory
Tobi: and in a way to simplify the code, i.e. get functions from global table in both states, instead of: get unsynced functions from registry and get synced functions from global table & hack around with making registry used as global table in unsynced
Tobi: I doubt that was in any way clear =)
zerver: :)
Tobi: either way, it would make things more consistent on the C++ side, without any changes needed on the Lua side
jk: I don't think zerver has enough lua knowledge to explain it fully to him
zerver: If trepans solution really has parallel execution in gadgets, how can it be compatible with current code?
jk: you need to know how Lua handles `enviroment` and tables etc.
jk: because gadgets are already splitted in 2 sub-luacodes
jk: in real each gadgets is created twice
jk: as synced gadgets and an unsynced gadget
jk: you see a "if (gadgetHandler:IsSyncedCode()) then" in all gadgets
jk: it is used to detect which part is executed right now
zerver: yeah, i know, but still only one luaState
zerver: so parallel execution --> crash
jk: but you could just give unsynced it's own LuaState
Tobi: not after split
jk: *its
Tobi: after split unsynced half would run in a different state from synced half
zerver: but then it cannot share data via SYNCED anymore
Tobi: why not? `just' needs some buffering
jk: yeah, that needs work
jk: but it is solvable
zerver: i doubt that
jk: you will see
zerver: i thought separate lua handles are completely isolated from the outside world
jk: you still need tunnels between them
zerver: and if the are not, how come concurrent access to shared data does not crash?
zerver: tunnels? ok
jk: e.g. even LuaRules can call LuaUI code via Script.LuaUI.MyCustomGlobalLuaUIFunction()
jk: (unsynced LuaRules)
jk: so those special cases need extra locking
jk: or they are added to the event queue
Tobi: probably depends on whether the LuaUI function can return data to unsynced LuaRules again
jk: no, it can't
Tobi: ok, that's good then
jk: first, I was annoyed it can't, but now I am happy about it :)
zerver: so how would this make it possible to share data via SYNCED?
zerver: where does the locking take place?
jk: no, locking in there
jk: in needs buffering
jk: *it
jk: instead of sharing the lua_objects between synced & unsynced, it needs to copy the data from synced to unsynced
zerver: i think this is fail. what data do we copy, and when?
jk: this should be done each renderframe and on SendToUnsynced
zerver: how can we make sure to copy the data before the reader needs it?
Tobi: SendToUnsynced could be buffered too
jk: "what data do we copy" the same as what it in SYNCED right now
jk: *is
Tobi: copy all data
Tobi: it's a shame though that unsynced SYNCED table refers to synced _G
zerver: so we copy all of it, every time
zerver: FAIL
jk: copy all >valid< data in _G
jk: e.g. functions aren't valid
Tobi: yeah, only primitives and tables, but you still need to loop through everything
zerver: sorry, but i think we should skip this data sharing and use a mod option instead
jk: it already loops through everything
zerver: what does?
Tobi: would have been nicer if there was a separate table in synced Lua (e.g. `EXPORTED') that was made visible in unsynced as SYNCED
zerver: i think it is ok to break _G/SYNCED communication for gadgets if we use a mod option for it
Tobi: [LCC]jk: I thought SYNCED was a magical table that fetched data on demand?
jk: that could be done via an modoptions (or any located anywhere else) if you want
jk: exporting data just in _G.EXPORT
zerver: i don't believe in that, it complicates matters too much
Tobi: it's pretty simple actually
zerver: but how often to copy the data, and does this copying need a lock?
Tobi: probably once reach sim frame is sufficient
zerver: triple buffering :)
Tobi: s/reach/each/
jk: sim frame ?
jk: you mean renderframe
Tobi: no, sim frame
Tobi: as sim things don't change between render frames, unless there has been a sim frame
zerver: once a sim frame --> big chance unsynced tries to read it before it is available
jk: for the synced Lua it doesn't matter if the data for SYNCED was used or not
Tobi: zerver: then it would read data from previous frame, pretty sure in 95% of the gadgets that use it that is no problem
jk: k each renderframe it needs to check if the sim frame increased and then to copy the data
Tobi: it just needs to be guaranteed that SendToUnsynced calls don't arrive in unsynced before the data in SYNCED has arrived -> buffer those too
jk: yup
zerver: they are buffered already
zerver: my commit contains that
Tobi: then each render frame, if there has been a sim frame since the past render frame, copy _G to SYNCED and after that go through SendToUnsynced buffer
zerver: im a bit worried copying may take a long time with tables and stuff
Tobi: it will be pretty fast
zerver: k
Tobi: Lua makes tables all the time
Tobi: and in case -after measurement- it appears too slow anyway then we can then think of a faster `data tunnel', that could optionally be used by a mod if they want to really optimise for max speed
zerver: i think my commit does everything we suggested so far, with the exception of the event queues and the _G/SYNCED communication
zerver: but i assume you want me to revert anyway?
jk: you didn't do so exactly
jk: it might sound from the todo items
jk: but the ways/implementations are different
Tobi: yes, it does much more, that isn't needed (splitting LuaUI etc.)
zerver: not anymore
zerver: i merged luaui again
Tobi: oh ok
zerver: and the split has to be in luahandle, because luahandlesynced uses a lot of stuff from there
zerver: all "synced" calls (UnitCreated etc) is declared in LuaHandle
jk: you need to be more creative
jk: there are solutions for those things
zerver: any attempt to make a nice split in LuaHandleSynced will be horror from a coding perspective
zerver: cannot use macros and stuff the way I have done now
jk: it won't be a 10 lines macro ...
zerver: so, conclusions?
zerver: i'm making the event queue...
jk: fine :)
jk: I will try to split LuaHandleSynced (2-3 weeks project)
hoijui: first, do the revert/move to branch
jk: esp. because my mulitcore CPU is coming this week, before that I can't test the locking
hoijui: yeah :D cool
jk: Phenom II 555BE + GTX460 :D
zerver: jK, you should test my code first
jk: I know it is broken
zerver: how?
jk: I know the code very well
zerver: you did not tell me how its broken in any way that i could understand :)
hoijui: the 4 vs 2 states thing?
jk: nah, the unsynced LuaRules enviroment creation + SYNCED is broken etc.
zerver: not convinced, 2 dead states do not break anything except the _G/SYNCED communication
jk: the `Script` userdata object is broken
zerver: where and why?
jk: Script.LuaUI?
jk: Script.LuaGaia, Script.LuaRules
zerver: and how did I break that?
jk: those are tunnels between the LuaStates
zerver: ok
jk: and now with multiple LuaStates, they may tunnel between the wrong ones
zerver: still a minor issue maybe? really worth it to throw away my solution completely?
Tobi: 2 dead states are bad from maintenance/design POV, will be even harder to understand what the code is doing when half of the runtime stuff it makes are dead bits
zerver: i agree on that
Tobi: clean design that makes as much objects as there conceptually are would be preferred
hoijui: next?
zerver: wait
zerver: Can Script.LuaUI read from the LuaUI state?
jk: not really
jk: but you can check if there are global functions available
zerver: so that would need a lock?
jk: or part of the event queue
jk: e.g. you can do in LuaUI: _.FOO = MyFooFunc and in LuaRules(unsynced): if (Script.LuaUI.FOO) then Script.LuaUI.FOO("bar") end
jk: but it doesn't allow return values, nor can it be used to share any other data than functions
zerver: okay, but it somehow uses the lua state from luaUI
Tobi: could probably be cached? (take lock only when it's never been requested before)
zerver: locks are dangerous, might deadlock
Tobi: yeah, but without it you most probably crash
zerver: this is one of the reasons I still prefer my "broken" solution in a way
zerver: it is simple, but it RUNS
jk: yeah, when calling Script.LuaUI in LuaRules(unsynced) then you need to wait until the LuaUI state is available (or you put the event on the queue - maybe only in none render-callins)
jk: it doesn't run ...
zerver: it is incompatible, but runs
zerver: so my vote is still to sever the _G/SYNCED communication for gadgets and use a mod option
zerver: next...
jk: zerver, you aren't a lua programmer
zerver: i fixed your LUPS...
Tobi: point is that when you will make it compatible you will still see the issues we are mentioning now
jk: I don't think you have any rights to request something like that, because you don't have any idea how important it is
zerver: it didnt seem very important in you LUPS, thats for sure
zerver: it is fairly easy to create the data you need on the respecive sides (synced/unsynced) without any other communication than SendToUnsynced
zerver: synced/unsynced bandwidth requirement is super low, if the code is properly written
zerver: sorry this discussion is getting long, im just worried we are getting nowhere because of to high backwards compatibility requirements
zerver: next...
main points:
- some disagrement removed, some still present
- zerver will move his changes to a branch (done)
- jk will implement his idea (1st stage, using a branch too)
- colaboration on job queues (jk and zerver)
git rules
hoijui: abma and me started an etherpad here:
hoijui: <stripped>
hoijui: we had some somewhere else already, but that got lost
hoijui: but what i want to discuss here mainly..
hoijui: when to use branches
hoijui: i mean.. this thing now..
hoijui: is kind of unacceptable to me
hoijui: using branches more makes live easier for others, and not harder for you (the branch owner) if people behave
hoijui: i mean.. 3 of us said it should be a branch, and you still put it into master again.. that is just bad.. creates anger for no benefit
hoijui: so.. we should try to do more branching.. if you are unsure, ask others, or just use a branch anyway
zerver: only because i thought i corrected the thing that annoyed you in the first place
hoijui: well... you really overread 70% of what i said then
zerver: single thread works like before, but that's not enough it seems.
hoijui: thing was, that we did not agree on the very principle you use to do it
hoijui: well.. just for the future.. use more branches
Tobi: compiling & running is not the only thing that matters, also design & implementation quality
zerver: im sorry, the explanation is probably that since i wrote 99% of MT, i think i have the right to break it :)
hoijui: i will be reverting stuff more aggressively from now on, when in such situations
Tobi: ok
hoijui: also... when someone has a branch somewhere, do not change lots of stuff in the are of the engine that branch is touching
hoijui: if you need to do that, use a branch
Tobi: :)
hoijui: small fixes and stuff is ok of course
hoijui: i think.. thats all i wanted to say
main points:
- new etherpad for git rules for hte spring repo
- use branches!
- actions that cause problems for others will be reverted more aggressively
Next meeting
hoijui: same is ok for me
jk: me too
Tobi: next week is fine, although I'd prefer a different time in the week in the future, but we can discuss that next week I guess
Tobi: (gtg now in a few mins)
jk: hope Kloot will be back soon
hoijui: yeah :D
hoijui: is he gone somewhere?
jk: (his new branch is promissing)
hoijui: ah
hoijui: mmm
Anything else? (WVTTK)
hoijui: i will do the minutes
Tobi: thanks
hoijui: btw, someone told me there are no debug packages in ubuntu, is that true?
Tobi: I thought they had, but I'm not sure, since I don't use it anymore
hoijui: ahh ok
hoijui: will ask others then.. or check online
Tobi: anyway I'm off to dinner, laters
hoijui: bye!