Dev meeting minutes 2013-01-21

Dev meeting minutes 2013-01-21

Minutes of the meetings between Spring developers are archived here.
Post Reply
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Dev meeting minutes 2013-01-21

Post by zerver » 22 Jan 2013, 18:47

Present: <abma_irc> <[LCC]jK> <zerver>

=== Welcome ===
<zerver> hello
<abma_irc> hi!
<zerver> hi, anything to discuss?
<zerver> vclibs maybe

=== VClibs ===
<zerver> I wondering if github removed uploads due to abuse
<abma_irc> hmm, yep
<abma_irc> no clue why
<zerver> Maybe too much uploading and sharing of copyrighted content
<abma_irc> i suggested to make it a git repo, too
<abma_irc> the same as mingwlibs
<abma_irc> but i couldn't find a way to add a foreign user to the project
<zerver> you mean to give me permissions to push?
<abma_irc> yep
<abma_irc> aah
<abma_irc> found it
<zerver> May need to add vclibs8 and vclibs10, I am working with both versions
<abma_irc> ok
<zerver> okay I added myself to vclibs10
<abma_irc> ok..
<abma_irc> shall i add the current vclibs zip to the repos?
<zerver> hm, is it less ugly to add it in an unzipped form?
<abma_irc> i meant the contents of it, sorry :)
<abma_irc> yep, it is, as spring source is git, too
<zerver> vclibs8 I will add
<abma_irc> ok
<zerver> you just added vclibs9?
<abma_irc> yep
<abma_irc> i personally would have abadonned vclibs8
<abma_irc> to much to maintain
<abma_irc> also afaik it doesn't compile as well?!
<abma_irc> if i remember right i saw some "break vc8 compatibility" commit
<zerver> well, I was actually able to get it to compile again
<abma_irc> I'll continue in #meeting...
<zerver> I will PM you when I fixed OMP/MT, so we can have test release
<abma_irc> vclibs8 push failed?
<abma_irc> also, spring-headless doesn't compile ... logs/stdio
<abma_irc> not sure if other targets work, validation test only compiles headless
<zerver> Well, git gave me error 77 on push
<abma_irc> started linux-static-x32...
<abma_irc> weird :-/
<abma_irc> try again?
<abma_irc> do you use https or ssh?
<zerver> maybe I need to pull first :P
<zerver> https
<abma_irc> ah, ok
<abma_irc> maybe it was some lock because i pushed at the moment as well
<abma_irc> hm, repo is still empty, so it should work
<zerver> now better without https, just a permission denied
<abma_irc> ah, ok
<abma_irc> updated links here: are there other references?
<abma_irc> in wiki or source code
<abma_irc> i can't change forum :)
<zerver> not that I can remember
<abma_irc> ok, i've added vclibs9 & vclibs10 git repos as github doesn't support downloads any more
<abma_irc> so its the same as with mingwlibs
<abma_irc> disable wiki & tracker?!
<zerver> ?
<abma_irc> each repo on github can have its own wiki & tracker, i've disabled it as imo mantis / mediawiki on should be prefered
<abma_irc> not sure if it will be needed
<zerver> ok, sure
<abma_irc> zerver: shall i upload vclibs8 as well?
<abma_irc> 9&10 are done...
<abma_irc> uploading 8, too...
<zerver> I have a new version of 8
<abma_irc> oops
<abma_irc> then just overwrite it
<zerver> maybe I will get 500 conflicts now :P
<abma_irc> ok, aborted... lets see what happens
<abma_irc> [LCC]jK: anything to say about a release?
<abma_irc> i guess I'm done for now, i would like to make again a test release and create at the same point a release branch?!
<zerver> we should release from MTsim imo
<abma_irc> time between last test release was way to high, but fixing / configuring the gentoo buildbot took long, too
<[LCC]jK> buildbot stuff finished so far?
<abma_irc> i only could add a mingw64 build factory but that will fail to compile i guess ^^
<abma_irc> so, yep
<zerver> single threaded exe removed?
<abma_irc> no, the discussion about wasn't finished
<abma_irc> we got stuck at the state "omp & mt doesn't fit together"
<[LCC]jK> talked with Licho about new ftp structure?
<abma_irc> indirectly, yep. i should make a small release post but licho was faster...
<abma_irc> hmm, some important thing is maybe the stacktrace translator
<[LCC]jK> yep
<abma_irc> imo how the stacktraces look like should be adjusted
<[LCC]jK> never the less, stacktrace translator can be fixed later
<[LCC]jK> so test-release this weekend
<[LCC]jK> ZK also did some test games already
<abma_irc> yeah, test release is independent of stacktranslator
<abma_irc> currently stacktraces begin with some different string, this should be made always the same, then output of git describe, build config, platform (linux32/linux64/win32/...)
<abma_irc> i tested also a bit... so there shouldn't be horrible bugs left
<abma_irc> this reminds me to report one :D
<abma_irc> lasers seems to shoot out of range

VClibs 8..10 goes github repo

=== MTsim/MT/OMP ===
<abma_irc> zerver: sorry, i didn't want to ignore MTsim, but for me it looks like most points that where criticized are still unchanged
<abma_irc> from dev side imo it makes no sense to merge when all devs except one are against merge
<zerver> we can release from MTsim without merging
<abma_irc> uhm.. why?
<zerver> why release a slow version when we have a fast one?
<abma_irc> because we can't fix the bugs?
<abma_irc> its the worst thing we could do: release an unstable engine
<zerver> you are assuming it is unstable?
<abma_irc> yep, because many bug reports in 91.0 about crashes were spring-mt
<abma_irc> that's my opinion
<zerver> most were gfx driver bugs imo, but if u think so
<zerver> some examples?
<zerver> also MT != MTsim
<abma_irc> yes, true
<abma_irc> this comparison makes no sense
<zerver> can we do anything about the removal of single threaded exe to begin with?
<abma_irc> but then there are still all (or most) points untouched
<zerver> can we disable OMP in runtime?
<abma_irc> hm, afaik omp can be disabled with some env var
<abma_irc> disabled = forced to one thread
<zerver> yes
<[LCC]jK> it can be disabled at the very start
<abma_irc> afaik OMP_NUM_THREADS
<[LCC]jK> but once the threads are created it's not possible to stop them
<zerver> so spring has to restart itself with this flag? tbh OMP is not very flexible
<zerver> really badly designed...
<zerver> there should be and API to manually start the threads after exe has started, and it should default to 1 thread
<[LCC]jK> no, you can set threadnum w/o that envvar
<[LCC]jK> but you need to do so at the very start
<abma_irc> hm, omp_set_num_threads() ?!
<abma_irc> jk is the omp-boss :)
<abma_irc> my guess was because of some different setting that could only be set by env :-/
<zerver> I hope omp_set_num_threads really terminates the threads...
<zerver> and not makes them spinlock-idle at 100% cpu
<zerver> did anyone try it?
<[LCC]jK> what did I said?
<[LCC]jK> <[LCC]jK> it can be disabled ___at the very start___
<zerver> "but once the threads are created it's not possible to stop them
<zerver> "
<[LCC]jK> exactly
<[LCC]jK> so your question is already answered
<zerver> so why introduce something this shitty in spring?
<zerver> :)
<[LCC]jK> cause it's a standard
<[LCC]jK> a very shitty one (or better the gomp implementation sucks)
<zerver> okay so omp_set_num_threads has no effect?
<zerver> the threads will "spin"
<zerver> ?
<[LCC]jK> only at the very start
<zerver> main() { omp_set_num_threads(); } ?
<[LCC]jK> before the first omp section
<zerver> ah, but that may be okay
<zerver> because MT is toggled based on modinfo, pretty early
<[LCC]jK> currently it's not early enough
<zerver> do you know where is the first section?
<zerver> we could just remove that section...
<[LCC]jK> no
<[LCC]jK> it's need a reorder
<[LCC]jK> -'s
<zerver> okay, you want me to look at it?
<[LCC]jK> omp threads are initialized (= cpu affinity is set) in SpringApp::Initialize()
<zerver> okay, we have to move this section to after modinfo
<[LCC]jK> both have to be moved
<zerver> both?
<[LCC]jK> modinfo loading happens not explicit enough
<[LCC]jK> it needs a explicit place where such stuff is initialized
<zerver> you mean modinfo loading could happen in different places?
<[LCC]jK> just check where it is done in CGame ctor
<[LCC]jK> it happens between all shit
<[LCC]jK> it needs to be separate of such stuff at the very beginning
<[LCC]jK> so it's 100% sure that omp isn't used before
<zerver> yes, but the question is merely: are there any openmp sections before modinfo loading?
<zerver> oh
<zerver> couldn't we just add an NDEBUG test at each openmp section, to check that the affinity stuff has been completed?
<zerver> I will do that, unless you have better idea...
<[LCC]jK> for debugging it will help but it won't solve the problem
<abma_irc> so it is either omp or MT?
<zerver> if we can discover that someone has added a new openmp section "too early" in game loading, then there is not problem imo
<zerver> yes, we just have to to omp set num threads before any other calls to omp if I understand jK
<[LCC]jK> yup
<[LCC]jK> spring already frees one core from omp
<[LCC]jK> it just needs to know how many mt threads are spawned to free more cores
<zerver> the issue is OMP threads take too much CPU so MT will be starved of resources
<zerver> spin-wait is horrible, but I read that can luckily be configured... :)
<[LCC]jK> spinlock was disabled for win, abma disliked by workaround for a win limitation
<[LCC]jK> still a core can either run omp OR gml but not both cause of latency issues
<[LCC]jK> 10ms wakeup time is just too much
<zerver> yep
<[LCC]jK> -by +my
<zerver> so I will go and fix this... please no test release before ST is gone
<abma_irc> zerver: whats with the open points in the etherpad discussion?
<zerver> MTsim?
<zerver> I was hoping for a discussion with kloot, but he is never around
<abma_irc> zerver: you've to use etherpad / forum for that
<abma_irc> not sure if he is online under some different nick
<abma_irc> i know that sucks, but he is a good bug fixer
<abma_irc> and has a very indeepth engine knowledge it seems :)
<zerver> Indeed, only problem is he hates multithreading
<zerver> Most of his comments in etherpad are just generic anti-threading propaganda imo
<abma_irc> i wouldn't say so, qtpfs is multithreaded
<zerver> Is it? I saw him disable the threading multiple times because it had bugs...
<abma_irc> uh, not sure what it currently is
<[LCC]jK> it's enabled
<[LCC]jK> he just switched between custom threads and omp multiple times
<[LCC]jK> ps, I got a nice idea regarding mingw64, it's possible to build 32bit builds with it too
<[LCC]jK> it will allow us to use the new threading tools introduced in win7 and is in general superior to mingw32
<zerver> okay
<[LCC]jK> i686-w64-mingw32: Supports cross-compiling for 32-bit Windows (toolchain based on mingw64).
<abma_irc> uhh
<[LCC]jK> not important, still nice to have :)
<[LCC]jK> e.g. we could reduce thread latency then
<abma_irc> nobody will trust us then, that this is spring :P we should make a release first ;)
<zerver> you have to set QTPFS_ENABLE_THREADED_UPDATE
<zerver> so QTPFS threading depends on the build I think
<zerver> no, it is actually disabled, in pathdefines.hpp
<zerver> jK, do you have any other suggestions how to make MTsim branch "okay" from your perspective?
<[LCC]jK> recode whole pathfinder to be data-driven
<zerver> I would like the pathfinder to be reentrant so I could have multiple pathing threads
<zerver> Spawn multiple pathmanagers instead of having a singleton
<[LCC]jK> too complicated
<[LCC]jK> only clean & maintable solution is a data-driven design: you got got just 1 class/singleton where you ask for your path being processed, and time t later you ask for the result
<[LCC]jK> -got
<zerver> well this is what I already do in MTsim
<zerver> but there is a bottleneck, so I would like more pathing threads
<[LCC]jK> your code is not clean with all those que... functions and mutexes
<zerver> I agree, Que() are the worst mess
<zerver> but it also points out parts/objects in the code that may need modularization/redesign to make cleaner threading possible
<zerver> And Que() is inevitable for any code that must be executed linearly in order not to desync
<zerver> So either Que(), or change the underlying code so it can be executed non-linearly
<[LCC]jK> 3rd way: make pathfinder a blackbox it should be that doesn't rely on external stuff
<[LCC]jK> and so doesn't desync when outside stuff changes
<zerver> Indeed, completely self-sufficient
<[LCC]jK> also whole path related code needs to be done in one place
<[LCC]jK> -> either at start or end of gameframe it should collect the pathfinder results
<zerver> however the extra path thread is only one component of MTsim, the Que() mechanism is also required for the multiple Sim threads
<[LCC]jK> the whole code is too complicated
<[LCC]jK> you need to split stuff into logic units
<zerver> Do you have a specific example of what could be done?
<[LCC]jK> e.g. updatecollisions, updatemovetypes, collectpathfinderresults, update positions, etc.
<[LCC]jK> currently it's spaghetti code
<[LCC]jK> one thread handles pathfinder other one handles collisions etc.
<[LCC]jK> that just crap
<[LCC]jK> +'s
<[LCC]jK> for debugging you need explicit timespots where such stuff is handled for _all_ units
<[LCC]jK> so you can compare the results for all of them
<[LCC]jK> and don't need to think about what the other thread is doing atm, cause it should do the _same_
<zerver> But I believe this kind of splitting has no effect on the need for Que()
<[LCC]jK> it has
<[LCC]jK> que's wouldn't be needed when, you split updates by read & write
<[LCC]jK> -,
<[LCC]jK> so threads don't write to stuff others are reading etc.
<[LCC]jK> e.g. first collect all collisions (multithreaded), and then handle them (in a threadsafe way)
<zerver> Yeah, and which to handle? Those that are Que()'s....
<[LCC]jK> no, currently the sources of your ques are scattered across the whole code & time
<[LCC]jK> that's impossible to debug
<[LCC]jK> you need one place in code and one point in time when all threads process the same data -> job based
<[LCC]jK> and not let each unit spawn its own jobs
<[LCC]jK> instead it needs one job for all units
<zerver> Not sure I understand
<zerver> And read/write split design does not work in practice. Problem is that during the write phase read becomes inevitable
<zerver> E.g., is position A blocked or not? Two units cannot take the same spot
<zerver> So write must happen in a specific order, and read the data updated by previous writes
<[LCC]jK> ...
<[LCC]jK> <[LCC]jK> no, currently the sources of your ques are scattered across the whole code & time!!!!!!
<[LCC]jK> first collect all collisions in one frame and then handle then one by one!
<[LCC]jK> there don't need to be an order, only if there are multiple conflicting results e.g. unit collides with 2 or more units at once
<[LCC]jK> and that can be solved in the write pass w/o any reading
<[LCC]jK> that's the whole problem, current code (and the way you are still thinking) is in from unit point of view
<[LCC]jK> you need to go a stage higher and handle all units at once
<[LCC]jK> then all such threading issues will vanish, cause all threads run the same code to the same time
<zerver> when a unit is pushed, it reads the blockingmap to make sure it is not pushed onto blocked squares. read is inevitable...
<zerver> well, we continue next meeting
<abma_irc> when reading the discussion in #meeting, it sound for me that current mtsim can't be merged. can code be reused or is refactoring needed before doing that?
<zerver> well, the discussion is not finished
<zerver> if someone suggests a clean way of rewrite, maybe code can be reused
<zerver> but no one suggested a way of doing it... yet (none that actually work in real life)
<abma_irc> thats homework then :)
<abma_irc> sadly i don't know how to do, too, but there should be a way to clean up the spaghetti code
<abma_irc> imo we are now at some better point... before this meeting imo it wasn't clear what exactly is bad and how it can be solved
<zerver> indeed, no one happier than me if magic solution is discovered
<abma_irc> thanks guys & good night!
<zerver> gn!

OMP needs to be disabled for MT (zerver assigned to do it)
QTPFS threading seems to be currently disabled
Not much consensus about MTsim yet, except that the Que() mechanism is ugly because it is scattered and does a little of this-and-that
Suggestions on how to improve MTsim are most welcome
0 x

User avatar
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Dev meeting minutes 2013-01-21

Post by Pxtl » 22 Jan 2013, 19:09

If I'm not mistaken, shouldn't it be called Queue?
0 x

Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2013-01-21

Post by zerver » 22 Jan 2013, 19:11

Pxtl wrote:If I'm not mistaken, shouldn't it be called Queue?
Yes, just laziness. Queueueue!

With regard to splitting read/write, this bank account example illustrates why it does not work in real life:

Read: First collect all the account transactions that people want to make, collect&handout cash
Write: Register the transactions in the bank's computer
Cleanup?: Send the police after those who have a negative account balance

It is the same with the blockingmap in spring. Just like the bank account it is a limited resource, and "cleanup" during or after the write phase cannot be performed.

Two units want to move onto a square, and it appears to be free. Yay!
However, delaying the write causes multiple problems. Not only do you not know how to resolve the conflict in a nice way, but the units that in the end are allowed to move will be blocking both their old square and the new one until the write is completed

That said, there are SOME cases where splitting of read/write can work fine.
0 x

Spring Developer
Posts: 3540
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2013-01-21

Post by abma » 22 Jan 2013, 19:26

i also would suggest to make a release soon without MTsim merged as its not ready for merge. (still needs discussion / cleanup)

last release was on 03. September 2012, so its really time for first making a test-release + create a release branch and then if nothing major is found release 92.0
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14571
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2013-01-21

Post by Forboding Angel » 22 Jan 2013, 22:52

This release will have static linux build, yes?
0 x

Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2013-01-21

Post by zerver » 22 Jan 2013, 23:06

abma wrote:i also would suggest to make a release soon without MTsim
But not a release with single threaded build still remaining.

Assuming that this compiles and runs (buildbot is down), go ahead: ... e65ca35006
0 x

Spring Developer
Posts: 1864
Joined: 08 Oct 2006, 16:58

Re: Dev meeting minutes 2013-01-21

Post by Kloot » 22 Jan 2013, 23:13

zerver wrote:only problem is he hates multithreading
You are either very dense or very purposely misrepresenting me if you *still* do not (or do not want to) understand my position on multithreading synced code in this engine.
0 x

Post Reply

Return to “Meeting Minutes”