Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2011-05-14

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

All times shown according to UTC.

Time Nick Message
00:00 lucian left #parrotsketch
00:44 bacek joined #parrotsketch
00:48 whiteknight left #parrotsketch
00:50 whiteknight joined #parrotsketch
00:56 whiteknight left #parrotsketch
00:56 whiteknight joined #parrotsketch
01:52 wagle left #parrotsketch
01:55 wagle joined #parrotsketch
01:56 ShaneC left #parrotsketch
02:40 whiteknight left #parrotsketch
06:57 contingencyplan joined #parrotsketch
09:30 contingencyplan left #parrotsketch
11:09 whiteknight joined #parrotsketch
13:12 lucian joined #parrotsketch
15:02 contingencyplan joined #parrotsketch
15:24 whiteknight left #parrotsketch
15:27 whiteknight joined #parrotsketch
15:39 bluescreen joined #parrotsketch
15:40 mariano joined #parrotsketch
15:41 bluescreen_ joined #parrotsketch
15:45 bluescreen__ joined #parrotsketch
15:46 bluescreen__ left #parrotsketch
15:46 mariano left #parrotsketch
15:46 bluescreen__ joined #parrotsketch
16:07 lucian_ joined #parrotsketch
16:12 lucian left #parrotsketch
16:14 lucian joined #parrotsketch
16:14 lucian_ left #parrotsketch
16:18 lucian_ joined #parrotsketch
16:18 lucian left #parrotsketch
16:21 bluescreen__ left #parrotsketch
16:22 bluescreen__ joined #parrotsketch
16:23 bluescreen left #parrotsketch
16:23 bluescreen_ left #parrotsketch
16:23 bluescreen__ left #parrotsketch
17:05 contingencyplan left #parrotsketch
19:01 soh_cah_toa joined #parrotsketch
19:24 pmichaud joined #parrotsketch
19:28 bubaflub joined #parrotsketch
20:32 plobsing joined #parrotsketch
20:46 soh_cah_toa left #parrotsketch
20:49 soh_cah_toa joined #parrotsketch
20:51 dukeleto joined #parrotsketch
20:51 * dukeleto waves
20:52 * tadzik waves too
20:54 pmichaud I wanted to post to parrot-dev but m/l issues are likely to make it late, so I'm nopasting instead:
20:56 pmichaud http://gist.github.com/972619http://gist.github.com/972625
20:56 pmichaud oops
20:56 pmichaud http://gist.github.com/972625
20:57 kid51 joined #parrotsketch
21:00 dukeleto hola
21:00 cotto hello
21:00 pmichaud for those coming in just now and didn't catch it -- my preliminary notes for PDS are at http://gist.github.com/972625
21:02 bubaflub hello
21:02 dukeleto PDS meeting agenda is here: http://nopaste.snit.ch/45279
21:02 soh_cah_toa yay, pds now!
21:04 pmichaud (I have to run a quick errand -- bbi15)
21:05 cotto For the record, our roadmap goals were listed in this thread: http://groups.google.com/group/parrot-dev/browse_thread/thread/2c578e901b2c911d/44a5660c2e531e92?show_docid=44a5660c2e531e92
21:05 dukeleto so where is this train headed?
21:06 dukeleto any other gsoc students hiding?
21:06 cotto deprecations as data, imcc isolation, M0 spec
21:06 soh_cah_toa dukeleto: i'm here
21:07 kid51 Re: roadmap goals from last summit
21:07 kid51 In March, I solicited feedback on them both on parrot-dev and in personal communications with other key developers.
21:08 kid51 My recollection of the feedback was:
21:08 kid51 1. Deprecations as data: Substantially met.  Indeed, met so soon after PDS that it perhaps needn't have been a Roadmap Level goal.
21:09 kid51 2. IMCC isolation:  A lot of effort by whiteknight et al.  I hope whiteknight can describe status better.
21:09 kid51 3. M0:  Substantial progress only in last 4 weeks.
21:10 kid51 whiteknight: Can you describe status of IMCC isolation?
21:10 whiteknight sure
21:10 whiteknight It was a little bit of a bumpy road, but the state of IMCC is much better now than it was
21:10 dukeleto soh_cah_toa++ # excited and diligent gsoc students
21:11 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?
21:11 whiteknight we can run libparrot without ever initializing or using IMCC, and it's feasible that we can build libparrot completely without imcc
21:12 whiteknight at the moment, there are no urgent next steps.
21:12 kid51 Thanks.
21:12 kid51 dukeleto: Any next steps for deprecations as data?
21:12 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
21:12 dukeleto kid51: yes. I would like to have a web-based frontend for deprecations
21:13 kid51 Can you describe that?  Is it a "nice to have" or a "must have"?
21:13 dukeleto kid51: for example...
21:14 dukeleto 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)
21:15 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
21:15 kid51 And do we currently have tools that do that (web interface or otherwise)?
21:16 dukeleto tools/dev/(dedeprecator,show_deprecations.nqp,show_experimental.nqp)
21:16 dukeleto kid51: no, we don't. And I think that is something that should change.
21:16 dukeleto kid51: we need to improve the flow of information from HLLs to Parrot core and vice versa
21:16 pmichaud (are we taking comments on the next steps or simply identifying them now?)
21:16 kid51 dukeleto: To be honest, I was completely unaware of the existence of those programs
21:17 kid51 pmichaud: No, we're reviewing what was done on Roadmap Goals since last PDS
21:17 dukeleto kid51: life moves fast :)
21:17 kid51 cotto: Current status of M0?
21:17 cotto more detailed M0 status - https://gist.github.com/972649
21:17 pmichaud kid51: I ask because your question was "Any next steps...?"  and I have some questions/comments
21:17 pmichaud it can wait
21:18 kid51 pmichaud: I know. We'll get to you :-)
21:18 bacek ~~
21:18 pmichaud (specifically, I have questions/comments about dukeleto's next steps :-)
21:18 pmichaud (silencing)
21:18 kid51 pmichaud: Yes, but that will come in a few.
21:19 * 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
21:20 kid51 So, my impression is that substantial work was done on all 3 Roadmap Goals ...
21:20 dukeleto kid51: indeed
21:20 cotto yes
21:20 kid51 ... but in each area there are substantial next steps.
21:21 kid51 If so, then can we review what was done since last PDS that was *not* in Roadmap Goal context?
21:21 kid51 Example, bacek et al work on GC?
21:21 * dukeleto estimates roughly 2 weeks to a done-enough M0 assembler to shake out any remaining holes in the M0 spec
21:22 dukeleto 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
21:22 pmichaud my comment is about the deprecation-on-web thingy
21:22 kid51 bacek: ping
21:22 bacek kid51, pong
21:23 * bacek is still trying to wake up.
21:23 dukeleto pmichaud: ah. well, i would like to hear that as well :)
21:23 dukeleto pmichaud: go for it, give bacek++ time to wake himself
21:23 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).
21:24 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)
21:24 dukeleto pmichaud: people get their axes when anybody attempts to send automated smoker/etc email to parrot-dev
21:24 pmichaud parrot-dev, and/or the mailing list of the thing being checked for deprecation
21:25 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
21:25 pmichaud even once per week ought to be sufficient
21:25 dukeleto pmichaud: parrot-dev simply won't work. People will have torches at your (or my) door.
21:25 pmichaud make a separate deprecations list that people can subscribe to
21:25 pmichaud I'm simply saying "look it up on the web" is likely to be ignored
21:25 pmichaud or forgotten
21:25 dukeleto pmichaud: emails can be sent from the software
21:25 pmichaud feel free to ignore my suggestion and do whatever you think is best
21:25 kid51 pmichaud: Agreed.  It would suffer from wiki-like bitrot
21:26 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
21:26 cotto I like active notification via email, but web apps can do that too.
21:26 dukeleto pmichaud: i appreciate your positive encouragement
21:27 kid51 As for non-Roadmap stuff, ...
21:28 kid51 ... last time around ...
21:28 pmichaud kid51: instead of "failed to do"  i prefer "haven't achieved yet"  :)
21:28 bacek dukeleto, I prefer ttbot for broken builds. It much less annoying but still highly visible.
21:28 kid51 ... we got a list of rakudo's needs, in part during the PDS and in part in the following days.
21:28 kid51 So, technically, they were'nt on the roadmap.
21:29 kid51 And I suspect that we will have to put them on the roadmap.
21:29 kid51 But, for right now, pmichaud, do you have anything to add to your comments in gist?
21:30 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.
21:31 kid51 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?
21:32 pmichaud 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.
21:32 whiteknight we don't have any benchmarks that really duplicate Rakudo's performance profile
21:32 pmichaud whiteknight: yes, thus my question.
21:32 whiteknight pmichaud: it is an invaluable source of data, although not the only one we have
21:32 pmichaud agreed, but still not an answer to my question
21:33 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.
21:33 kid51 Yes
21:33 pmichaud because that has implications for rakudo's release/dependency cycle
21:34 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 ...
21:34 pmichaud it has been suggested again today (on the mailing list) that rakudo should be targeting something other than parrot head
21:34 pmichaud if rakudo chooses to target only supported releases, then performance benchmarking isn't really possible
21:35 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.
21:35 pmichaud whiteknight: false.
21:35 whiteknight so, if we want Rakudo performance to increase, we need it as a regulra benchmark
21:35 pmichaud the benchmarks we did this past month are almost exclusively Parrot performance.
21:36 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 whiteknight the last round is just one of many to consider
21:36 pmichaud I'm not following where you're leading.
21:36 pmichaud s/following/understanding/
21:37 pmichaud perhaps it's not important
21:37 pmichaud anyway, that's my question, I don't know that it needs resolution in this meeting.
21:37 bacek How hard is to setup infrastructure similar to speed.pypy.org?
21:38 dukeleto bacek: it is time and energy to set it up and not difficulty
21:39 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
21:39 pmichaud Still, not directly addressing my question.
21:39 dukeleto pmichaud: i was not attempting to address your question
21:39 pmichaud fair enough.
21:40 pmichaud (my comment was in response to bacek, fwiw)
21:40 whiteknight pmichaud: I'm not sure I am clear what your question is
21:40 pmichaud will parrot be relying on Rakudo (at all) for (any of) its performance measurements going forward?
21:41 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
21:41 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.
21:41 bacek pmichaud, from my point of view - yes, we'll use it.
21:41 pmichaud and if yes, does that mean that we expect Rakudo to be continue to target something more frequent than individual parrot releases?
21:41 whiteknight we will be able to focus our optimization efforts on what Rakudo needs if we are benchmarking regularly against Rakudo
21:41 dukeleto bacek: we could run a benchmark suite on the OSL supercell vm cluster
21:42 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"
21:42 whiteknight if Rakudo works against Parrot head, we benchmark the pair more frequently
21:42 whiteknight if not, we benchmark less frequently
21:42 cotto pmichaud, I think the best answer is that we'll support Rakudo's attempts to run against master.
21:43 pmichaud cotto: thank you.
21:43 whiteknight yes, what cotto says
21:43 whiteknight (my ability to explain what I am thinking is poor today)
21:43 pmichaud that answers my question(s)
21:45 kid51 Do we have any more to discuss under 'I' of the agenda posted here:  http://nopaste.snit.ch/45279?tx=on&submit=Format+it! ?
21:46 pmichaud I wish to commend whiteknight++ on the imcc landing.  That was non-disruptive (and difficult to achieve).
21:46 pmichaud it was "non-disruptive" to Rakudo, and had a huge potential to be.
21:47 pmichaud so, fantastic work.
21:47 whiteknight being non-disruptive was the #1 priority
21:47 pmichaud you succeeded.
21:47 whiteknight thank you very much
21:47 kid51 whiteknight: how was non-disruptiveness achieved?
21:47 whiteknight kid51: identifying a stable interface, and testing the heck out of it
21:49 kid51 Are we ready to go on to Agenda item II?
21:50 pmichaud (I am ready.
21:50 pmichaud )
21:51 cotto sure
21:51 kid51 Hearing no objection ....
21:51 cotto The closest conference I know of to July 19 is OSCON, which goes from the 25th to the 29th.
21:51 kid51 I'm recommending that we set date for our next summit now, lest we forget about it later in meeting.
21:51 pmichaud FOSSCON is in Philadelphia on July 23 (I'm tentatively attending)
21:52 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.
21:52 pmichaud at any rate, I don't have an expected conflicts for the 30th-31st
21:52 whiteknight Those dates work fine for me
21:52 pmichaud *any
21:53 bacek Any date should work for me.
21:53 cotto I also don't see any conflict.
21:53 kid51 Do we then have a consensus that the next PDS will be held on either July 30 or 31?  (Exact time TBD)
21:54 whiteknight yes, let's set it for that weekend, we'll pick the time with doodle or whatever
21:54 cotto +1
21:54 pmichaud +0.5   # my attendance is less weighty than others'
21:54 kid51 Okay, so now we can proceed to Agenda Item III
21:54 mikehh joined #parrotsketch
21:54 cotto any volunteers to send the doodle?
21:55 pmichaud I volunteer cotto, since he's experienced at doodling.  :)
21:55 cotto sigh
21:55 bacek cotto, if you have to ask :)
21:55 * cotto will doodle
21:55 whiteknight cotto: let me take it this time
21:55 pmichaud (is it a lot of work?)
21:55 whiteknight We need to raise the bus number
21:55 cotto whiteknight, even better
21:55 cotto pmichaud, not really
21:55 pmichaud okay
21:55 bacek afk a bit
21:56 pmichaud on to III when others are ready
21:56 whiteknight I'll look at that later tonight
21:56 cotto sure
21:56 kid51 My general belief ...
21:56 kid51 ... is that in this quarter (and probably the next) ...
21:57 kid51 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 kid51 Which means elevating some of the concerns raised by pmichaud to Roadmap Goal status and forming teams to work on them.
21:58 kid51 Which further means that getting work done in those areas takes precedence over, say, extending work on other areas.
21:58 kid51 That's my general feeling.
21:59 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
21:59 cotto I was just thinking that I need to make that a roadmap goal.
21:59 whiteknight that appears to be a huge area of concern for Rakudo where nobody else is currently working
21:59 cotto (referring to what whiteknight said)
21:59 whiteknight I was really hoping we would have a GSoC student on that project, but that didn't pan out
22:00 cotto She tried, but not hard enough, so here we are
22:00 whiteknight right
22:00 cotto sounds like whiteknight and I are volunteering.  Any others?
22:00 whiteknight beyond that, reading through pmichaud's message, it looks like general optimizations are the name of the game
22:00 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)
22:01 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"
22:01 whiteknight and we hit that milestone by whatever means necessary
22:01 bacek whiteknight, heh. On what kind of box?
22:01 whiteknight bacek: any box. Lots of hand-waving
22:01 cotto valgrind?
22:02 cotto 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
22:02 bacek whiteknight, 3.3 is 20% faster than 3.0 on 4G- boxes.
22:02 whiteknight bacek: on pmichaud's box
22:02 kid51 :)
22:03 cotto whiteknight, nice
22:03 bacek whiteknight, 8G, 64bits? Lets rewrite PCC from scratch.
22:03 whiteknight kid51: a percentage performance improvement is hardly something that we can ever guarantee
22:03 whiteknight bacek: don't tempt me. I *will* rewrite PCC eventually
22:03 bacek I can probably increase GMS performance a bit, but this box isn't memory bounded.
22:03 whiteknight I would start on it tomorrow, if profiling weren't a bigger need
22:04 whiteknight 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"
22:04 pmichaud also, rakbench can easily accommodate pure Parrot benchmarks, if we wish to add some.
22:04 whiteknight if we can get teams dedicated to each of those three things, I think we can call that a roadmap
22:04 bacek I think I can improve current PCC a bit without total redesign. But "C-to-PIR" calls and MMD are way too complex.
22:04 whiteknight unless there are other things people want to get devoted to
22:05 whiteknight 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
22:05 whiteknight MMD is trickly only because we need to preserve semantics
22:05 pmichaud s/no 6model/on 6model/
22:06 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)
22:06 bacek whiteknight, MMD is tricky because of :flat
22:06 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
22:07 whiteknight 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
22:07 pmichaud still, we're sometimes surprised by what profiling reveals :)
22:07 pmichaud (which is what you started with :)
22:08 pmichaud 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
22:08 bacek pmichaud, "on building Rakudo"
22:09 bacek pmichaud, core.pm test on plum :)
22:09 pmichaud bacek: https://github.com/pmichaud/rakbench/blob/master/results/kiwi-x86_64-201105100844.txt   # core.pm on 2GB kiwi
22:09 pmichaud 7% slower
22:10 bacek pmichaud, erm. core.pm is 40% faster. rx is 15%.
22:10 pmichaud on 3.3.0?
22:10 pmichaud or 3.3.0+lots of patches that haven't been released yet?
22:10 bacek pmichaud, ah. yes.
22:11 whiteknight pmichaud: those three boxes you list, are those going to be available for a while?
22:11 pmichaud whiteknight: yes.
22:11 whiteknight if so, we could call those our gold standard boxes, and make them better
22:11 bacek whiteknight, I would like to some 32bits boxes as well
22:11 whiteknight ok
22:11 pmichaud https://github.com/pmichaud/rakbench/blob/master/results/orange-x86_64-201105140653.txt # 4GB  (actually 3.5GB)
22:11 bacek and non-linux
22:12 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
22:12 pmichaud I can install 32-bit on my boxes and test them as well.
22:12 pmichaud bacek: so it's not simply a function of memory that is making things faster/slower
22:12 soh_cah_toa i have plenty of machines i can test on. in fact, i already have been
22:13 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
22:13 whiteknight I don't feel like 10% is impossible to do across the board
22:13 cotto 10% on what?
22:13 cotto core.pm?
22:13 whiteknight yeah, core.pm seems the most painful
22:13 pmichaud I'll try to locate some suitable parrot-only or otherwise stable benchmarks that can be stable across all releases
22:14 pmichaud 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 pmichaud the benchmark that is most useful/representative at this point (for Rakudo users) is the "coretest" benchmark
22:14 pmichaud it's a set of unchanged spectests across all releases tested
22:15 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)
22:15 whiteknight bacek: okay. 10% on that.
22:15 cotto commontest?
22:15 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)
22:15 cotto ok
22:16 pmichaud and the p6 programs test many different features of Perl 6
22:17 kid51 We have 9 weeks and 3 days until Parrot 3.6 release.
22:18 bacek Plus we need examples/shootout/*.t
22:18 bacek (from parrot)
22:18 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)?
22:18 pmichaud bacek: should I time each individual shootout program, or the group collectively (or both?)
22:19 bacek pmichaud, "both" is best case.
22:19 pmichaud is there a preference between the two?
22:19 pmichaud (if I need to choose one or other?)
22:19 bacek pmichaud, individual tests then.
22:19 pmichaud okay.
22:19 pmichaud I'll start with that.
22:20 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
22:20 pmichaud ...and rakbench makes it easy to select subsets of benchmarks and builds
22:21 whiteknight pmichaud: does rakbench accept submissions like smolder with test reports?
22:21 pmichaud whiteknight: no
22:21 pmichaud and probably shouldn't
22:21 whiteknight ok
22:21 kid51 We ought to have a mechanism for responding (as a project) to any reported deterioration in performance discovered via benchmarking.
22:21 bacek whiteknight, https://github.com/tobami/codespeed/
22:21 pmichaud kid51: trac ticket, perhaps?
22:21 whiteknight bacek: looks promising
22:21 bacek I think we can install it somewhere and connect rakbench to it.
22:22 bacek 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 #parrotsketch
22:22 pmichaud kid51: my experience thus far is that performance degradations get quick attention when reported
22:22 bacek "Smolder" style submission interface, etc.
22:22 pmichaud (as they are right now)
22:22 pmichaud still, I won't object to further process/structure for it, if others think it's needed/useful
22:23 bacek afk # looks like my kids going to destroy house
22:23 pmichaud (bacek's kids are garbage collecting, perhaps? :-)
22:23 pmichaud (or perhaps they're generating garbage for him to collect :-)
22:23 whiteknight my kid generates tons of garbage
22:24 pmichaud kid51:  sorry to have derailed your comment
22:25 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
22:25 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
22:25 lucian for benchmarks
22:25 kid51 Because the first objective of benchmarking is to prevent sliding backwards
22:25 kid51 pmichaud:proceed
22:26 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
22:26 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
22:27 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
22:27 pmichaud the last couple of paragraphs of my PDS gist is what I was thinking about
22:28 pmichaud 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 pmichaud where in this case, "point person" is someone "empowered to issue a 'stop and rethink' command that others know to pay attention to"
22:28 pmichaud or something like that
22:28 kid51 Yes.
22:29 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.
22:29 kid51 elaborate
22:29 pmichaud let's consider the recent breakage on the random number generator for Rakudo
22:29 cotto I think any of me, whiteknight and kid51 could perform that role.
22:30 pmichaud (I'm choosing it because it's already resolved.)
22:30 * cotto gets to serve as a bad example
22:30 pmichaud several people on the Rakudo team noticed that Parrot no longer generated random numbers as Rakudo expected it to
22:31 * 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"
22:31 pmichaud 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"
22:31 pmichaud then I came in, had a brief discussion with cotto++, and he agreed that it needed to be fixed
22:31 pmichaud it got fixed, which is good
22:32 pmichaud 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 pmichaud *that's* where our frustration arises
22:32 cotto That's what we need to avoid.
22:32 pmichaud there's another case that is currently ongoing (the 't' deprecation)
22:33 pmichaud 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.
22:33 pmichaud (that may or may not be the truth of what is happening, but that's the perception on our end)
22:33 whiteknight being told that it wasn't parrot's problem is absolutely not what should have happened
22:33 pmichaud so, we ask for help, and we're often told "you need to go fix things on your end first"
22:34 pmichaud 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.
22:34 pmichaud cotto: exactly
22:34 pmichaud so, relationship managers help to solve that
22:34 whiteknight maybe the strategy should be to come to a point person first, instead of just chatting about problems in #parrot
22:35 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
22:35 pmichaud whiteknight: yes, I agree
22:35 pmichaud I'm not sure that we should say *always* go to the point person
22:35 cotto I like it.
22:35 kid51 There's a cultural problem here.
22:35 pmichaud because that introduces synchronization dependencies
22:35 whiteknight pmichaud: I like that idea. Do you want to pick somebody you are comfortable with, or do you want us to self-select?
22:35 cotto The point person is a good second point of contact if #parrot doesn't work out.
22:36 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"
22:36 kid51 ... and "internals guys" tend to have different interests from HLL people, who are of necessity more outwardly-focused.
22:36 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
22:38 pmichaud 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 pmichaud but since there's no designated person to "represent Parrot" (and nobody else from Parrot saying otherwise), it's frustrating.
22:39 cotto pmichaud, would you like to pick someone or have us self-select?
22:39 pmichaud self-select is fine
22:39 pmichaud if that doesn't work, I'll let you know, but I think I'm quite comfortable with any of the people present
22:39 cotto great
22:39 cotto nominations/volunteers?
22:40 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
22:40 cotto a lot can happen in a week
22:41 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.
22:41 whiteknight a second person to increase availability would be nice
22:41 cotto I'll do that.
22:42 pmichaud +1 to having two people
22:42 pmichaud two is sufficient, and I'm certain that two can work it out
22:42 cotto pmichaud, can you make sure that the Rakudo hackers know about this?
22:42 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".)
22:42 pmichaud I'm hoping it won't be a huge time/energy sink (more)
22:42 cotto I don't think it will be either.
22:43 pmichaud also, from our perspective the panic is generally not a "XYZ broke and it has to be fixed NOW"
22:43 pmichaud the panic for us is when "XYZ broke and people are telling us it will never be fixed"
22:44 pmichaud as long as we know a resolution is being worked on / likely, we can live with that
22:44 pmichaud so it's only "stop the presses" in the sense of "Parrot cannot let this continue into its next release"
22:44 PerlJam .
22:44 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
22:45 cotto In general, I feel like the urgency of problems has been effectively communicated.
22:46 kid51 It seems that there are two classes of problems which these relationship managers need to be able tohandle ...
22:46 kid51 1. This change in Parrot broke the HLL
22:46 pmichaud (and yes, I will be sure to pass the word along to the Rakudo devs)
22:46 kid51 2. We've been observing a deterioration in our performance that may be due to Parrot
22:47 pmichaud to me they're roughly the same class of problem
22:48 pmichaud 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 pmichaud a long term trend of reduction in performance will show up in the rakbench stuff I'm producing
22:48 pmichaud I intend to comparatively benchmark every monthly release
22:48 pmichaud for now, 2011.01 is our "baseline"
22:49 pmichaud for one, it's the fastest that we have yet
22:49 pmichaud as we get to later in 2011, I may update the baseline to be 2011.04 - a la a sliding window
22:49 pmichaud anyway, monthly releases then become our official benchmarks showing performance changes over time
22:50 bacek pmichaud, can you start benchmarking few days _before_ release? Otherwise we can't fix performance regressions in release.
22:51 pmichaud bacek: sure, can do that also
22:51 bacek pmichaud, thanks!
22:51 pmichaud you already see that to some extent with rakudo-master and rakudo-bleed
22:51 pmichaud rakudo continues to be heavily focused on "how do we make things faster", so the rakbench reports are becoming almost daily tools
22:51 bacek pmichaud, I have to revert some of GC improvements commits. They broke win32 somehow :(
22:51 pmichaud bacek: understood
22:53 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
22:53 cotto It sounds like this is more or less resolved.
22:53 pmichaud +1
22:54 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
22:55 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
22:55 pmichaud it's basically a glorified "run these releases on these scripts and capture the output of /usr/bin/time"  thingy :)
22:55 cotto (Rakudo, of course, does)
22:56 pmichaud I'd say the policy applies to whatever HLLs want to participate at that level
22:56 pmichaud at least, until it becomes burdensome for parrot, at which point we update the policy
22:56 cotto yes
22:56 cotto we'll react as needed
22:57 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
22:57 kid51 So I have two questions at this point:
22:58 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?
22:58 cotto It sounds like whiteknight and I will be on profiling
22:59 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 pmichaud it may be that kcachegrind/valgrind simply can't handle CPS-style profiling
22:59 cotto It's not entirely clear how many layers of yaks lie that way.
22:59 pmichaud agreed.
23:00 pmichaud fwiw, I'm fine with that being a 3.9 or even 4.0 goal
23:00 cotto We'll be finding out.
23:00 pmichaud the quick-and-dirty one I put together last night ought to be enough to get us through the next few months
23:00 cotto pmichaud, is it accessible somewhere?
23:00 pmichaud cotto: it's dreadfully simple
23:00 pmichaud I added an opcode that when run outputs the identity of the current sub and its caller to a logfile
23:01 pmichaud then I configured Rakudo to add that opcode near the beginning of every sub
23:01 pmichaud so, we get call counts
23:01 cotto ok
23:01 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
23:02 pmichaud anyway, the code is in src/core/perl6.ops, the log analysis is in tools/sublog-report.pl
23:02 pmichaud look for x_enter_sublog opcode
23:02 cotto thanks
23:03 cotto kid51, what's your other question?
23:03 kid51 Well, it's time to get concrete re Roadmap Goals and Teams
23:03 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)
23:03 kid51 Given that we have only 9 weeks to 3.6 ...
23:04 kid51 ... 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
23:04 kid51 And of all the things discussed here, profiling looks like the one where we have to collectively push ourselves to get something done
23:05 cotto I agree.
23:05 bacek I'll try couple of ideas to speedup GC and PCC a bit.
23:05 kid51 We can "continue at same pace" for GC, deprecations as data, M0
23:05 pmichaud +1 to all of above
23:05 kid51 It's mostly a question of focus.
23:05 pmichaud those sound like sufficient and achievable goals to me
23:06 kid51 Who knows what profiling tools we currently have?  (I don't.)
23:06 kid51 What improvements can we make in them by mid-July?  What by mid-October?
23:06 kid51 Who knows how to do that?
23:06 bacek But don't expect much from algorithmic improvements of GC. It's limited by design of PMC.
23:07 cotto Yup.  No copying/compacting for us for now.
23:07 kid51 Or, more concretely, ...
23:07 cotto but there are other wins
23:07 kid51 whiteknight and cotto:  If you are going to focus on profiling, what can the 2 of you accomplish by each of those dates?
23:07 kid51 (and, what doesn't get done if you shift your focus in that direction?)
23:08 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.
23:09 kid51 whiteknight?
23:09 cotto pmichaud, ?
23:09 pmichaud by 3.6, have looked a bit at the existing profiling runcore and decided if it+kcachegrind will work out
23:09 pmichaud or if parrot needs a much larger approach
23:09 pmichaud s/much larger/different/
23:09 pmichaud (doesn't have to be larger)
23:10 cotto Its original intent was to work with kcachegrind, and to a limited extent it does.
23:10 pmichaud right
23:10 pmichaud it's very close to working out, if only we can find out why it gives nonsensical results in some areas
23:10 cotto It also has tests, so there's the potential to add test cases for bugs that are dug up.
23:11 cotto yes
23:11 pmichaud if we simply knew the bounds of the existing profiler, that's a good achievement
23:11 cotto The most valuable thing for it is tests that don't profile correctly.
23:11 pmichaud I gave one in my january pds email :)
23:12 cotto great
23:12 pmichaud I think I was profiling the opsc compiler
23:12 pmichaud (so it's even parrot-specific :-)
23:13 pmichaud 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"?
23:13 kid51 How about this for a statement?
23:13 pmichaud or, I should say, more usable than kcachegrind+profiling runcore
23:13 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.
23:13 pmichaud mainly what Rakudo would want is to know the callgraph and time spent in each sub
23:14 pmichaud "time spent" can be instruction counts, though, instead of wall counts
23:14 pmichaud *wall-clock
23:14 pmichaud kid51: that statement works for me
23:14 cotto alright
23:14 pmichaud (but since I'm not on the team, whether it works for me is not completely relevant :)
23:15 pmichaud (the team for that goal, that is)
23:17 kid51 How does this work as a statement of our resolutions coming from this Summit?
23:17 kid51 http://nopaste.snit.ch/45564
23:17 mikehh pmichaud: I think we can say that you have contributed a lot to parrot
23:17 * bacek is have to go. Will backlog.
23:17 pmichaud mikehh: I have no doubt about that :)
23:18 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
23:18 pmichaud 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!"
23:19 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)
23:20 pmichaud 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 pmichaud Or, I'll draft an elaboration, and consult with the parrot reps to make it into a joint statement of our intent
23:20 kid51 Good.
23:21 benabik joined #parrotsketch
23:21 pmichaud I should be able to draft something tomorrow-ish
23:21 pmichaud (might be monday depending on events around the house)
23:21 kid51 Of the 3 policy items, two are more modifications of the way we do things.
23:21 kid51 But the profiling focus is new.  It ought to be a Roadmap Goal and have a designated team.
23:22 kid51 cotto: Are you willing to be on a profiling team?
23:22 pmichaud actually, benchmarking is relatively new as well
23:22 cotto kid51, sure
23:22 pmichaud we didn't start doing that until about 10 days ago, at least not in any formalized sense
23:22 kid51 pmichaud: It's new as a practice, but probably doesn't require much new Parrot code.
23:22 kid51 profiling probably needs new parrot code.
23:22 pmichaud kid51: Parrot code, perhaps not, but infrastructure, a little.
23:23 pmichaud 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.
23:23 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
23:23 kid51 Who wants to work with cotto on improving Parrot's profiling?
23:24 cotto kid51, whiteknight already indicated that he would
23:24 kid51 Anyone else?  This could use a 3rd.
23:24 * kid51 thinks whiteknight is afk
23:24 cotto seems like it
23:25 kid51 we have lots of people on channel who have not spoken up
23:25 kid51 Now's the time!
23:25 mikehh I acn always help with testing things and that sort of stuff
23:25 mikehh can
23:25 kid51 Any reflections from GSOCers on this summit?
23:26 kid51 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?
23:26 pmichaud 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)
23:26 mikehh there is always the prospect of testing on remote machines
23:27 kid51 pmichaud: agreed
23:28 kid51 My impression is that, after 2.5 hours, we've touched on major issues and people's attention is going elsewhere.
23:29 kid51 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 :)
23:29 kid51 We can defer GSOC discussion until weekly parrotsketch.
23:29 cotto +!
23:29 cotto +1
23:29 kid51 I move we adjourn.
23:30 pmichaud wfm
23:30 cotto Any last issues?
23:30 pmichaud cotto: would you have a moment to discuss the 't' issue in #parrot before we depart?
23:30 cotto pmichaud, sure
23:30 pmichaud thanks
23:31 contingencyplan joined #parrotsketch
23:31 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
23:31 cotto kid51++
23:31 kid51 Thanks.
23:31 soh_cah_toa yes, very organized and professional
23:31 kid51 Okay, that's a wrap.  Other than logging post-summit impressions, take discussions to #parrot or off-channel.
23:32 kid51 left #parrotsketch
23:33 bubaflub left #parrotsketch
23:33 soh_cah_toa left #parrotsketch
23:41 contingencyplan left #parrotsketch
23:49 benabik left #parrotsketch

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