Priorities for this week: Plan our Testing Infrastructure (choose lead person), Contact all GSoC students | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/
Set by moderator on 10 May 2011.
00:00 lucian left 00:44 bacek joined 00:48 whiteknight left 00:50 whiteknight joined 00:56 whiteknight left, whiteknight joined 01:52 wagle left 01:55 wagle joined 01:56 ShaneC left 02:40 whiteknight left 06:57 contingencyplan joined 09:30 contingencyplan left 11:09 whiteknight joined 13:12 lucian joined 15:02 contingencyplan joined 15:24 whiteknight left 15:27 whiteknight joined 15:39 bluescreen joined 15:40 mariano joined 15:41 bluescreen_ joined 15:45 bluescreen__ joined 15:46 bluescreen__ left, mariano left, bluescreen__ joined 16:07 lucian_ joined 16:12 lucian left 16:14 lucian joined, lucian_ left 16:18 lucian_ joined, lucian left 16:21 bluescreen__ left 16:22 bluescreen__ joined 16:23 bluescreen left, bluescreen_ left, bluescreen__ left 17:05 contingencyplan left 19:01 soh_cah_toa joined 19:24 pmichaud joined 19:28 bubaflub joined 20:32 plobsing joined 20:46 soh_cah_toa left 20:49 soh_cah_toa joined 20:51 dukeleto joined
dukeleto waves 20:51
tadzik waves too 20:52
pmichaud I wanted to post to parrot-dev but m/l issues are likely to make it late, so I'm nopasting instead: 20:54
gist.github.com/972619http://gist.g...com/972625 20:56
oops
gist.github.com/972625
20:57 kid51 joined
dukeleto hola 21:00
cotto hello
pmichaud for those coming in just now and didn't catch it -- my preliminary notes for PDS are at gist.github.com/972625
bubaflub hello 21:02
dukeleto PDS meeting agenda is here: nopaste.snit.ch/45279
soh_cah_toa yay, pds now!
pmichaud (I have to run a quick errand -- bbi15) 21:04
cotto For the record, our roadmap goals were listed in this thread: groups.google.com/group/parrot-dev/...0c2e531e92 21:05
dukeleto so where is this train headed?
any other gsoc students hiding? 21:06
cotto deprecations as data, imcc isolation, M0 spec
soh_cah_toa dukeleto: i'm here
kid51 Re: roadmap goals from last summit 21:07
In March, I solicited feedback on them both on parrot-dev and in personal communications with other key developers.
My recollection of the feedback was: 21:08
1. Deprecations as data: Substantially met. Indeed, met so soon after PDS that it perhaps needn't have been a Roadmap Level goal.
2. IMCC isolation: A lot of effort by whiteknight et al. I hope whiteknight can describe status better. 21:09
3. M0: Substantial progress only in last 4 weeks.
whiteknight: Can you describe status of IMCC isolation? 21:10
whiteknight sure
It was a little bit of a bumpy road, but the state of IMCC is much better now than it was
dukeleto soh_cah_toa++ # excited and diligent gsoc students
whiteknight IMCC pokes into the internal guts of Parrot still, but to a far lower degree. Parrot does not depend on IMCC at all anymore 21:11
kid51 whiteknight: Any more details? Next steps?
whiteknight we can run libparrot without ever initializing or using IMCC, and it's feasible that we can build libparrot completely without imcc
at the moment, there are no urgent next steps. 21:12
kid51 Thanks.
dukeleto: Any next steps for deprecations as data?
whiteknight Eventually we will be able to excise IMCC completely, and I suspect some GSoC projects are going to help nudge us in that direction
dukeleto kid51: yes. I would like to have a web-based frontend for deprecations
kid51 Can you describe that? Is it a "nice to have" or a "must have"? 21:13
dukeleto kid51: for example...
kid51: we should automatically be running our deprecation tools on Rakudo, Partcl and other HLLs, with a web-frontend that shows the data 21:14
pmichaud (back)
kid51 dukeleto: Can you describe what you mean by "our deprecation tools"? 21:15
dukeleto kid51: such as "HLL Foo is using function_bar which is ready for removal in 43 days". It isn't perfect, and it won't find everything, but it would be a useful canary in the coalmine
kid51 And do we currently have tools that do that (web interface or otherwise)?
dukeleto tools/dev/(dedeprecator,show_deprecations.nqp,show_experimental.nqp) 21:16
kid51: no, we don't. And I think that is something that should change.
kid51: we need to improve the flow of information from HLLs to Parrot core and vice versa
pmichaud (are we taking comments on the next steps or simply identifying them now?)
kid51 dukeleto: To be honest, I was completely unaware of the existence of those programs
pmichaud: No, we're reviewing what was done on Roadmap Goals since last PDS 21:17
dukeleto kid51: life moves fast :)
kid51 cotto: Current status of M0?
cotto more detailed M0 status - gist.github.com/972649
pmichaud kid51: I ask because your question was "Any next steps...?" and I have some questions/comments
it can wait
kid51 pmichaud: I know. We'll get to you :-) 21:18
bacek ~~
pmichaud (specifically, I have questions/comments about dukeleto's next steps :-)
(silencing)
kid51 pmichaud: Yes, but that will come in a few.
kid51 reads cotto's gist 21:19
dukeleto i expect that i am very close to finishing the m0 assembler. I haven't had sufficient time/tuits recently to put towards it
kid51 So, my impression is that substantial work was done on all 3 Roadmap Goals ... 21:20
dukeleto kid51: indeed
cotto yes
kid51 ... but in each area there are substantial next steps.
If so, then can we review what was done since last PDS that was *not* in Roadmap Goal context? 21:21
Example, bacek et al work on GC?
dukeleto estimates roughly 2 weeks to a done-enough M0 assembler to shake out any remaining holes in the M0 spec
pmichaud: ask your question about m0, and if bacek is around to talk about the GC, we will let him 21:22
pmichaud I don't have a question about m0
my comment is about the deprecation-on-web thingy
kid51 bacek: ping
bacek kid51, pong
bacek is still trying to wake up. 21:23
dukeleto pmichaud: ah. well, i would like to hear that as well :)
pmichaud: go for it, give bacek++ time to wake himself
pmichaud my main comment is that the web tends to be passive -- it requires someone to actively go look at it before things are noticed. Better would be notifications to the mailing list or channel (a-la ttbot).
dukeleto pmichaud: to which mailing list? 21:24
kid51 In the general context of non-Roadmap goals, there's what we did despite not being on roadmap (GC work) and what we failed to do (pmichaud's gist)
dukeleto pmichaud: people get their axes when anybody attempts to send automated smoker/etc email to parrot-dev
pmichaud parrot-dev, and/or the mailing list of the thing being checked for deprecation
dukeleto pmichaud: i think we may need a parrot-smoker mailing list or something 21:25
pmichaud don't do it on every commit -- do it once per day. or only when the deprecation list changes
even once per week ought to be sufficient
dukeleto pmichaud: parrot-dev simply won't work. People will have torches at your (or my) door.
pmichaud make a separate deprecations list that people can subscribe to
I'm simply saying "look it up on the web" is likely to be ignored
or forgotten
dukeleto pmichaud: emails can be sent from the software
pmichaud feel free to ignore my suggestion and do whatever you think is best
kid51 pmichaud: Agreed. It would suffer from wiki-like bitrot
pmichaud I don't think it will catch all that much anyway. 21:26
dukeleto pmichaud: i attempted to send emails from jitterbug to parrot-dev for failing test suites, and bacek++ was not pleased
cotto I like active notification via email, but web apps can do that too.
dukeleto pmichaud: i appreciate your positive encouragement
kid51 As for non-Roadmap stuff, ... 21:27
... last time around ... 21:28
pmichaud kid51: instead of "failed to do" i prefer "haven't achieved yet" :)
bacek dukeleto, I prefer ttbot for broken builds. It much less annoying but still highly visible.
kid51 ... we got a list of rakudo's needs, in part during the PDS and in part in the following days.
So, technically, they were'nt on the roadmap.
And I suspect that we will have to put them on the roadmap. 21:29
But, for right now, pmichaud, do you have anything to add to your comments in gist?
pmichaud only that if we get to a discussion of dealing with deprecation breakages, I now have a suggestion. it can wait until we get to that point (if ever) 21:30
kid51 okay.
Other than reserving time for bacek on GC, are there any other *retrospective* things we should discuss? 21:31
pmichaud will parrot be relying on rakudo for its performance measurements going forward?
one of the things we discovered with rakbench was that the February 2011 release was horribly slower than the january one. I don't believe anyone noticed it until I did the benchmarks with rakudo. 21:32
bacek pmichaud, I definitely will use rakbench.
whiteknight we don't have any benchmarks that really duplicate Rakudo's performance profile
pmichaud whiteknight: yes, thus my question.
whiteknight pmichaud: it is an invaluable source of data, although not the only one we have
pmichaud agreed, but still not an answer to my question
cotto pmichaud, if you mean "regularly testing Rakudo's performance", that's something we need to do. We should form a plan to that end. 21:33
pmichaud I'm not asking that rakudo be the exclusive measure. I'm simply asking if Parrot will need to be using it as a measure.
kid51 Yes
pmichaud because that has implications for rakudo's release/dependency cycle
cotto Of course not, but going from testing one language to testing two is much easier than zero to one. 21:34
kid51 describe implications ...
pmichaud it has been suggested again today (on the mailing list) that rakudo should be targeting something other than parrot head
if rakudo chooses to target only supported releases, then performance benchmarking isn't really possible
whiteknight pmichaud: what Rakudo is, is a great measure of Rakudo performance. If we don't have a rakudo benchmark, we will optimize for other benchmarks that won't necessarily help Rakudo 21:35
pmichaud I want to either kill the notion that rakudo should target something other than head, or make it formal that it should only target releases.
whiteknight: false.
whiteknight so, if we want Rakudo performance to increase, we need it as a regulra benchmark
pmichaud the benchmarks we did this past month are almost exclusively Parrot performance.
whiteknight pmichaud: these ones, yes. There have been plenty of other cases where the usage patterns of Rakudo were not adequately covered by our benchmakrs 21:36
the last round is just one of many to consider
pmichaud I'm not following where you're leading.
s/following/understanding/
perhaps it's not important 21:37
anyway, that's my question, I don't know that it needs resolution in this meeting.
bacek How hard is to setup infrastructure similar to speed.pypy.org?
dukeleto bacek: it is time and energy to set it up and not difficulty 21:38
pmichaud I may be able to come up with something. 21:39
dukeleto bacek: isparrotfastyet.com attempted to get there, but i doubt atrodo++ has much time to devote to it
pmichaud Still, not directly addressing my question.
dukeleto pmichaud: i was not attempting to address your question
pmichaud fair enough.
(my comment was in response to bacek, fwiw) 21:40
whiteknight pmichaud: I'm not sure I am clear what your question is
pmichaud will parrot be relying on Rakudo (at all) for (any of) its performance measurements going forward?
bacek pmichaud, one of the current problems - we don't have consistent way of comparing performance of parrot builds. 21:41
whiteknight my answer is that I thnk it's in the best interests of Rakudo if we do
cotto It's clear that not having an aggregation of Rakudo's performance has caused us to miss its performance regressions due to Parrot. Let's make it a roadmap goal to make those measurements accessible.
bacek pmichaud, from my point of view - yes, we'll use it.
pmichaud and if yes, does that mean that we expect Rakudo to be continue to target something more frequent than individual parrot releases?
whiteknight we will be able to focus our optimization efforts on what Rakudo needs if we are benchmarking regularly against Rakudo
dukeleto bacek: we could run a benchmark suite on the OSL supercell vm cluster
whiteknight pmichaud: I'm not sure that's a question Parrot can answer. 21:42
dukeleto bacek: but we don't, because no one has said "sure, I'll stop everything and spend an undefined amount of time setting up and maintaining something"
whiteknight if Rakudo works against Parrot head, we benchmark the pair more frequently
if not, we benchmark less frequently
cotto pmichaud, I think the best answer is that we'll support Rakudo's attempts to run against master.
pmichaud cotto: thank you. 21:43
whiteknight yes, what cotto says
(my ability to explain what I am thinking is poor today)
pmichaud that answers my question(s)
kid51 Do we have any more to discuss under 'I' of the agenda posted here: nopaste.snit.ch/45279?tx=on&sub...Format+it! ? 21:45
pmichaud I wish to commend whiteknight++ on the imcc landing. That was non-disruptive (and difficult to achieve). 21:46
it was "non-disruptive" to Rakudo, and had a huge potential to be.
so, fantastic work. 21:47
whiteknight being non-disruptive was the #1 priority
pmichaud you succeeded.
whiteknight thank you very much
kid51 whiteknight: how was non-disruptiveness achieved?
whiteknight kid51: identifying a stable interface, and testing the heck out of it
kid51 Are we ready to go on to Agenda item II? 21:49
pmichaud (I am ready. 21:50
)
cotto sure 21:51
kid51 Hearing no objection ....
cotto The closest conference I know of to July 19 is OSCON, which goes from the 25th to the 29th.
kid51 I'm recommending that we set date for our next summit now, lest we forget about it later in meeting.
pmichaud FOSSCON is in Philadelphia on July 23 (I'm tentatively attending)
cotto Yes. I was looking at the 2010 fosscon. 21:52
kid51 I *strongly* want us to avoid any last-minute rescheduling of PDS as we did this time. Anticipating an Apr 30/May 1 PDS, I scheduled my time off from work and travel plans accordingly.
pmichaud at any rate, I don't have an expected conflicts for the 30th-31st
whiteknight Those dates work fine for me
pmichaud *any
bacek Any date should work for me. 21:53
cotto I also don't see any conflict.
kid51 Do we then have a consensus that the next PDS will be held on either July 30 or 31? (Exact time TBD)
whiteknight yes, let's set it for that weekend, we'll pick the time with doodle or whatever 21:54
cotto +1
pmichaud +0.5 # my attendance is less weighty than others'
kid51 Okay, so now we can proceed to Agenda Item III
21:54 mikehh joined
cotto any volunteers to send the doodle? 21:54
pmichaud I volunteer cotto, since he's experienced at doodling. :) 21:55
cotto sigh
bacek cotto, if you have to ask :)
cotto will doodle
whiteknight cotto: let me take it this time
pmichaud (is it a lot of work?)
whiteknight We need to raise the bus number
cotto whiteknight, even better
pmichaud, not really
pmichaud okay
bacek afk a bit
pmichaud on to III when others are ready 21:56
whiteknight I'll look at that later tonight
cotto sure
kid51 My general belief ...
... is that in this quarter (and probably the next) ...
is that our Roadmap Goals have to focus more on what our customers (HLLs) need now rather than what we (parrot core devs) might choose to work on the most 21:57
Which means elevating some of the concerns raised by pmichaud to Roadmap Goal status and forming teams to work on them.
Which further means that getting work done in those areas takes precedence over, say, extending work on other areas. 21:58
That's my general feeling.
whiteknight I think it's looking like I'm going to need to start focusing on profiling 21:59
kid51 Among other things, that implies that our devs should not get so caught up in GSOC mentoring that we ignore HLL needs
cotto I was just thinking that I need to make that a roadmap goal.
whiteknight that appears to be a huge area of concern for Rakudo where nobody else is currently working
cotto (referring to what whiteknight said)
whiteknight I was really hoping we would have a GSoC student on that project, but that didn't pan out
cotto She tried, but not hard enough, so here we are 22:00
whiteknight right
cotto sounds like whiteknight and I are volunteering. Any others?
whiteknight beyond that, reading through pmichaud's message, it looks like general optimizations are the name of the game
kid51 As I noted earlier, we have to distinguish between "nice to have" (which is an excellent place for GSOC) and "must have" (which is province of Roadmap Goals)
whiteknight We should set a performance goal. Say, Parrot 3.5 should be 10% faster than the Parrot 3.0 build for Rakudo 22:01
cotto If a q&d hacky profiler got a significant improvement, profiling is beyond "nice to have"
whiteknight and we hit that milestone by whatever means necessary
bacek whiteknight, heh. On what kind of box?
whiteknight bacek: any box. Lots of hand-waving
cotto valgrind?
also, how much ram 22:02
kid51 "we hit that milestone by whatever means necessary" -- yes that is what a Roadmap Goal ought to mean
bacek whiteknight, 3.3 is 20% faster than 3.0 on 4G- boxes.
whiteknight bacek: on pmichaud's box
kid51 :)
cotto whiteknight, nice 22:03
bacek whiteknight, 8G, 64bits? Lets rewrite PCC from scratch.
whiteknight kid51: a percentage performance improvement is hardly something that we can ever guarantee
bacek: don't tempt me. I *will* rewrite PCC eventually
bacek I can probably increase GMS performance a bit, but this box isn't memory bounded.
whiteknight I would start on it tomorrow, if profiling weren't a bigger need
We need profiling, we need four metric shit-tons of benchmarking, and we need optimizing 22:04
pmichaud note that from rakudo perspective, "faster parrot" is still more important than "profiling". It's just that profiling can be a huge help towards getting to "faster parrot"
also, rakbench can easily accommodate pure Parrot benchmarks, if we wish to add some.
whiteknight if we can get teams dedicated to each of those three things, I think we can call that a roadmap
bacek I think I can improve current PCC a bit without total redesign. But "C-to-PIR" calls and MMD are way too complex.
whiteknight unless there are other things people want to get devoted to
bacek: I'm not as worried about it as you are. C-to-PIR isn't too bad 22:05
pmichaud I would recommend holding on PCC until we've got Rakudo no 6model. there will be important lessons there that feed into pcc improvements
whiteknight MMD is trickly only because we need to preserve semantics
pmichaud s/no 6model/on 6model/
bacek whiteknight, C-to-PIR is why we have intermediate storage of arguments. 22:06
pmichaud (unless, of course, there is low hanging fruit on pcc improvements, in which case pick 'em right away)
bacek whiteknight, MMD is tricky because of :flat
whiteknight bacek: right, but we have all those interfaces. If we keep CallContext, we can keep C-to-PIR the way it is without changes
pmichaud: nothing low enough. There is gold in them there hills, but it won't be easy to mine 22:07
pmichaud whiteknight: right, I agree
still, we're sometimes surprised by what profiling reveals :)
(which is what you started with :)
bacek: also, 3.3 is *not* 20% faster on 4G- boxes 22:08
whiteknight right. 6model was my priority. I'm going to push that back and work on profiling now instead
bacek pmichaud, "on building Rakudo"
pmichaud, core.pm test on plum :) 22:09
pmichaud bacek: github.com/pmichaud/rakbench/blob/...100844.txt # core.pm on 2GB kiwi
7% slower
bacek pmichaud, erm. core.pm is 40% faster. rx is 15%. 22:10
pmichaud on 3.3.0?
or 3.3.0+lots of patches that haven't been released yet?
bacek pmichaud, ah. yes.
whiteknight pmichaud: those three boxes you list, are those going to be available for a while? 22:11
pmichaud whiteknight: yes.
whiteknight if so, we could call those our gold standard boxes, and make them better
bacek whiteknight, I would like to some 32bits boxes as well
whiteknight ok
pmichaud github.com/pmichaud/rakbench/blob/...140653.txt # 4GB (actually 3.5GB)
bacek and non-linux
cotto I have a 32-bit laptop that just became mostly-idle 22:12
pmichaud 51% slower on 3.3.0. 0.8% slower on 3.3.0+patches
I can install 32-bit on my boxes and test them as well.
bacek: so it's not simply a function of memory that is making things faster/slower
soh_cah_toa i have plenty of machines i can test on. in fact, i already have been
bacek pmichaud, of course. But I was focusing on GC part. Which should get better. 22:13
whiteknight okay, let's make a goal of 10% improvement over 3.0.0 on *all* machines where we run benchmarks
I don't feel like 10% is impossible to do across the board
cotto 10% on what?
core.pm?
whiteknight yeah, core.pm seems the most painful
pmichaud I'll try to locate some suitable parrot-only or otherwise stable benchmarks that can be stable across all releases
rakudo has trouble fitting that bill because we can't get a modern rakudo to build on an old parrot, or vice-versa 22:14
the benchmark that is most useful/representative at this point (for Rakudo users) is the "coretest" benchmark
it's a set of unchanged spectests across all releases tested
bacek whiteknight, nope. core.pm doesn't represent load from perl6 runtime. We need core.pm and commontest (at least) 22:15
pmichaud right, commontest (sorry)
whiteknight bacek: okay. 10% on that.
cotto commontest?
pmichaud in other words, it's the performance of rakudo on identical p6 programs over time (the programs are unchanged from, say, 2011.01 to present)
cotto ok
pmichaud and the p6 programs test many different features of Perl 6 22:16
kid51 We have 9 weeks and 3 days until Parrot 3.6 release. 22:17
bacek Plus we need examples/shootout/*.t 22:18
(from parrot)
kid51 Of the items discussed above, what can/must we deliver by July 17; what will have to be targeted for 3.9 (Oct 18)?
pmichaud bacek: should I time each individual shootout program, or the group collectively (or both?)
bacek pmichaud, "both" is best case. 22:19
pmichaud is there a preference between the two?
(if I need to choose one or other?)
bacek pmichaud, individual tests then.
pmichaud okay.
I'll start with that.
bacek Otherwise it's hard to catch regression in particular part of parrot due coarse granularity. 22:20
whiteknight The more benchmarks we can get, the better
pmichaud ...and rakbench makes it easy to select subsets of benchmarks and builds
whiteknight pmichaud: does rakbench accept submissions like smolder with test reports? 22:21
pmichaud whiteknight: no
and probably shouldn't
whiteknight ok
kid51 We ought to have a mechanism for responding (as a project) to any reported deterioration in performance discovered via benchmarking.
bacek whiteknight, github.com/tobami/codespeed/
pmichaud kid51: trac ticket, perhaps?
whiteknight bacek: looks promising
bacek I think we can install it somewhere and connect rakbench to it.
whiteknight, this is app behind speed.pypy.org. 22:22
kid51 pmichaud: That's a start ... but I'm talking about the human factors.
22:22 bluescreen joined
pmichaud kid51: my experience thus far is that performance degradations get quick attention when reported 22:22
bacek "Smolder" style submission interface, etc.
pmichaud (as they are right now)
still, I won't object to further process/structure for it, if others think it's needed/useful
bacek afk # looks like my kids going to destroy house 22:23
pmichaud (bacek's kids are garbage collecting, perhaps? :-)
(or perhaps they're generating garbage for him to collect :-)
whiteknight my kid generates tons of garbage
pmichaud kid51: sorry to have derailed your comment 22:24
kid51 pmichaud: I'm thinking of how Parrot leadership persuades Parrot devs to stop what they're doing when there's a deterioration in Rakudo or HLL performance 22:25
lucian_ is winxed stable enough across parrot versions?
22:25 lucian_ is now known as lucian
lucian conceivably, a test suite could be written in that 22:25
pmichaud kid51: I think that may lead into my "I think I have a solution to the deprecation breakage problem" remark from earlier, perhaps
lucian for benchmarks
kid51 Because the first objective of benchmarking is to prevent sliding backwards
pmichaud:proceed
pmichaud my thought is actually a resurrection of something that others (I think whiteknight and/or kid51) proposed, but I nixed and now realize I was likely wrong. 22:26
kid51 elaborate
pmichaud for problems relating to rakudo breakages, we probably need to designate point persons for the rakudo and parrot teams for "escalation" when problems arise
whiteknight what kinds of "problems" are we talking about? 22:27
pmichaud as I said, I nixed this before, but upon thinking about it with respect to recent issues, I think it would work
the last couple of paragraphs of my PDS gist is what I was thinking about
but that also fits with what kid51 just said, perhaps -- about "Parrot leadership persuades devs to stop what they're doing when there's a deterioration..." 22:28
where in this case, "point person" is someone "empowered to issue a 'stop and rethink' command that others know to pay attention to"
or something like that
kid51 Yes.
pmichaud I can elaborate further with an example, if that helps. 22:29
kid51 A customer relationship manager on the Parrot side. A vendor relationship manager on the HLL side.
elaborate
pmichaud let's consider the recent breakage on the random number generator for Rakudo
cotto I think any of me, whiteknight and kid51 could perform that role.
pmichaud (I'm choosing it because it's already resolved.) 22:30
cotto gets to serve as a bad example
pmichaud several people on the Rakudo team noticed that Parrot no longer generated random numbers as Rakudo expected it to
bacek is back 22:31
pmichaud they discussed it with various folks on Parrot, and came away with the sense that Parrot's position was "you have to solve this on your own, sorry it broke but it's not something we're going to fix on our end"
when I inquired about it on #perl6, that's what they told me -- basically "we're told it's not going to be changed back in Parrot"
then I came in, had a brief discussion with cotto++, and he agreed that it needed to be fixed
it got fixed, which is good
the part that is bad is the bad feeling that developed from the rakudo devs feeling that their needs were rejected by whatever Parrot devs they were talking to 22:32
*that's* where our frustration arises
cotto That's what we need to avoid.
pmichaud there's another case that is currently ongoing (the 't' deprecation)
but the significant factor is that sometimes the Rakudo devs feel that the Parrot team doesn't credit us for already trying to solve the problem on our own before coming to Parrot for help 22:33
whiteknight I've been playing the role of project manager, so that seems like a job I should volunteer for.
pmichaud (that may or may not be the truth of what is happening, but that's the perception on our end)
whiteknight being told that it wasn't parrot's problem is absolutely not what should have happened
pmichaud so, we ask for help, and we're often told "you need to go fix things on your end first"
or "everything you need is in this ticket" (that in fact we've already looked at and have decided isn't sufficient for us to solve our problem) 22:34
cotto I think that part of the problem was that the response didn't represent a well-thought-out consensus, but the thoughts of whoever happened to be in #parrot at the time.
pmichaud cotto: exactly
so, relationship managers help to solve that
whiteknight maybe the strategy should be to come to a point person first, instead of just chatting about problems in #parrot
pmichaud so when a rakudo dev feels stonewalled by #parrot, they go to the relationship manager (for Rakudo) who communicates "this is a real problem" to his counterpart and a stop-the-presses order can go forth 22:35
whiteknight the response you get in the chatroom is always going to be dependent on the people in attendance
pmichaud whiteknight: yes, I agree
I'm not sure that we should say *always* go to the point person
cotto I like it.
kid51 There's a cultural problem here.
pmichaud because that introduces synchronization dependencies
whiteknight pmichaud: I like that idea. Do you want to pick somebody you are comfortable with, or do you want us to self-select?
cotto The point person is a good second point of contact if #parrot doesn't work out.
pmichaud but if we simply say "if you feel like you're not getting the answers you want, there's a recourse" 22:36
kid51 The Parrot project inherently attracts "internals guys"
... and "internals guys" tend to have different interests from HLL people, who are of necessity more outwardly-focused.
pmichaud if we know there's a recourse and that there is a person empowered to take a higher-level view decision (and make it stick), then I think we'll be happy with that
for example, part of my frustration with the 't' deprecation is that there's only one person that seems to be discussing it on the mailing list from the Parrot side, and he's starting to make claims about Parrot positions that aren't consistent with other things we've decided in the past 22:38
but since there's no designated person to "represent Parrot" (and nobody else from Parrot saying otherwise), it's frustrating.
cotto pmichaud, would you like to pick someone or have us self-select? 22:39
pmichaud self-select is fine
if that doesn't work, I'll let you know, but I think I'm quite comfortable with any of the people present
cotto great
nominations/volunteers?
pmichaud also, from my side I might need to designate two representatives, simply because my availability is sometimes out of my control 22:40
mikehh would it help to have a weekly meeting between HLL and parrot devs something like #ps
cotto a lot can happen in a week
whiteknight I would definitely like to take this role, at least in part 22:41
kid51 whiteknight: I think you would be good at this from the Parrot side ... but it would mean redirecting some of your time/energy away from more internally focussed stuff.
whiteknight a second person to increase availability would be nice
cotto I'll do that.
pmichaud +1 to having two people 22:42
two is sufficient, and I'm certain that two can work it out
cotto pmichaud, can you make sure that the Rakudo hackers know about this?
kid51 Or I could ... at least from the "sounding the alarm" point of view. (I don't think people would listen to me saying "stop the presses".)
pmichaud I'm hoping it won't be a huge time/energy sink (more)
cotto I don't think it will be either.
pmichaud also, from our perspective the panic is generally not a "XYZ broke and it has to be fixed NOW" 22:43
the panic for us is when "XYZ broke and people are telling us it will never be fixed"
as long as we know a resolution is being worked on / likely, we can live with that 22:44
so it's only "stop the presses" in the sense of "Parrot cannot let this continue into its next release"
PerlJam .
pmichaud and to get back to kid51's original point, I think "performance regression" can be treated the same way, if it's serious enough
cotto In general, I feel like the urgency of problems has been effectively communicated. 22:45
kid51 It seems that there are two classes of problems which these relationship managers need to be able tohandle ... 22:46
1. This change in Parrot broke the HLL
pmichaud (and yes, I will be sure to pass the word along to the Rakudo devs)
kid51 2. We've been observing a deterioration in our performance that may be due to Parrot
pmichaud to me they're roughly the same class of problem 22:47
because at least for Rakudo today, a significant deterioration of performance is a form of breakage (i.e., our customers lose faith in our product) 22:48
a long term trend of reduction in performance will show up in the rakbench stuff I'm producing
I intend to comparatively benchmark every monthly release
for now, 2011.01 is our "baseline"
for one, it's the fastest that we have yet 22:49
as we get to later in 2011, I may update the baseline to be 2011.04 - a la a sliding window
anyway, monthly releases then become our official benchmarks showing performance changes over time
bacek pmichaud, can you start benchmarking few days _before_ release? Otherwise we can't fix performance regressions in release. 22:50
pmichaud bacek: sure, can do that also 22:51
bacek pmichaud, thanks!
pmichaud you already see that to some extent with rakudo-master and rakudo-bleed
rakudo continues to be heavily focused on "how do we make things faster", so the rakbench reports are becoming almost daily tools
bacek pmichaud, I have to revert some of GC improvements commits. They broke win32 somehow :(
pmichaud bacek: understood
bacek pmichaud, rakudo-really-bleed should get some performance back :) 22:53
pmichaud rakudo-master is rakudo head with its preferred version of parrot master. rakudo-bleed is rakudo head with parrot head
cotto It sounds like this is more or less resolved.
pmichaud +1
kid51 In order to move this discussion, can we formulate this as a PDS policy decision: 'The Parrot project will collaborate with HLLs to develop ways of benchmarking the performance of the HLLs as targeted to monthly Parrot releases." 22:54
pmichaud kid51: definitely works for me
cotto kid51, that should only apply to hlls that can deal with the potential for breakage that happens during the release cycle 22:55
pmichaud rakbench may be very easy to adapt to other HLLs, fwiw
it's basically a glorified "run these releases on these scripts and capture the output of /usr/bin/time" thingy :)
cotto (Rakudo, of course, does)
pmichaud I'd say the policy applies to whatever HLLs want to participate at that level 22:56
at least, until it becomes burdensome for parrot, at which point we update the policy
cotto yes
we'll react as needed
kid51 How about this? "The Parrot project will collaborate with HLLs to develop ways of benchmarking the performance of the HLLs as targeted to monthly Parrot releases and the expressed needs of those HLLs." 22:57
pmichaud also +1 from me
kid51 So I have two questions at this point:
cotto kid51, +1 to that statement 22:58
kid51 Should Parrot form a team specifically for this? And what resources can we throw at profiling?
cotto It sounds like whiteknight and I will be on profiling
pmichaud if we can just get the existing profiler to somehow be more reliable (or understand when/how its "odd numbers" are being produced), then that can be sufficient. 22:59
it may be that kcachegrind/valgrind simply can't handle CPS-style profiling
cotto It's not entirely clear how many layers of yaks lie that way.
pmichaud agreed.
fwiw, I'm fine with that being a 3.9 or even 4.0 goal 23:00
cotto We'll be finding out.
pmichaud the quick-and-dirty one I put together last night ought to be enough to get us through the next few months
cotto pmichaud, is it accessible somewhere?
pmichaud cotto: it's dreadfully simple
I added an opcode that when run outputs the identity of the current sub and its caller to a logfile
then I configured Rakudo to add that opcode near the beginning of every sub 23:01
so, we get call counts
cotto ok
pmichaud we don't get any idea of how long each sub takes, but we have other ways of measuring that if we need to
anyway, the code is in src/core/perl6.ops, the log analysis is in tools/sublog-report.pl 23:02
look for x_enter_sublog opcode
cotto thanks
kid51, what's your other question? 23:03
kid51 Well, it's time to get concrete re Roadmap Goals and Teams
pmichaud I've been thinking of changing that to simply x_sublog and x_sublog_i opcodes (the _i would allow an integer marker to distinguish different types of events to be logged)
kid51 Given that we have only 9 weeks to 3.6 ...
... I'd be happy if we limited Roadmap Goals to 1 or 2, each with at least 2 members. 23:04
bacek voting for profiling
kid51 And of all the things discussed here, profiling looks like the one where we have to collectively push ourselves to get something done
cotto I agree. 23:05
bacek I'll try couple of ideas to speedup GC and PCC a bit.
kid51 We can "continue at same pace" for GC, deprecations as data, M0
pmichaud +1 to all of above
kid51 It's mostly a question of focus.
pmichaud those sound like sufficient and achievable goals to me
kid51 Who knows what profiling tools we currently have? (I don't.) 23:06
What improvements can we make in them by mid-July? What by mid-October?
Who knows how to do that?
bacek But don't expect much from algorithmic improvements of GC. It's limited by design of PMC.
cotto Yup. No copying/compacting for us for now. 23:07
kid51 Or, more concretely, ...
cotto but there are other wins
kid51 whiteknight and cotto: If you are going to focus on profiling, what can the 2 of you accomplish by each of those dates?
(and, what doesn't get done if you shift your focus in that direction?)
pmichaud (I have suggestion if needed) 23:08
cotto I'll be continuing M0 work, which requires more thinking than coding. I don't think I'll be giving up a lot else in this case.
kid51 whiteknight? 23:09
cotto pmichaud, ?
pmichaud by 3.6, have looked a bit at the existing profiling runcore and decided if it+kcachegrind will work out
or if parrot needs a much larger approach
s/much larger/different/
(doesn't have to be larger)
cotto Its original intent was to work with kcachegrind, and to a limited extent it does. 23:10
pmichaud right
it's very close to working out, if only we can find out why it gives nonsensical results in some areas
cotto It also has tests, so there's the potential to add test cases for bugs that are dug up.
yes 23:11
pmichaud if we simply knew the bounds of the existing profiler, that's a good achievement
cotto The most valuable thing for it is tests that don't profile correctly.
pmichaud I gave one in my january pds email :)
cotto great 23:12
pmichaud I think I was profiling the opsc compiler
(so it's even parrot-specific :-)
anyway, if a larger goal is wanted, then have something that is "usable" (doesn't have to be perfect) by 3.9 23:13
cotto Can you tighten "usable"?
kid51 How about this for a statement?
pmichaud or, I should say, more usable than kcachegrind+profiling runcore
kid51 Parrot project will establish a team to pursue goal of better profiling. By 3.6 we will have studied our existing profiling tools, determined their strengths and limitations and developed a plan for significant improvements in later supported releases.
pmichaud mainly what Rakudo would want is to know the callgraph and time spent in each sub
"time spent" can be instruction counts, though, instead of wall counts 23:14
*wall-clock
kid51: that statement works for me
cotto alright
pmichaud (but since I'm not on the team, whether it works for me is not completely relevant :)
(the team for that goal, that is) 23:15
kid51 How does this work as a statement of our resolutions coming from this Summit? 23:17
nopaste.snit.ch/45564
mikehh pmichaud: I think we can say that you have contributed a lot to parrot
bacek is have to go. Will backlog.
pmichaud mikehh: I have no doubt about that :)
mikehh and anything you have to say is completely relevant 23:18
pmichaud mikehh: I simply meant that since I'm not the one that will have to do the work, whether I agree with the task should be reduced accordingly
i.e., the ones who commit to doing the work should get a stronger vote than those who sit on the sidelines and say "yeah! go!"
cotto kid51, thanks 23:19
pmichaud kid51: those look great to me. I plan to elaborate on the last item in a message to perl6-compiler (which can be cross-posted to parrot-dev if that turns out to be appropriate)
actually, I'll write the message with the intention that it be cross-posted. It would help if at some point a parrot person can confirm or present the parrot view of things. 23:20
Or, I'll draft an elaboration, and consult with the parrot reps to make it into a joint statement of our intent
kid51 Good.
23:21 benabik joined
pmichaud I should be able to draft something tomorrow-ish 23:21
(might be monday depending on events around the house)
kid51 Of the 3 policy items, two are more modifications of the way we do things.
But the profiling focus is new. It ought to be a Roadmap Goal and have a designated team.
cotto: Are you willing to be on a profiling team? 23:22
pmichaud actually, benchmarking is relatively new as well
cotto kid51, sure
pmichaud we didn't start doing that until about 10 days ago, at least not in any formalized sense
kid51 pmichaud: It's new as a practice, but probably doesn't require much new Parrot code.
profiling probably needs new parrot code.
pmichaud kid51: Parrot code, perhaps not, but infrastructure, a little.
parrot is more than just its code. (perhaps goals reflect only Parrot code, though) 23:23
kid51 Yes, infrastructure. Which gives me an incentive to get better machines.
pmichaud anyway, I'm planning to continue building the benchmarking infrastructure; that can be listed as a goal or whatever from PDS as you deem appropriate
kid51 Who wants to work with cotto on improving Parrot's profiling?
cotto kid51, whiteknight already indicated that he would 23:24
kid51 Anyone else? This could use a 3rd.
kid51 thinks whiteknight is afk
cotto seems like it
kid51 we have lots of people on channel who have not spoken up 23:25
Now's the time!
mikehh I acn always help with testing things and that sort of stuff
can
kid51 Any reflections from GSOCers on this summit?
mikehh: Me too. Incentive to get better machines. 23:26
pmichaud I might suggest that anyone reading this log post-summit should feel free to comment about the summit in channel?
i.e., just add your comments even after the summit is "complete"? It'll be logged on the parrotsketch log (and someone will undoubtedly see it)
mikehh there is always the prospect of testing on remote machines
kid51 pmichaud: agreed 23:27
My impression is that, after 2.5 hours, we've touched on major issues and people's attention is going elsewhere. 23:28
We actually touched on Agenda Item IV.A. without directly doing so: functioning of parrot project. 23:29
soh_cah_toa i'm still listening. though most was out of my league :)
kid51 We can defer GSOC discussion until weekly parrotsketch.
cotto +!
+1
kid51 I move we adjourn.
pmichaud wfm 23:30
cotto Any last issues?
pmichaud cotto: would you have a moment to discuss the 't' issue in #parrot before we depart?
cotto pmichaud, sure
pmichaud thanks
23:31 contingencyplan joined
pmichaud also, thanks to kid51 and others for organizing and participating in the summit. I feel we accomplished a lot today. 23:31
cotto yes, thanks
kid51++
kid51 Thanks.
soh_cah_toa yes, very organized and professional
kid51 Okay, that's a wrap. Other than logging post-summit impressions, take discussions to #parrot or off-channel.
23:32 kid51 left 23:33 bubaflub left, soh_cah_toa left 23:41 contingencyplan left 23:49 benabik left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!