Dev meeting minutes 2012-12-3

Dev meeting minutes 2012-12-3

Minutes of the meetings between Spring developers are archived here.
Post Reply
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Dev meeting minutes 2012-12-3

Post by abma »

Date: 3-12-2012
Present: jK, abma

maybe some words:
this is just a chatlog slightly modified for better readability. i hope its interesting.



status of the new win32 buildslave
<abma> [LCC]jK: hm, i've applied the patch... i still don't get more than 1 core at 100%
<abma> ideas?
<abma> the omp hello world seems to work...
<jK> abma_irc, there will never be more than one 100% core
<jK> the omp threads are helpers
<jK> you are happy when they eat >30%
<jK> also I limited omp to leave 1 core free for OS & drivers
<jK> (except on dualcores)
<jK> windows taskmanager sucks such much ...
<jK> with htop you have a much better view of such things
<abma> this means, with 4 cores you get 25% cpu load at max?
<jK> your last commit broke that btw
<jK> now it won't use omp on dualcores at all
<jK> with quadcore you should get around 200-200%
<abma> i wanted to revert after the compile because the info in general is useless ..meh, damnit
<jK> 200-300%
<jK> np
<abma> qtpfs only or both pathfinders?
<jK> qtpfs has a omp flag too, but uses boost::threads by default (kloot doesn't trust external code)
<abma> i ask this stupid because on windows i don't get more cpu load that 100% of one core
<jK> you should have one 100% core and 2 30-50% ones
<abma> or 25 at each of the 4 cores
<abma> ok, i don't have/had this on windows...
<jK> doesn't windows show cpu usage in >100% in case of threading?
<abma> yep, it should
<jK> and what does it show?
<abma> 100% at max...
<abma> its like its running as singlethreaded...
<jK> and omp hello world works?
<abma> omp hello world worked on the buildslave with wine
<abma> didn't try on windows directly
<jK> #pragma omp parallel { printf("hello world"); }
<abma> yep, thats my example
<abma> http://abma.de/tmp/test.exe
<abma> hm, pthreadGC2.dll has to be taken from spring_mini...
<abma> <-reboot
<abma> ok, hello world works on a "real" windows 7, too...
<abma> [f=0000000] Using 3 OMP threads
<abma> hmm
<abma> did i apply the wrong patch or something like that? :D
<jK> testign in my virtualbox
<abma> is moving arround 1000 fleas a good testcase?
<abma> i come to the conclusion my test maybe sucks :D
<abma> aah, now i get about 30% or so
<abma> with cheat + give all a few times
<abma> and sorry, i said it wrong i guess. the windows task-manager shows cpu usage at total for all cores is 100%
<abma> 25% is one core at 100% with 4 cores...
<jK> :)
<abma> so i guess gamedevs have to test from now on
<abma> seems to work in general :-)
<jK> <_< >_>
<jK> vbox is soo slow
<jK> perhaps I should switch to vmware & winxp
<abma> hmm, vbox has similar speed than vmware
<jK> has it?
<jK> in case of 3d accel. I saw some benchmarks that were promising, but duno about mem-alloc & disk-io
<abma> it mostly depends on if you have vmx/sm
<abma> aah
<abma> yeah, ok. i don't know anything about 3d virtualized
<abma> only that you need an iommu to passthrough a gpu :-)
<jK> maybe it's also a 32bit problem
<jK> I know some vm-accel stuff is only available in 64bit
<abma> yeah... possible
<abma> what i dislike on vmware... its bloat
<jK> I wished there would be a runtime way to upgrade gentoo :<
<abma> you install like 10 services and you've no clue why
<jK> dislike to reinstall everything
<jK> yeah, vmware is like "erm erm erm what should I do know?"
<abma> hmm, its not complicate to use, its just such a big fat thing :)
<jK> there is a libvirt that should simplify such things, but somehow it doesn't work for me wit vbox
<jK> crash ...
<jK> waiyed 10misn to spring start and then it crashed ...
<jK> *waited
<abma> hm... my reboot was faster i think :)
<jK> yeah
<jK> tried once to compile spring in it and it took >2h for just the spring main binary
<abma> ouch
<abma> maybe really because of 32 bit / no hardware virtualization support
<abma> cat /proc/cpuinfo |grep svm
<jK> there is hw-support & enabled, but I read once that some specific stuff is limited to 64bit
<abma> ah, ok
<abma> no clue. but 64 bit should be faster as it can use more / bigger registers

conclusion: we have a working win32 omp build of spring! (only development branch currently) :-)


split off buildbot stuff to an extra repo
<abma> [LCC]jK: what do you think to split of the buildbot stuff to an extra git repo?
<jK> but that's the only speedup by 64bit ;)
<jK> advantage?
<abma> yep, i can't say switching to a 64 bit os/cpu made everything faster
<jK> now there is even 32bit in 64bit os
<abma> advantage would be: fewer try&error commits in spring
<jK> to reduce size if pointers and so to optimize cache hit rate
<abma> old versions of spring could be rebuilt
<abma> uhm
<jK> <abma_irc> old versions of spring could be rebuilt > that's an advantage
<abma> yeah, sure
<abma> i have no idea if the old versions would compile with the new setup :D
<abma> but as "cmake . && make install" should work on all versions...
<jK> hmmm no
<abma> it only depends on libs
<jK> cmake's break old compiles
<abma> + headers
<jK> buildbot has less influence on buildprocess
<jK> it might make buildslave git setup more complex
<abma> hmm
<jK> atm it just pulls a single repo
<abma> yep
<jK> duno what needs to be changed to solve that
<abma> hmm, ok only advantage would be fewer commits
<abma> but thats no reason i guess

conclusion: splitting buildbot stuff to an external repo seems to make no sense currently as it just makes things more complicated and other stuff is currently more important



refactor directory layout to allow builds for multiple architectures
<jK> won;t stop you to do so, I see the time better spend in more gentoo compiled mingwlibs
<abma>
<jK> e.g. I am able to able to compile freetype but didn't spend the time yet to move into a buildjob
<abma> http://springrts.com/mantis/view.php?id=3349
<jK> -to able
<abma> yeah, i have / had similar ideas i guess
<abma> compile all mingwlibs from scratch for a 64 bit build
<jK> some libraries are very complicated, but even when compile 60% of the libs it should make a 64bit build possible
<abma> not sure if we should try to compile from scratch or just collect the libs
<abma> doing ourself will take many time
<jK> in case of freetype & boost you don't have any other chance
<abma> ok..
<jK> duno about minizip
<jK> I assume there we need to compile it ourself too
<abma> hm, we compile it ourself already :)
<jK> 7zip has 64bit binaries
<abma> its more: what do we need...
<abma> boost
<jK> SDL ... they better have a 64bit binary
<abma> hmm, resort the mingwlibs then? create a x86 and x64 folder and move bin / lib / dll into it?
<abma> or create an extra repo?
<jK> dll64/
<jK> headers should be the same afaik
<abma> this would force us to use the same versions for both of it.. not sure whats better.
<abma> but dll64 / lib64 sounds reasonable
<abma> i guess fewer code has to be changed with this
<jK> I would branch it only when needed
<jK> stuff as this can always been done later
<abma> yep
<abma> hm
<abma> maybe we should just focus a bit more on a release?
<abma> the todo-list is like infinite :)

todo for release: merge spring-mt
<jK> spring-mt merge is left
<jK> and a backward-compability break I don't know if I will fix it
<abma> zerver disappeared and i heard nothing from you :)
<abma> are you fine with a merge?
<abma> last time it was to late
<jK> I wished zerver would clean it up before merge :<
<jK> his preprocessor is the devil
<jK> *code
<jK> *his preprocessor code is the devil
<abma> i know what you meant :)
<abma> thats already on the eterpad page
<jK> ever tried to look up what LUA_CALL_IN_CHECK does?
<abma> no...
<abma> but i'll do no for some time
<abma> +w
<jK> you will give up after the first #define ;)
<abma> yeah, zerver always loved #ifdefs / defines
<jK> never use a #define when it can been done in a function
<abma> also you get only many untested code with ifdefs, too
<jK> and a lot branches in them
<abma> hm, at least there is a single comment about lua_call_in_check
<jK> with a damn lot of combinations of unreadable code
<abma> // hack to add some degree of thread safety to LUA
<jK> yeah ... a hack ...
<jK> cause lua laready got an inbuild system for thread safety
<jK> -> http://lua-users.org/wiki/ThreadsTutorial
<jK> lua_lock & lua_unlock
<abma> yep, i already read about that some time ago...
<jK> zerver didn't ...
<jK> he coded his own instead, just making everything more complicated than it needs to be
<jK> I assume minimum 40% of the #define can be removed
<jK> also the definition flags can be reduced a lot
<jK> e.g. there is no need to have an extra flag GML_ENABLE_SIM
<jK> it just makes stuff complicated
<jK> KISS is the way
<abma> yep
<abma> this is why i annoyed him a bit to the merge...
<abma> currently its like he created an own engine
<abma> many different code paths
<abma> aweful to debug / to understand
<jK> yup and then he even started MTSim
<abma> pew, i'm not sure what to do
<abma> wait a bit more and then decide i guess
<abma> i'll pm zerver, whats up with him
<abma> hm, last visit 30.11 in forum...
<abma> pmed him
<abma> as we need young blood focusing on making the code cleaner / simpler should be important :-/

conclusion: the mt code is really hard to understand, it should be really cleaned up before the merge with spring mt to make it maintainable for others, too (currently only zerver understands the code it seems...) also it should be changed to use lua_lock/lua_unlock.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes 2012-12-3

Post by FLOZi »

Nice to see at least some discussion is still going on.

wrt new blood; cleanrock a possibility?
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2012-12-3

Post by abma »

oops already done! cleanrock already has git commit access and made some bugfixes :)
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes 2012-12-3

Post by smoth »

FLOZi wrote:cleanrock
he needs some feedback on repairing part of the unitcrashing code for aircraft.
<cleanrock> question to game makers: does it raelly make sense to be able to call Spring.SetUnitCrashing(unitID, false) ...
<cleanrock> i.e. make a crashing aircraft flying again
...
<cleanrock> if u supply false unit will go to FLYING if its CRASHING, but spring will assert/crash now
Post Reply

Return to “Meeting Minutes”