Post closed tickets in your report. | Note: This channel is for our weekly status meetings (Tuesdays at 19:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 20 March 2012.
01:58 jashwanth joined 05:45 eternaleye joined 05:54 eternaleye joined 05:55 eternaleye joined 07:12 jashwanth joined 08:25 lucian joined 14:26 jashwanth joined 17:11 lucian joined 17:57 alvis joined 18:51 benabik joined 19:13 contingencyplan joined 19:14 dukeleto joined
dukeleto soon? 19:42
benabik Supposedly 12 minutes ago.
cotto said he might be in a meeting.
dukeleto Amazingly, I was first to #ps today! 19:44
dukeleto has been hacking on M0 a bit and released 4.2.0. parrot.github.com still needs updating 19:45
19:50 NotFound joined
NotFound Late hello 19:50
dukeleto NotFound: #ps is a bit late-ish today
NotFound This weekend we switched to dst, I'm a bit disoriented.
nine I somehow thought it was at 20:00 UTC not 19:30
19:51 whiteknight joined
dukeleto whiteknight: are we late or early? 19:52
whiteknight i have no idea
NotFound We're here, then is the rigth time.
nine So dukeleto has been hacking on M0 a bit and released 4.2.0. Thanks for that! 19:53
DONE: * got threads to run reliably * finished chameneos.pir threading example implementation * achieved a performance increase of an order of magnitude for chameneos.pir compared to the initial version 19:56
PLAN: * slowdowns of single threaded loads have accumulated to 3.7 %. Trying to get some numbers on how much of that we can get back by using a flag instead of the new orig_interp PMC header field * I suspect one or two remaining GC related threading problems which only showed on the assertions I unfortunately lost from my git stash * finish my thesis!
dukeleto nine: if you need somewhere to run benchmarks, we can get you access to the gcc compile farm 19:57
nine: there are machines with 64 cores and stuff like that
NotFound nine: What branch?
dukeleto nine: gcc.gnu.org/wiki/CompileFarm 19:58
nine: instructions to get access are there. Just tell them you are part of Parrot and give them your ssh pub key
nine: lost work in your stash? Have you tried "git reflog" ?
nine NotFound: threads. Though the second 3x performance increase is not there yet because I'm still playing around a little
NotFound nine: no problem, I just want to try using threads with winxed. 19:59
nine dukeleto: git reflog? Not yet, but looks like I might find them there. thanks!
whiteknight NotFound: Yes, I want to do the same
nine NotFound: please, go ahead!
And tell my how badly it breaks :)
dukeleto nine: the reflog keeps a reference to every HEAD, even if they aren't on a branch, fyi. 20:00
nine dukeleto: I stashed the stuff and then did a git reset HEAD^ which seemed to have kicked the stuff from the stash as well. But I'll have a look at the reflog if I can find it 20:01
NotFound nine: examples/threads ? 20:02
benabik git reset shouldn't do anything to the stash.
git stash list should still show it.
nine NotFound: yes, that's where chameneos.pir is and the simpler moretasks.pir. If anything's unclear just ask 20:03
benabik: you're right! There they are! No idea how I overlooked them the first time. Must have been even more tired than I realized... 20:06
Just curious: how much slowdown of single threaded loads would actually be considered acceptable to gain threading support? 20:13
NotFound Ideally, 0 ;) 20:14
nine NotFound: of course...but that's almost impossible ;) Though I try to get as close as possible 20:15
NotFound Maybe we can duplicate sections of the core for single thread case, and switch the moment the first thread is created. 20:17
whiteknight nine: It would be very instructive to find out where and why the slowdown is occurring 20:21
nine: When we pinpoint the differences, we will be able to make a more informed decision about whether we can fix it, or whether it's worth living with 20:22
nine I'm actually a little surprised that my latest optimization caused a 1.3 % slowdown. Though I now take a lock in get_new_pmc_header I only do it when more than one thread is running. So its actually just two additional if (interp->thread_data)
whiteknight get_new_pmc_header is called a hell of a lot
I don't think that's where the issue is, not for two pointer tests causing a 1.3% slowdown 20:25
nine Well maybe we'll find a way to do it without this lock. bacek++ had some interesting thoughts on how we could structure threaded GC in the long term with local allocation and merging of pools to do m&s on the main thread.
whiteknight I think ultimately we're going to have to move to a concurrent algorithm for GC, instead of a single-threaded algorithm trying to be tolerant of threads 20:26
do a google search for VCGC "Very Concurrent GC" for an idea of what I'm thinking 20:27
benabik +1
whiteknight but for now, we do the best with what we have
nine whiteknight: had a look at that. A very interesting read. But IIRC even this algorithm needs to stop the world. But only for a very very short time
benabik Here's a horrible idea: use a function pointer to switch between thread aware and thread-less allocations. 20:28
Change the pointer before you start the 2nd thread.
nine benabik: well, since GCs are already pluggable, this wouldn't even be so horrible...
benabik Oh, yes, we already have that indirection. Hm.
whiteknight our GC should be a lot less pluggable than it currently is. All the indirect sub calls are unnecessarily expensive
In any case I have to go home now. I'll be back on later tonight 20:30
21:39 NotFound left 22:02 benabik left 22:18 whiteknight joined