Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2013-02-26

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

All times shown according to UTC.

Time Nick Message
08:04 contingencyplan joined #parrotsketch
12:49 xcombelle joined #parrotsketch
14:18 bluescreen joined #parrotsketch
17:17 bluescreen joined #parrotsketch
19:28 not_gerd joined #parrotsketch
19:30 moritz OH HAI
19:30 cotto Hello
19:30 moritz it's #parrotketch time, I think
19:30 cotto You are correct.
19:30 not_gerd hi
19:31 moritz so, my report for this week: reported a parrot bug (related to sockets), tested fix by cotto++. Not much more.
19:31 cotto I'm glad that fix worked out for you.
19:32 * not_gerd re-submitted cleaned-up pull requests for my packfile/eval/target=pbc work
19:32 cotto I've been seeing a segfault during the NQP build with recent NQP versions, so that bug that was preventing a 5.x update might be back.
19:33 cotto If it looks reproducible enough, that'll be a good thing for someone (likely me) to do this week.
19:33 Util Hello
19:33 moritz fwiw all the segfaults I observed went away after running 'git clean -xdf' in all of (rakudo, nqp, parrot)
19:33 Coke I didn't manage to commit to sixparrot much since last week.
19:34 moritz (with my setup, cleaning in rakudo removes the installation location too)
19:34 Util Released Parrot 5.1.0; working on cleanup of Release Manager's Guide, and doc-publishing process.
19:34 cotto Speaking of which, I'd like to see sixparrot merge (or at least plan to merge) into master in the near future.
19:35 cotto Thoughts?
19:35 Util Please vote on the proposed hackathon: http://ideas.yapcna.org/idea/6290DA56-7AEB-11E2-818A-8AC49D4F7835/perl-ng-hackathon
19:35 cotto Util++
19:36 Util Where does sixparrot live? I would like to test it.
19:36 not_gerd I don't see merging back to master as a priority until the 'hard stuff' gets tackled
19:36 cotto Util: It's a branch of parrot/parrot
19:36 not_gerd however, it would make keeping the branches in sync (bugfixes) easier
19:36 Util Great; thanks
19:36 cotto not_gerd: that's my thinking too.
19:37 cotto My NQP breakage seems to have been from a local modification that I forgot about.  It's working now.
19:39 not_gerd publicity-wise, it might be a good idea to wait with a sixparrot-based release until there are some significant improvements
19:39 cotto not_gerd: I'm content to merge now and publicize once there are measurable improvements.
19:39 cotto Having too many active branches floating around makes me a bit nervous.
19:41 Coke cotto: better something unfinished dies in a branch alone rather than on master.
19:42 cotto Coke: yes, but my impression was that it was at a point where it could be merged without causing much damage.
19:44 cotto We can leave it as is and revisit if things start to heat up in master if that's your preference.
19:45 cotto Relatedly, any thoughts on the ops2c branch?  Parrot, NQP and Rakudo all seem to build and run just fine and there's a small decrease in the build time due to p5 being faster at processing .ops files.
19:45 cotto The only likely downside is that opsc could easily start to bitrot.
19:45 Util Looking at sixparrot-TODO.md, there is still quite a lot of work to be done to meet the goals. The branch is being actively worked on; I see no benefit to a mid-process merge.
19:47 cotto Note that getting rid of opsc is a prerequisite for getting rid of parrot-nqp.
19:49 not_gerd +1 to removing nqp-rx ops2c for now
19:49 cotto good enough.  I'll do that sometime this week.
19:49 not_gerd keep in mind that we need access to ops definitions at runtime if we ever want to re-add a jit
19:50 cotto That strikes me as something that's pretty far out in the future.
19:50 not_gerd agreed
19:50 cotto The old jit isn't something that should be brought back.
19:51 not_gerd I wonder how far one could go gluing together the ops C code, send it through libtcc and register the combined op as a dynop
19:51 not_gerd that's called selective inlining, I believe
19:51 cotto I'll make sure to post to parrot-dev before merging.
19:52 cotto not_gerd: it depends on how hight the expected performance increase is.
19:52 cotto *high
19:52 cotto but that's an interesting idea
19:54 not_gerd one would need to look into how to identify jitable op sequences (eg change of control flow only at end of block), but I don't see why it couldn't work in principle
19:54 Util Are there any TODOs not yet done in the ops2c branch? Any more major work needed?
19:55 cotto Util: the final piece is to make a thin wrapper script so that NQP/Rakudo can continue to build without modifying their makefile rules.
19:55 cotto I've been testing by modifying the makefile rules manually.
19:56 cotto It's a small but important piece that'd allow a seamless transition.
19:56 Util Do you plan do create&test that in the ops2c branch before merging?
19:56 cotto Util: you're welcome to do it.
19:57 cotto Util: yes
19:58 Util I am travelling starting tomorrow; if it remains undone on Saturday, then I can tackle it.
19:58 cotto Util: ok.  Thank.  I hope I beat you to it,
19:59 cotto I forgot to mention that I took a shot at profiling PCC.  There doesn't seem to be a whole lot in terms of small optimizations.
20:00 cotto Are there any questions or concerns?
20:01 Util Does anyone see *any* reason to keep the github parrots docs in separate repos per major release?
20:01 not_gerd is allison still looking into the pcc refactor?
20:01 Util Right now, it is parrot-docs4, parrot-docs5, ...
20:01 Util Why not just parrot-docs ?
20:02 cotto Util: I didn't know we were doing that.  It seems silly.
20:02 cotto +1 to it going away
20:02 Util (The instructions for publishing break badly at the release boundary)
20:03 allison not_gerd: yes
20:03 Util I looks like Alvis just set it up that way in the beginning. If no one objects today, I will move to unnumbered repo.
20:03 cotto Util: go for it!
20:03 not_gerd allison: good to hear
20:04 allison not_gerd: I'm working through MMD removal as a start
20:04 allison not_gerd: pmichaud says he's amenable to stripping down to just call_sig
20:05 allison not_gerd: but NQP will need some revisions
20:05 allison so, I'm not going there to start :)
20:05 allison not_gerd: still, it'd be easy enough to split out bits
20:05 allison not_gerd: particularly, remove all PCC method calls from the VM internals
20:05 cotto I think that's how much of this work is going to have to go.
20:06 allison not_gerd: i.e. if a piece of functionality is used both internally, and from an HLL, the HLL-accessible method should be calling into a C function
20:07 allison not_gerd: rather than the internals going through the painfully slow process of invoking a method
20:08 allison not_gerd: I'm not sure if we'll get so far as removing method invocation from the internals, but can save a lot on execution cost by removing what we can
20:12 cotto I'm excited to see what this week will hold.
20:13 cotto Are there any other questions?
20:13 not_gerd allison: do you believe the current design is viable or will a redesign be necessary long-term?
20:13 allison not_gerd: depends on what you mean by "the current design"
20:14 allison not_gerd: the current code will need substantial refactoring, definitely
20:14 allison not_gerd: I'm more interested in doing that in direct response to performance benchmarks
20:15 allison not_gerd: not really interested in repeating the process of a lengthy "hypothetical" design, reimplementing from scratch, and then finding out whether the new idea provides reasonable performance
20:15 allison not_gerd: Does that make sense?
20:15 not_gerd yes
20:16 allison not_gerd: As in, I think the design will change a lot, it's more a matter of how we go about it.
20:17 not_gerd I don't know how the NQP-side (multi-dispatch via captures) interacts with the Parrot side (callcontexts?) right now
20:17 bluescreen joined #parrotsketch
20:17 not_gerd perhaps there are ways to integrate them more tightly
20:17 allison At the Rakudo level, the use only call_sigs, and none of the Parrot fancy dispatch
20:18 allison At the NQP level, they don't use multi-dispatch at all, but do use slurpy, flat, and other features
20:18 allison not_gerd: yes, I suspect there are ways we could achieve better performance by pulling features of Rakudo's dispatch down to the Parrot level
20:19 not_gerd I was thinking more along the line of getting rid of unnecessary marshalling
20:19 allison not_gerd: but the first step is removing expensive features of Parrot's current dispatch
20:19 not_gerd eg do arguments move from NQP captures to registers help in the callcontext just to end up in the lexpad, etc
20:20 * not_gerd has noo idea how the data flows right now
20:20 allison not_gerd: well, if they're using call_sig, there's no marshalling involved
20:20 * not_gerd wonders how he managed to mangle that sentence so badly
20:20 allison not_gerd: yes, I think we're talking about the same thing
20:21 allison not_gerd: fundamentally, cut down on operations necessary to make a call
20:22 not_gerd without considering the current situation, if I were to design a calling convention, I'd do it like that:
20:23 not_gerd have a global (or rather thread-local) capture (set of positional+named args), which gets inspected by the mmd and moved into the lexpad once the candidate has been found
20:23 not_gerd it gets a bit more tricky as the mmd can call subs as well (where clauses etc)
20:24 not_gerd but it would cut down on allocations
20:25 allison well, mmd is going away entirely, so that simplifies things
20:25 allison (going away from the Parrot level, Rakudo handles its own)
20:26 allison not global or thread-local though, that assumes synchronicity
20:26 allison it's not a call stack
20:26 allison it's more "execution context local"
20:27 allison not_gerd: sorry, probably not making much sense, I'm trying to both explain quickly for IRC and explain in detail :)
20:27 allison not_gerd: you're heading the right direction, though
20:27 not_gerd the global would only be a convenient staging area where we stash arguments until the mmd has identified the lexpad where they need to end up ultimately
20:27 allison not_gerd: essentially what you want is for the lexpad to be prepopulated with the arguments
20:28 allison not_gerd: i.e. the lexpad *is* the call signature
20:28 allison to start with
20:29 allison not_gerd: ah, but the lexpad is created as part of dispatch, so it's not really that dispatch has to "find the right lexpad"
20:29 not_gerd I'm rambling here under the assumption that long-term, NQP's mmd gets moved into Parrot
20:29 allison not_gerd: it just has to build the right structure for the rest of the lexpad, based on what sub actually eventually gets invoked
20:30 allison not_gerd: think of it this way, the call_sig is @_
20:30 not_gerd I see
20:30 allison not_gerd: it's just a smarter form of @_
20:30 allison that contains signature information
20:31 not_gerd there's no need for a staging area if the structure of the lexpad is dynamic
20:31 allison not_gerd: aye
20:32 not_gerd the Perl6 lexcial environment is known statically, and in principle could have a less generic structure
20:33 allison it could, but it doesn't have to
20:33 not_gerd ie after mmd we could know that argument $foo needs to end up in slot 3
20:33 allison i.e. knowing it statically can give you some optimization advantages
20:33 allison i.e. but it might also *not* give optimization advantages
20:34 allison (i.e. treating it as a static entity could make it more expensive)
20:35 allison not_gerd: I'm not starting from integrating all the Perl 6 dispatch features into Parrot, I'm just starting with "make what NQP/Rakudo uses from Parrot now fast"
20:36 not_gerd that's sensible
20:36 cotto which is what we need most right now
20:37 not_gerd anything beyond that would need invasive Rakudo-side changes, and that's something to consider once the Parrot-side is in better shape
20:40 * not_gerd has nothing more to discuss
20:41 cotto Alright.  Let's call it a wrap.
20:45 not_gerd left #parrotsketch

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