Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2012-03-20

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:06 ilbot2 joined #parrotsketch
01:06 Topic for #parrotsketch is now 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: http://irclog.perlgeek.de/
01:34 contingencyplan joined #parrotsketch
04:12 alvis joined #parrotsketch
04:29 alvis left #parrotsketch
09:15 lucian joined #parrotsketch
11:47 alvis joined #parrotsketch
12:42 bluescreen joined #parrotsketch
15:20 bluescreen joined #parrotsketch
16:11 whiteknight joined #parrotsketch
16:18 whiteknight WHAT I DID:
16:18 whiteknight * Getting ready for GSOC. Our application got accepted. I've been filling out forms and writing proposal ideas on github in preparation.
16:18 whiteknight * Working on the remove_sub_flags branch. All coretests pass. Fixing t/library/* and t/language/* tests, most of which are using old load_bytecode_s and load_language_s opcodes. Things that are updated to use the new code seem to work perfectly.
16:18 whiteknight * Planning for another round of IMCC cleanups, and creating a new packfile-write API. Input welcome.
16:19 whiteknight WHAT I WILL DO:
16:19 whiteknight * Keep working on remove_sub_flags branch. I would like to get it ready for broad testing within the next week or two. I do not have a merge timeline yet, we won't rush it. We want to make sure NQP and Rakudo work fine with it before doing anything.
16:19 whiteknight * Prepare patches for NQP-rx, Winxed and maybe NQP to work with the new branch.
16:19 whiteknight * Talk to a few prospective GSOC students about project ideas
16:22 contingencyplan joined #parrotsketch
18:09 benabik joined #parrotsketch
18:58 bluescreen joined #parrotsketch
19:26 kid51 joined #parrotsketch
19:30 Util # Done: Nothing.
19:30 Util # Plan to do: Set up wiki page today for Parrot/Perl6 hackathon at YAPC::NA::2012
19:30 Util # Blockers: $WORK
19:30 Util .end
19:31 Util Hello
19:31 benabik hi
19:33 Util The first week or two after the time change, we have low attendance.
19:33 whiteknight hello
19:33 whiteknight I think cotto might not be here, he's at a conference
19:34 benabik It's actually slightly easier for me to be here on DST.  :-D
19:34 Util Which conference, whiteknight?
19:34 benabik A Drupal conf, I think.
19:36 whiteknight yeah, something with Drupals
19:37 Util Looks like the dates of YAPC::NA are 1/2-way between start of GSOC coding and mid-term evaluation.
19:38 benabik That's about what it was last year, wasn't it?
19:39 Util We should encourage GSOC students&mentors to come to YAPC for extra interaction.
19:39 Util benabik: I think so.
19:40 benabik It was very good last year.  I'll be unable to this year, sadly.
19:40 benabik (Even assuming I'm a student this year.)
19:40 whiteknight Where is YAPC this year?
19:41 Util GSOC students might not be aware (unless we tell them) that YAPC can grant scholarships to help with travel and admission.
19:41 Util Madison
19:41 benabik !
19:41 whiteknight oh, yeah, ain't no way I'm making it to Madison
19:41 benabik That would have been helpful.
19:41 Util Yet Another Perl Conference : North America - Madison, Wisconsin - June 13-15, 2012
19:42 Util whiteknight: You are in Philadelphia? benabik: Where are you based?
19:42 benabik Util: Rochester, NY
19:43 whiteknight Phily
19:43 Util I am in east-central Alabama.
19:44 Util I plan to attend. My wife Sarah is trying to come, too. She has been wanting to see a YAPC for several years now.
19:45 benabik I'd really love to come, but with a kid scheduled for the end of June, trying to vanish mid-June would probably not go over well with the wife.
19:45 Util benabik: indeed!
19:47 Util My 2nd grandchild is due August 1, but we should be OK to travel.
19:48 whiteknight benabik: your first kid?
19:48 benabik whiteknight: Yeah.  Busy summer ahead.
19:48 whiteknight the extra GSOC money will come in handy with the myriad baby expenses, at least
19:49 benabik It's not really "extra" so much as "required summer job".  :-D
19:49 whiteknight :)
19:49 benabik I need something that spans between my assistantships.
19:55 whiteknight okay, it looks like we're the only three people at the meeting. Are there any questions before we wrap this up and pretend it never happened?
19:55 nine yep
19:55 benabik four!
19:55 whiteknight nine: you have the floor
19:55 benabik (ah-ha-ha)
19:55 nine I think, I'll need some whiteknight time this week
19:56 whiteknight We'll talk to him, see what he can do
19:56 whiteknight what do you need?
19:57 nine Proxied calls can cause garbage collection which would be catastrophic if run from the wrong thread. Also the data owning thread might just be running GC as well...
19:58 nine My only idea to maybe solve this is adding a lock to the GC but it's hard to say if that would be enough and it might be negative for single threaded performance. Maybe you got some of your great ideas handy.
20:00 whiteknight GC only runs on the main thread?
20:02 nine Every interp (and thus thread) runs its own GC. Also I'm still not 100 % decided if I should run proxied PMC methods with the caller's interp or the proxied one. Everything is simple with an Integer PMC, but starts to get quite complicated with things like Sub.
20:03 nine Just to be clear: I very much appreciate anyone's input on this. Just asking whiteknight specifically, because my work is based on his ideas.
20:04 whiteknight I suggest running the method on the calling thread. The invocant is already proxied there so all accesses should be safe
20:04 whiteknight find_method on the proxy is going to have to return a clone of the Sub, since Sub is stateful
20:04 whiteknight it shouldn't be, but it currently is
20:05 nine It would certainly make the whole GC problem simpler. But it makes the question more complicated if a method should return a PMC as is, or a new Proxy to the PMC.
20:05 whiteknight return PMC as is. If the PMC originally came from a different thread, it would be a proxy already
20:06 whiteknight if the PMC was created on the current thread, return it directly
20:06 nine No it wouldnt
20:06 whiteknight wouldn't?
20:06 nine If I have a proxy to a ResizablePMCArray and do a shift, it would simply forward the shift VTABLE call to the array and thus return an unproxied PMC belonging to the other thread
20:08 whiteknight that proxies vtable call doesn't automatically proxy results?
20:10 nine It does right now because it runs the forwarded calls with the proxied PMC's interpreter. If I run them with the calling thread's interp, I could no longer be sure that all PMC results originate from the foreign interp. So I could no longer unconditionally create proxies for these results.
20:11 nine Any PMC which would be created during the forwarded call would be created on the thread's interp. Which would be nicer for GC, nicer for performance but Proxy would somehow have to know that it can pass it on as is.
20:13 whiteknight all this gets much easier if the PMC structure contains a "parent interp" pointer for easy identification
20:14 whiteknight if  (interp == pmc->parent_interp) all is good, etc
20:15 nine Which it even does on my threads_playground branch, because I use it to track down PMCs leaking to interps where they don't belong.
20:15 whiteknight make that a permanent part of the design for now
20:16 whiteknight Add a macro PMC_IS_OWNED_BY(p, interp), so we can try to optimize it later
20:19 whiteknight then in GC we can explicitly ignore all PMCs that don't belong. In the proxy we can auto-proxy results that are from a different interp, etc. A lot of logic becomes easier
20:19 nine I'm a bit worried about the cost, but don't have any numbers.
20:20 whiteknight I'm sure it will have a negative impact, but we save on a lot of costly logic elsewhere
20:21 whiteknight If we wrap it up in a #ifdef PARROT_HAS_NINES_THREADS block, we can cut it out completely for single-threaded builds
20:21 whiteknight and if we can clean out enough space, we might be able to store an interp_id in the PMC->flags field. Of course, that limits the number of interps we can have
20:23 whiteknight We've got space there for at least 8 bits worth, if we have fewer than 256 interps
20:23 whiteknight if we're on a machine with more than that many processor cores, maybe the extra pointer overhead is a non-issue
20:25 whiteknight being able to do a this_interp == that_interp pointer comparison will be very fast compared to other kinds of lookups
20:26 nine Yep, the comparison doesn't worry me since it's only done during GC runs and in Proxy. Both situations where we don't really hurt a single threaded program. It's just adding 8 bytes to every single PMC that sounds expensive.
20:27 whiteknight the extra piece of mind in avoiding GC "catastrophy" may be worth the cost
20:28 whiteknight and considering the whole lockless system was designed to be safer, that makes good sense
20:29 whiteknight okay, I have to pack up and go home now. I'll be online later tonight to continue chatting
20:35 Util Any other business?
20:37 Util Adjourned. Thanks, everyone!
21:32 dukeleto joined #parrotsketch
21:32 * dukeleto waves
21:33 dukeleto did i miss it?
21:35 benabik dukeleto: Very yes
21:35 benabik By 2 hours or so
21:46 dukeleto lulz
21:50 dukeleto ETOOLATE
22:35 whiteknight joined #parrotsketch

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary