|
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 January 2013. |
|||
|
08:04
contingencyplan joined
12:49
xcombelle joined
14:18
bluescreen joined
17:17
bluescreen joined
19:28
not_gerd joined
|
|||
| moritz | OH HAI | 19:30 | |
| cotto | Hello | ||
| moritz | it's #parrotketch time, I think | ||
| cotto | You are correct. | ||
| not_gerd | hi | ||
| 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. | ||
| 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. | ||
| If it looks reproducible enough, that'll be a good thing for someone (likely me) to do this week. | 19:33 | ||
| Util | Hello | ||
| moritz | fwiw all the segfaults I observed went away after running 'git clean -xdf' in all of (rakudo, nqp, parrot) | ||
| Coke | I didn't manage to commit to sixparrot much since last week. | ||
| 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. | ||
| cotto | Speaking of which, I'd like to see sixparrot merge (or at least plan to merge) into master in the near future. | ||
| Thoughts? | 19:35 | ||
| Util | Please vote on the proposed hackathon: ideas.yapcna.org/idea/6290DA56-7AEB...-hackathon | ||
| cotto | Util++ | ||
| 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 | ||
| cotto | Util: It's a branch of parrot/parrot | ||
| not_gerd | however, it would make keeping the branches in sync (bugfixes) easier | ||
| Util | Great; thanks | ||
| cotto | not_gerd: that's my thinking too. | ||
| My NQP breakage seems to have been from a local modification that I forgot about. It's working now. | 19:37 | ||
| 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. | ||
| Having too many active branches floating around makes me a bit nervous. | |||
| Coke | cotto: better something unfinished dies in a branch alone rather than on master. | 19:41 | |
| cotto | Coke: yes, but my impression was that it was at a point where it could be merged without causing much damage. | 19:42 | |
| We can leave it as is and revisit if things start to heat up in master if that's your preference. | 19:44 | ||
| 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 | ||
| The only likely downside is that opsc could easily start to bitrot. | |||
| 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. | ||
| cotto | Note that getting rid of opsc is a prerequisite for getting rid of parrot-nqp. | 19:47 | |
| not_gerd | +1 to removing nqp-rx ops2c for now | 19:49 | |
| cotto | good enough. I'll do that sometime this week. | ||
| not_gerd | keep in mind that we need access to ops definitions at runtime if we ever want to re-add a jit | ||
| cotto | That strikes me as something that's pretty far out in the future. | 19:50 | |
| not_gerd | agreed | ||
| cotto | The old jit isn't something that should be brought back. | ||
| 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 | |
| that's called selective inlining, I believe | |||
| cotto | I'll make sure to post to parrot-dev before merging. | ||
| not_gerd: it depends on how hight the expected performance increase is. | 19:52 | ||
| *high | |||
| but that's an interesting idea | |||
| 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? | ||
| 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 | |
| I've been testing by modifying the makefile rules manually. | |||
| 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? | ||
| cotto | Util: you're welcome to do it. | ||
| Util: yes | 19:57 | ||
| 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, | ||
| 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. | 19:59 | ||
| Are there any questions or concerns? | 20:00 | ||
| 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? | ||
| Util | Right now, it is parrot-docs4, parrot-docs5, ... | ||
| Why not just parrot-docs ? | |||
| cotto | Util: I didn't know we were doing that. It seems silly. | 20:02 | |
| +1 to it going away | |||
| Util | (The instructions for publishing break badly at the release boundary) | ||
| 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. | ||
| cotto | Util: go for it! | ||
| not_gerd | allison: good to hear | ||
| allison | not_gerd: I'm working through MMD removal as a start | 20:04 | |
| not_gerd: pmichaud says he's amenable to stripping down to just call_sig | |||
| not_gerd: but NQP will need some revisions | 20:05 | ||
| so, I'm not going there to start :) | |||
| not_gerd: still, it'd be easy enough to split out bits | |||
| not_gerd: particularly, remove all PCC method calls from the VM internals | |||
| cotto | I think that's how much of this work is going to have to go. | ||
| 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:06 | |
| not_gerd: rather than the internals going through the painfully slow process of invoking a method | 20:07 | ||
| 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:08 | ||
| cotto | I'm excited to see what this week will hold. | 20:12 | |
| 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? | ||
| allison | not_gerd: depends on what you mean by "the current design" | ||
| not_gerd: the current code will need substantial refactoring, definitely | 20:14 | ||
| not_gerd: I'm more interested in doing that in direct response to performance benchmarks | |||
| 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 | ||
| not_gerd: Does that make sense? | |||
| not_gerd | yes | ||
| 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:16 | |
| not_gerd | I don't know how the NQP-side (multi-dispatch via captures) interacts with the Parrot side (callcontexts?) right now | 20:17 | |
|
20:17
bluescreen joined
|
|||
| 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 | ||
| At the NQP level, they don't use multi-dispatch at all, but do use slurpy, flat, and other features | 20:18 | ||
| 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 | |||
| 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 | ||
| not_gerd | eg do arguments move from NQP captures to registers help in the callcontext just to end up in the lexpad, etc | ||
| 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 | ||
| not_gerd wonders how he managed to mangle that sentence so badly | |||
| allison | not_gerd: yes, I think we're talking about the same thing | ||
| not_gerd: fundamentally, cut down on operations necessary to make a call | 20:21 | ||
| not_gerd | without considering the current situation, if I were to design a calling convention, I'd do it like that: | 20:22 | |
| 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 | ||
| it gets a bit more tricky as the mmd can call subs as well (where clauses etc) | |||
| but it would cut down on allocations | 20:24 | ||
| allison | well, mmd is going away entirely, so that simplifies things | 20:25 | |
| (going away from the Parrot level, Rakudo handles its own) | |||
| not global or thread-local though, that assumes synchronicity | 20:26 | ||
| it's not a call stack | |||
| it's more "execution context local" | |||
| not_gerd: sorry, probably not making much sense, I'm trying to both explain quickly for IRC and explain in detail :) | 20:27 | ||
| not_gerd: you're heading the right direction, though | |||
| 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 | ||
| allison | not_gerd: essentially what you want is for the lexpad to be prepopulated with the arguments | ||
| not_gerd: i.e. the lexpad *is* the call signature | 20:28 | ||
| to start with | |||
| 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 | ||
| 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 | ||
| not_gerd: think of it this way, the call_sig is @_ | 20:30 | ||
| not_gerd | I see | ||
| allison | not_gerd: it's just a smarter form of @_ | ||
| that contains signature information | |||
| not_gerd | there's no need for a staging area if the structure of the lexpad is dynamic | 20:31 | |
| allison | not_gerd: aye | ||
| not_gerd | the Perl6 lexcial environment is known statically, and in principle could have a less generic structure | 20:32 | |
| 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 | ||
| allison | i.e. knowing it statically can give you some optimization advantages | ||
| i.e. but it might also *not* give optimization advantages | |||
| (i.e. treating it as a static entity could make it more expensive) | 20:34 | ||
| 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:35 | ||
| not_gerd | that's sensible | 20:36 | |
| cotto | which is what we need most right now | ||
| 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:37 | |
| not_gerd has nothing more to discuss | 20:40 | ||
| cotto | Alright. Let's call it a wrap. | 20:41 | |
|
20:45
not_gerd left
|
|||