Camelia, the Perl 6 bug

IRC log for #parrot, 2011-05-03

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:04 bacek_at_work seen benabik
00:04 aloha benabik was last seen in #parrot 5 hours 7 mins ago saying "I was fascinated by Hurd for a while...  Then I found MINIX.  Then I decided I don't have enough free time to make either really worth while.".
00:06 whiteknight Tene: I'm extremely interested in all that information. Both your prior attempts and your future ideas
00:07 Tene whiteknight: Hm?  Interested in how I was screwing something up?
00:07 whiteknight yes
00:07 whiteknight that kind of experience is extremely valuable
00:08 whiteknight helps us to avoid mistakes going forward
00:08 whiteknight or, avoid the same ones. I plan to make new, novel mistakes
00:10 lucian r.e. benabik's last comment. an exokernel parrot port would be awesome
00:35 lucian hmm, interesting conversation on freenode#pypy
00:35 lucian ionmonkey may spell the death of nanokit
00:35 lucian jit
00:35 cotto_work interesting
00:37 cotto_work It seemed like Firefox was its big user.
00:45 dalek parrot/m0-prototype: c5e1b43 | cotto++ | t/m0/m0bgen.t:
00:45 dalek parrot/m0-prototype: add some subs to calculate the size of mob chunks
00:45 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/c5e1b43d17
00:46 whiteknight I know FireFox was the big user
00:46 whiteknight and if nanoJit dies, we won't be using it for PArrot
00:50 whiteknight unless we want to try to adopt it wholesale for Parrot
00:50 whiteknight but that seems like a waste
00:52 whiteknight cotto_work: I think nanoJIT was made expressly for FireFox
00:52 whiteknight left #parrot
00:54 cotto_work tonight, I generate valid m0 bytecode
00:58 lucian afaik, Adobe started nanojit, and it got forked when mozilla was gifted tracemonkey
00:59 lucian bah, i'm really getting sick of this dissertation. and i'm very likely complaining too much
01:05 lucian cotto_work: that sounds epic
01:06 lucian bah, firefox memory usage is insane (at least on osx)
01:06 lucian i wonder how on earth tomshardware benchmarked firefox to have the least average memory usage
01:06 Tene lucian: I have to restart firefox daily to deal with memory usage growing.
01:07 lucian on what platform?
01:07 Tene Chrome, however, just uses too much ram constantly.
01:07 Tene linux x86_64
01:07 Tene Fx 4.something
01:07 Tene it wasn't so bad on 3.whatever
01:07 lucian chrome does use a lot, yes
01:07 lucian but if i close tabs, it shrinks fast
01:08 lucian i think firefox has really crappy JS and xpcom GCs
01:08 bubaflub lucian: i've noticed that as well
01:09 bubaflub i'm also on OS X and have to switch between Safari, Firefox, and Chrome for browsing sanity
01:09 bubaflub i blame flash plugins remaining resident in memory long after they should be dead
01:10 bluescreen joined #parrot
01:12 lucian i mostly just stick to chrome
01:13 atrodo cotto_work> m0 night, eh?
01:15 lucian bubaflub: hmm, chrome memory usage with 30 tabs < firefox memory usage with 1 tab
01:16 bubaflub lucian: hmmm. i haven't been very scientific about it.  i try to close or migrate my tabs consistently.  i keep safari for non-flash pages (i have ClickToFlash).  i also like the reader feature.
01:17 lucian if you use more than one browser at a time, it's likely they'll each load lots of things
01:29 benabik joined #parrot
01:31 benabik ~~
01:34 rohit_nsit08 left #parrot
01:35 rohit_nsit08 joined #parrot
01:36 davidfetter left #parrot
01:39 bacek_at_work benabik, aloha. How is your gsoc going?
01:41 benabik bacek_at_work: Greetings!  Not very much GSoC work yet.  Put up an intro blog and a fork of parrot.  But I'm trying to finish a couple projects and a term paper.  :-/  Finals in 2 weeks, then I get to dig in.
01:41 bacek_at_work benabik, ok. We still have plenty of time :)
01:42 cotto ~~
01:42 cotto lucian, I'm only generating valid bytecode.  Running it and generating *useful* bytecode are entirely different matters.
01:43 lucian cotto: i see
01:43 cotto but it's an important step
01:44 rurban_ joined #parrot
01:44 benabik bacek_at_work: Really really looking forward to digging into Parrot.  It's what keeps me motivated on the more irritating schoolwork.  :-D
01:46 rurban left #parrot
01:47 rurban_ is now known as rurban
01:56 lucian benabik: SCHOOLWORK IS EXTREMELY IRRITATING, ISN'T IT?
01:57 benabik lucian: Tell us how you really feel about it.  :-D
01:57 lucian i don't want to segfault perlnet
02:29 woosley joined #parrot
03:12 * tcurtis gets to give a lightning talk about his project at the Chicago GSoC meetup next Thursday.
03:24 cotto tcurtis, awesome
03:27 hudnix left #parrot
03:28 cotto Hacking in Perl 5 after doing PHP all day is like a breath of fresh air.
03:36 mtk0 left #parrot
03:42 cotto Wheee.  I found a problem in the M0 spec.
03:43 mtk0 joined #parrot
03:44 lateau joined #parrot
03:46 sorear Aren't you glad it has a version now?
03:47 cotto That'd matter a lot more if anything could read it.
03:54 ShaneC joined #parrot
03:55 lateau left #parrot
04:10 cotto dukeleto, ping
04:12 dukeleto cotto: pong
04:13 bubaflub left #parrot
04:13 cotto dukeleto, any thoughts on adding type information to the M0 variables table?
04:15 cotto presumably we'll be storing different types in there anyway, so adding explicit information will make the format less opaque
04:59 dukeleto https://github.com/brixen/poetics
04:59 dukeleto Native implementation of CoffeeScript on Rubinius
05:17 cotto_work left #parrot
05:17 dalek parrot/m0-prototype: 8a354c4 | cotto++ | t/m0/m0bgen.t:
05:17 dalek parrot/m0-prototype: make m0b generation code "work"
05:17 dalek parrot/m0-prototype:
05:17 dalek parrot/m0-prototype: The code seems to be correct and generates sane-looking results, but
05:17 dalek parrot/m0-prototype: it'll be hard to tell if it's actually correct without an actual interp.
05:17 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/8a354c46b3
05:17 dalek parrot/m0-prototype: f2263b3 | cotto++ | t/m0/m0bgen.t:
05:17 dalek parrot/m0-prototype: finish fake mob generation code, add a batch of failing tests
05:17 dalek parrot/m0-prototype:
05:17 dalek parrot/m0-prototype: At this point I'm only marginally confident that the generated M0
05:17 dalek parrot/m0-prototype: bytecode is correct, but I'd much rather start writing the interp than
05:17 dalek parrot/m0-prototype: stare at a hexedit some more.
05:17 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/f2263b33a1
05:18 cotto It seems that "false" makes a poor M0 interp.  I guess I'll have to write a real one.
05:20 dalek website: tcurtis++ | The adventure begins
05:20 dalek website: http://www.parrot.org/content/adventure-begins
05:20 lucian dukeleto: were you in freenode#coffeescript ?
05:20 dalek parrot/m0-prototype: 1339338 | cotto++ | t/m0/m0bgen.t:
05:20 dalek parrot/m0-prototype: update test plan for the M0 interp tests
05:20 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/1339338134
05:20 cotto tcurtis++
05:30 cosimo joined #parrot
05:35 dukeleto lucian: no, why?
05:36 dukeleto tcurtis++ # bloggin'
05:36 lucian__ joined #parrot
05:36 dukeleto "But maybe if someone provides some nice suggestions, either by email or on #parrot, the Parrot community will be spared this travesty of nomenclature."
05:37 dukeleto lulz
05:37 dukeleto msg tcurtis my suggestion for the name is "lollerskates"
05:37 aloha OK. I'll deliver the message.
05:38 cotto tcurtis, I'm not sure what dukeleto's talking about, but I approve.
05:38 dukeleto cotto: http://knowyourmeme.com/memes/lollerskates
05:39 lucian left #parrot
05:39 cotto dukeleto, of course.  I'm reading his post now to get the context.
05:39 dukeleto msg tcurtis look how many logos you have to choose from already! http://knowyourmeme.com/memes/lollerskates
05:39 aloha OK. I'll deliver the message.
05:40 dukeleto cotto: mea culpa
05:40 dukeleto msg tcurtis or possibly lalrskate
05:40 aloha OK. I'll deliver the message.
05:41 cotto Sweet.  We'll get an algorithm that was published in the year I was born.
05:42 cotto '80s GC, '80s parser generator
05:42 cotto now all we need is an '80s soundtrack
05:43 dukeleto slow and steady wins the race
05:51 KaeseEs cotto: i nominate Powerslave
05:56 lucian joined #parrot
06:00 lucian__ left #parrot
06:11 dalek parrot/m0-spec: 73df301 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
06:11 dalek parrot/m0-spec: add a place in the binary format for the M0 version number
06:11 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/73df301bdc
06:12 dalek parrot/m0-spec: a36275c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
06:12 dalek parrot/m0-spec: delete a TODO about where the version should go
06:12 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/a36275c392
06:16 dalek parrot/m0-prototype: 6d5fd46 | cotto++ | t/m0/m0bgen.t:
06:16 dalek parrot/m0-prototype: update m0bgen with version number, make header code more readable
06:16 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/6d5fd4698c
06:23 particle1 left #parrot
06:24 fperrad joined #parrot
06:28 cotto dukeleto, I'd appreciate an eye on t/m0/m0bgen.t to make sure it's sane.
06:28 dalek parrot/m0-prototype: 0276976 | cotto++ | t/m0/m0bgen.t:
06:28 dalek parrot/m0-prototype: clean up after ourselves
06:28 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/027697656d
06:28 dalek parrot/m0-prototype: 0174b30 | cotto++ | src/m0/m0_interp.pl:
06:28 dalek parrot/m0-prototype: beginnings of the prototype M0 interp
06:28 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/0174b30f92
06:28 cotto time for sleep.
06:33 rohit_nsit08 left #parrot
06:44 theory left #parrot
07:15 dod joined #parrot
07:36 rhebus joined #parrot
07:37 lateau joined #parrot
07:45 mj41 joined #parrot
07:45 cosimo left #parrot
07:51 UltraDM joined #parrot
07:53 rhebus left #parrot
08:01 lateau left #parrot
08:35 bluescreen left #parrot
08:38 jrt4__ left #parrot
08:56 bacek ~~
08:57 contingencyplan left #parrot
09:00 rohit_nsit08 joined #parrot
09:06 lucian left #parrot
09:08 lucian joined #parrot
09:13 lucian_ joined #parrot
09:17 lucian left #parrot
09:45 rurban_ joined #parrot
09:46 rurban left #parrot
09:47 rurban_ is now known as rurban
10:09 woosley left #parrot
10:23 particle joined #parrot
10:38 woosley joined #parrot
10:38 lucian joined #parrot
10:43 lucian_ left #parrot
11:24 mtk0 left #parrot
11:30 mtk0 joined #parrot
11:57 Patterner left #parrot
11:57 Psyche^ joined #parrot
11:57 Psyche^ is now known as Patterner
12:06 woosley left #parrot
12:09 whiteknight joined #parrot
12:17 whiteknight good morning, #parrot
12:17 whiteknight interesting article today about source control: http://www.troyhunt.com/2011/05/10-com​mandments-of-good-source-control.html
12:55 ambs joined #parrot
12:57 lucian whiteknight: i'm not sure i agree with the last one
13:01 coke_ was that "dependencies" ? I mentally translated that one to "make sure your dependencies are easily installable", not "exist in the vcs"
13:01 bubaflub joined #parrot
13:02 whiteknight I've seen it done both ways.
13:02 moritz s/the vcs/a vcs/
13:02 whiteknight I had a boss at my last job who insisted on including the whole IDE in svn
13:02 coke_ urg?
13:02 whiteknight I thought that was bananas, but keeping some libraries in there is nice
13:03 whiteknight In general, it depends. If the dependency is easy enough to get yourself and easy enough to keep up to date, it's no big deal
13:05 coke_ I have a build.xml (ARGH) that I use to fetch all the deps I need.
13:06 whiteknight I think that counts
13:06 coke_ I am "fighting" with developers new to svn who want to include the entire unzipped 3rd party libraries into their own project.
13:06 whiteknight I mean, whether you have the dependencies themselves, or a mechanism to fetch the correct ones automatically makes no functional difference as far as I am concerned
13:06 whiteknight where libraries become a problem is if somebody updates to a new version of the lib
13:29 ambs left #parrot
13:34 hudnix joined #parrot
13:35 lateau joined #parrot
13:37 whiteknight seen cgaetner
13:37 aloha Sorry, I haven't seen cgaetner.
13:37 whiteknight seen cgaertner
13:37 aloha cgaertner was last seen in #parrot 30 days 23 hours ago saying "btw, who would be willing to mentor the project? the proposal template ask for that information, I I don't remeber anyone actually mentioning that...".
13:37 whiteknight blah
13:44 lucian_ joined #parrot
13:47 lucian left #parrot
13:48 lucian_ is now known as lucian
13:51 whiteknight opbots trust lucian
13:51 slavorg But I already trust lucian
13:51 slavorgn But I already trust lucian
13:52 whiteknight opbots names
13:53 lucian ?
13:53 whiteknight ??
13:54 lucian i was wondering what you were trying to do
13:57 whiteknight lucian: I'm making sure you have ops
13:57 lucian i see
13:57 lucian i don't really know what they do :)
13:57 whiteknight basically, nothing
13:57 whiteknight but my IRC client sorts usernames with ops at the top, and now I can actually see when you are signed on without scrolling
13:57 whiteknight AND I AM WATCHING YOU
13:58 lucian yeah, my client does the same
14:00 lucian I FOUND THE PROBLEM! dammit
14:02 whiteknight what problem?
14:02 bluescreen joined #parrot
14:03 lucian in my dissertation demo
14:03 lucian sadly it's hard to fix and i have little time ...
14:03 lucian i've had this problem for very long, too
14:07 hudnix left #parrot
14:08 hudnix joined #parrot
14:09 cotto_work joined #parrot
14:10 whiteknight when is the demo?
14:10 whiteknight and will you be videotaping it and sending me a link?
14:10 whiteknight :)
14:11 PerlJam whiteknight: ask if there's remote participation.  Maybe you can heckle^Wparticipate.
14:11 PerlJam :)
14:16 lucian no remote participation. i'll consider videotaping
14:18 whiteknight I used to love going to dissertations and other presentations when I was in school
14:19 PerlJam whiteknight: I always liked going to the ones that weren't train wrecks.
14:20 PerlJam when they were clearly not prepared (i.e.,  their chair wasn't doing his/her job)  it was just sad.
14:21 whiteknight My thesis presentation ended up being shorter than I anticipated. I talked too fast and had too few questions
14:22 whiteknight so that was disappointing
14:22 Andy joined #parrot
14:23 lucian mine'll suck immensely
14:25 PerlJam lucian: but you'll get through it, they'll suggest some minor changes, everyone will sign off on it, then party time!
14:26 lucian PerlJam: meh, if i don't fail the year
14:28 whiteknight that's the spirit!
14:30 pmichaud hola, #parrot
14:30 PerlJam greetings pmichaud!
14:30 whiteknight good morning, pmichaud
14:31 pmichaud just a quick note that I'm getting some very strange timings on the core.pm test that bacek++ cited earlier today
14:31 whiteknight strange in the good way?
14:31 pmichaud no
14:31 whiteknight damnit. It's never the good way
14:31 pmichaud first time I did the test, core.pm with Parrot 3.0 took 900s to compile
14:31 pmichaud I then tested with Parrot 3.3, took 300s.  I'm thinking "wow, 66% speedup!"
14:32 pmichaud I then recompiled core.pm with Parrot 3.0, it took 270s the second time
14:32 jnthn__ lolWUT?!
14:32 PerlJam vagaries of GC?
14:32 pmichaud so, I rebooted, untarred a fresh copy of Rakudo 2011.01 (Parrot 3.0), rebuilt and did the core.pm test:  200s
14:32 whiteknight is that Parrot 3.3.0 with --gc=gms?
14:33 jnthn__ pmichaud: Some adaptive CPU thingy?
14:33 pmichaud yes, 3.3.0 with --gc=gms
14:33 whiteknight pmichaud: my suggestion is to keep compiling, because it gets faster every time
14:33 jnthn__ lol
14:33 whiteknight pmichaud: when it gets down to 10s, stop touching it
14:33 whiteknight :)
14:33 PerlJam how many GC runs does parrot go through when compiling core.pm?
14:33 pmichaud PerlJam: I don't know
14:33 jnthn__ fwiw, I've found nqp test times quite stable. Though it's a much smaller workload...
14:34 whiteknight PerlJam: that is a very good question. I have to assume GC churn there is quite high
14:34 PerlJam that's what I'd guess too
14:34 jnthn__ Yeah, but gen-gc can run regularly...the nursery is meant to be small.
14:34 whiteknight I'd suggest profiling it, but there may not be enough time left in the universe
14:34 jnthn__ Compared to the entire working set.
14:35 pmichaud I don't have an easy way to count the gc runs for Parrot 3.0
14:35 whiteknight what we could do is insert some kind of stderr debugging statement in the function that runs it
14:35 whiteknight print out a count
14:35 pmichaud that starts to get messy :(
14:35 PerlJam pmichaud: also, did you only have the one really long run?  Maybe something else was going on on your system at that time?
14:36 whiteknight I never said it would be pretty, but for a first blush it will give us a general ballpark count
14:36 pmichaud PerlJam: that's what I'm guessing now -- something else must have been running on the system
14:37 pmichaud PerlJam: but even so, the difference between 300s and 200s is pretty big also
14:37 whiteknight pmichaud: yes, that is pretty big. We would expect some small regressions because of the way we are handling packfiles now, but that can't be adding up to 33% of the total
14:38 whiteknight I'm talking about a handful of new PMCs in the old generation
14:38 whiteknight so 100s difference there is pretty extreme
14:41 pmichaud just ran again with 3.0:  207s
14:41 pmichaud trying 2011.04/3.3...
14:42 PerlJam you'll have to do a lot more runs to get anything statistically significant  ;)
14:42 pmichaud as long as I have 3.0 runs that are faster than 3.3 runs.... I think I can say that 3.3 isn't a speed improvement over 3.0 :-)
14:43 PerlJam in anycase if your timeline is accurate it went  900 300 270 200 ...  seems like a decreasing trend to me.  Whatever was running during the 900s run was trailing off.
14:43 pmichaud if any(@parrot_3_0) < all(@parrot_3_3) { say "3.3 isn't faster"; }
14:44 pmichaud I rebooted after the 300, yes
14:44 pmichaud also, it's not quite that simple
14:44 pmichaud because
14:44 whiteknight I don't think there is an expectation that 3.3 is faster than 3.0 --gc=gms
14:45 pmichaud 3.0 is gc=ms2
14:45 pmichaud gms didn't exist in 3.0
14:45 whiteknight hmm, I'm muddling up my timelines
14:45 pmichaud I'm saying that 3.3 with gms isn't faster than 3.0 with ms2
14:45 PerlJam do any profiling tools exist for GC?  Even something like counting the marks/sweeps/whatever
14:45 pmichaud at least, for spectests and for my limited testing of core.pm
14:46 pmichaud PerlJam: there are some interpreter variables that can be queried
14:46 pmichaud but those were broken for much of the past six months
14:46 whiteknight that's a weird result because we were seeing significant performance improvements in various Rakudo benchmarks when GMS landed.
14:46 pmichaud I don't remember when they got fixed
14:46 * moritz had the feeling (but no data to prove it) that rakudo on parrot got slower since 3.1 or 3.2
14:46 whiteknight moritz: that's possible. more data would be very nice
14:46 pmichaud whiteknight: right, that's why I've been bringing it up
14:46 PerlJam moritz: oddly I had the same feeling (but again, no evidence)
14:47 pmichaud I ran some simple tests on the 2011.04 star release versus the 2011.01 star release because I wanted to say "Rakudo Star is now X% faster"
14:47 pmichaud but I couldn't do that
14:47 pmichaud because it wasn't.  :()
14:47 whiteknight I could very well be underestimating the performance effects of some of the IMCC and packfile changes that have happened
14:47 whiteknight that's probably the biggest changeset that has landed recently
14:47 * moritz should start up his otherwise unused desktop computer when he's home, and automate some speed tests
14:49 pmichaud 3.3 retest:  289s
14:49 whiteknight okay, can we get a timing of 3.2?
14:49 pmichaud sure
14:50 pmichaud it'll take a bit to build Parrot
14:50 whiteknight if that's as fast or faster than 3.0, we can start to expect the imcc/packfile changes of being the culprit
14:50 whiteknight If the problems started before 3.2, we have a different set of things to look at
14:52 pmichaud here's what I propose to do (after I get a few house errands taken care of):
14:52 pmichaud 1.  Run the core.pm test four times for each of 3.0, 3.2, and 3.3
14:52 pmichaud 2.  Throw out the slowest time of each
14:53 pmichaud 3.  Compare (a) the fastest time of each and (b) the average time of each
14:53 pmichaud the other tests I've been running are t/spec/S05-mass/rx.t   and t/spec/S32-trig/sin.t
14:54 pmichaud is there a table or easy way to find out what the default gc is for each of the parrot versions?
14:54 moritz it's ms2 for 3.3 and older
14:54 pmichaud well, only back until ms2 was created, yes?
14:54 pmichaud when did ms2 land?
14:54 moritz the switch to gms as only after the 3.3 release
14:55 pmichaud rakudo requests gms for 2011.03 (3.2) and 2011.04 (3.3), though
14:55 moritz yes
14:56 pmichaud so, 2011.01 is using ms2, 2011.02 is using m2, 2011.03 is using gms, 2011.04 is using gms... is that right?
14:56 pmichaud (does that sound right?)
14:56 pmichaud s/m2/ms2/
14:57 * jnthn__ has a machine now building all <2011.02  2011.03  2011.04>
14:57 moritz pmichaud: I think that's right, yes
15:02 lucian left #parrot
15:02 pmichaud first run of 3.2:  262s
15:03 pmichaud (faster than 3.3, slower than 3.0)
15:04 pmichaud running again
15:14 dmalcolm joined #parrot
15:16 pmichaud 3.2 second run: 262s
15:17 ambs joined #parrot
15:20 UltraDM left #parrot
15:22 whiteknight okay, so 3.2 is about midway between 3.0 and 3.3?
15:27 whiteknight what I really need to see is a graph
15:27 whiteknight my powers of number-understanding are poor today
15:28 PerlJam Has the chief benchmark for GC performance been "time to compile rakudo"?
15:30 whiteknight I can't say that there is a single "chief benchmark" unfortunately
15:30 whiteknight rakudo build and spectest run times are high on the list
15:32 PerlJam so, no one has built a test suite designed to stress the GC in various ways?
15:35 tcurtis ~~
15:35 whiteknight PerlJam: nosir
15:36 whiteknight There may be some things in the examples folder that have the side effect of describing GC performance, but no benchmark explicitly designed to stress it
15:36 pmichaud besides, I'm not necessarily pointing at the gc
15:37 pmichaud I do know that a new gc was implemented, and several of us "observed" significant rakudo performance improvements as a result
15:37 plobsing we have examples/benchmarks/gc_*
15:37 whiteknight pmichaud: well, to narrow the GC out of contention, we could run 3.3 with --gc=ms2, same as what 3.0 used
15:37 PerlJam pmichaud: no, just the GC switch across the versions you were looking at made me think of it.
15:37 pmichaud but now when I try it in 2011.04, I'm not seeing any improvements -- in fact, it's arguably 40% worse than it was in January
15:37 hercynium joined #parrot
15:37 pmichaud whiteknight: I did that already (by accident) -- it was *way* worse
15:38 whiteknight okay, so that rules out GC algorithm
15:38 whiteknight so we are seeing other slowdowns
15:38 whiteknight including slowdowns before and after 3.2 it seems
15:38 pmichaud whiteknight: when I was building the 2011.04 star release, it didn't have the --gc option in its configure, thus Parrot got built with its default (ms2).  And the spectest run took 55m instead of 30m
15:38 whiteknight ouch
15:38 whiteknight gms for the win, then
15:38 tcurtis aloha, msg dukeleto the lalrskate idea didn't seem too great to me, but then I realized I could name a tool for outputting the parsing table "lalrcat".
15:38 aloha tcurtis: OK. I'll deliver the message.
15:39 pmichaud so gms is definitely better than ms2 for the spectest, at least for that one test I ran
15:39 pmichaud but we're still heading in the wrong direction w.r.t. parrot speed, it seems :(
15:39 whiteknight I think we definitely need to review those imcc_compreg_pmc and packfile_wrap branch merges
15:40 pmichaud third run of 3.2: 262s
15:40 pmichaud so it seems that 3.2 is consistently 262s  :-)
15:40 whiteknight I don't want to undo those merges, but if we can narrow down to that being a part of the problem we can focus our optimization efforts
15:40 pmichaud (core.pm)
15:40 pmichaud okay, I'll start my long string of test runs now
15:40 whiteknight that's I really appreciate it
15:40 contingencyplan joined #parrot
15:41 whiteknight pmichaud: if we can get a test before the imcc_compreg_pmc merge, that should be sufficient. packfile_wrap went in right before 3.3
15:41 whiteknight so the difference between those two should give us the aggregate effect
15:41 pmichaud I'll start with the releases first
15:41 whiteknight okay
15:41 pmichaud that gives us a good, stable baseline that makes it very reproducible for everyone that wants to try
15:42 pmichaud (also, it's what our collective users are seeing)
15:42 whiteknight timings I saw for imcc_compreg_pmc didn't look like they were any worse, I don't know that packfile_wrap was ever benchmarked
15:42 whiteknight at least not aggressively
15:42 dmalcolm left #parrot
15:42 whiteknight IMCC man, let me tell you about IMCC. Every night I pray for god to light it on fire
15:43 whiteknight and every morning, disappointment
15:44 plobsing whiteknight: (re: PI) yeah, runcore_optable_fixup() is just wrong. That was part a mechanical translation of code whose underlying assumptions were broken by dynop mapping. You'll need to figure out a different way to accomplish what that code does.
15:45 whiteknight plobsing: thanks for looking at it. I figured that was the problem, and I have no idea what to do differently. I still don't completely understand what PI does in all cases
15:45 whiteknight plobsing: tracing through it is a bit of a nightmare sometimes
15:46 plobsing That code is supposed to maintain the probe hooks in sync with the op table of instrumented interp so the intruments know what an executed op is.
15:47 whiteknight how is it inserting those probe hooks, a copy of the optable?
15:47 plobsing It assumes the op table works the old way and only grows when we load new oplibs.
15:48 plobsing but it also messes with the instrumented interp for some reason
15:48 plobsing whiteknight: I think it is a runloop thing
15:48 whiteknight plobsing: I've already ripped out the instrumentgc pmc, because it was causing massive fail with the new GC system. I may have to pull out instrumentruncore too
15:48 plobsing whiteknight: what would that leave?
15:49 whiteknight That is, I'm trying to get to some kind of stable core of stuff that "works"
15:49 whiteknight I want a baseline
15:49 whiteknight and I have no idea what would be left
15:49 whiteknight class hooks, I think. Although those tests look fail too
15:50 whiteknight the bad news is that cotto and soh_cah_toa are going to need to re-evaluate some of the entries in his GSoC timeline
15:50 plobsing if there were one things PI should do, regardless of all others, it is intrument the runcore.
15:50 whiteknight because we were going on the assumption that PI was mostly workable and needed just a few tweaks to be fixed
15:50 whiteknight but if it's making some hugely wrong underlying assumptions, that's a big problem
15:51 plobsing whiteknight: I don't think PI is suitable for the debugger project. It does different things.
15:51 dukeleto whiteknight: sounds like perhaps PI should not be used for the debugger project, as plobsing++ mentions
15:51 whiteknight inserting hooks and probes into the runcore wouldn't be helpful for the debugger?
15:51 whiteknight dukeleto: at the moment, it can't be used because it doesn't work
15:52 whiteknight if it were working, the introspection capabilities are quite interesting
15:52 plobsing whiteknight: yes, but the way PI does it is *way* more flexible than what a debugger needs
15:52 dukeleto whiteknight: yes, I gathered that. I don't want a student to be blocked by their dependencies not working.
15:53 dukeleto if the new debugger is written in such a way that it could use PI down the line, when it works properly, that may be the best course of action here
15:53 whiteknight plobsing: so we shouldn't use a base library because the base library provides a superset of functionality?
15:53 plobsing from my perspective, it would be easier to just write a new, special-purpose instrumentation system than to resurect PI.
15:54 whiteknight plobsing: I am coming to that conclusion now too. Back when the project was proposed, I thought the effort to resurrect PI would be much lower
15:54 plobsing Please do not construe this as a commitment on my part to write such a system.
15:54 whiteknight clearly it's turning into a much larger project than is feasible
15:54 whiteknight I think the better course of action is to have soh_cah_toa borrow code liberally where necessary, but to write his own system from the ground up
15:57 plobsing Again, I think, from the perspective of a debugger, the way PI does things is too general and not the most direct.
15:57 whiteknight that's fine. At this point it is up to cotto and soh_cah_toa about how to proceed
15:57 whiteknight but clearly, PI is not a viable option right now
15:58 whiteknight damnit. Not the result I was hoping for
15:59 theory joined #parrot
16:00 whiteknight brb food
16:02 jnthn__ pmichaud: I build the 2011.0[432] releases of Rakudo with their chosen Parrot versions. I then did three runs of core.pm compilation. (OK, I didn't...a script I wrote did :-)). Results: https://gist.github.com/953615
16:02 pmichaud interesting.
16:02 pmichaud I have my script running now... we'll see what it reports
16:03 pmichaud how about 2011.01?
16:03 dukeleto jnthn__: that looks quite nice
16:04 jnthn__ pmichaud: Updated the gist with the script, fwiw.
16:04 dalek winxed: r970 | NotFound++ | trunk/winxedst1.winxed:
16:04 dalek winxed: fix bug in new qualified introduced in recent refactor, issue 24, plobsing++
16:04 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=970
16:05 jnthn__ pmichaud: running a 2011.01 now
16:05 jnthn__ pmichaud: This is in a powerful and lightly loaded 64-bit Linux box.
16:05 jnthn__ s/in/on/
16:06 * moritz would love to get similar numbers :-)
16:08 jnthn__ I...don't use this box for that much :)
16:09 jnthn__ Maybe I should :)
16:09 dalek winxed: r971 | NotFound++ | trunk/pir/winxed_compiler.pir:
16:09 dalek winxed: update installable compiler
16:09 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=971
16:18 dod left #parrot
16:20 jnthn__ pmichaud: https://gist.github.com/953615 updated with 2011.01 times.
16:20 jnthn__ pmichaud: First time there's a way-out-there figure.
16:20 jnthn__ But other two are very close.
16:31 pmichaud my numbers will start to come in soon
16:35 jnthn__ pmichaud: btw, I'm two test fails off merging ctmo branch in nqp repo. After that, it's "just" installation issues.
16:35 jnthn__ pmichaud: Then I can dig into rakudo/nom :)
16:36 jnthn__ Expect to fix those fails today :)
16:36 whiteknight jnthn__++
16:37 whiteknight Those numbers seem to be exactly the opposite of what pmichaud is reporting
16:37 whiteknight if I'm reading it correctly
16:37 pmichaud yes, they are
16:38 whiteknight there's a chance that GMS might be badly behaved on systems with various limitations
16:38 whiteknight that is, it's not really tuned, much less tuned for any particular platform
16:39 whiteknight what we might need to do is start putting together a collection of valgrind reports
16:39 pmichaud I'm re-running my tests now.  You can watch the updates (as I make them) at http://pmichaud.com/sandbox/rak-bench-1.txt
16:40 rohit_nsit08 left #parrot
16:42 davidfetter joined #parrot
16:45 dukeleto Smalltalk on Javascript: https://github.com/NicolasPetton/jtalk
16:45 dukeleto what will those kids think of next?
16:47 moritz parrot on JS?
16:48 moritz actually I've read about a protype C-to-javascript compiler that could run (modified) Doom in the browser
16:48 moritz maybe we could port parrot to it
16:48 moritz and then run on top of V8, to speed things up
16:48 moritz SCNR
16:49 plobsing moritz: emscripten?
16:51 plobsing NotFound: the -I flag on winxed doesn't seem to be working any more
16:56 dalek parrot: dc5f4cf | mikehh++ | src/call/pcc.c:
16:56 dalek parrot: add missing ASSERT_ARGS
16:56 dalek parrot: review: https://github.com/parrot/parrot/commit/dc5f4cf819
16:56 dalek parrot: cccbf37 | mikehh++ | src/debug.c:
16:56 dalek parrot: add missing ASSERT_ARGS
16:56 dalek parrot: review: https://github.com/parrot/parrot/commit/cccbf37e0a
16:56 dalek parrot: 8b0397b | mikehh++ | src/debug.c:
16:56 dalek parrot: add missing documentation
16:56 dalek parrot: review: https://github.com/parrot/parrot/commit/8b0397ba97
16:56 dalek parrot: e3ecaf8 | mikehh++ | src/gc/gc_ms.c:
16:56 dalek parrot: add missing documentation
16:56 dalek parrot: review: https://github.com/parrot/parrot/commit/e3ecaf848a
16:59 dodathome joined #parrot
16:59 plobsing msg kid51 can you try the latest tt1931-nci-parameters-deprecation on your machine? I suspect it may work.
16:59 aloha OK. I'll deliver the message.
17:00 mj41 left #parrot
17:11 cotto_work ~~
17:11 whiteknight left #parrot
17:23 dmalcolm joined #parrot
17:25 cotto_work That's too bad about PI, but it definitely does about 500% of what a mere debugger would need.
17:25 cotto_work well, did
17:26 whiteknight joined #parrot
17:27 cotto_work hio whiteknight
17:27 whiteknight hio
17:27 NotFound plobsing: I haven't used it recently. Are you using the installed version or the source tree?
17:27 cotto_work I saw that GSoC will be a bit more work for me and soh_cah_tao than it first looked like it'd be.
17:31 whiteknight cotto_work: maybe not. Readjust the schedule
17:31 whiteknight you're starting at a lower point, so will end up at a lower point maybe
17:34 pmichaud bench mark results after two trials:  http://pmichaud.com/sandbox/rak-bench-1.txt
17:36 whiteknight pmichaud: okay, so it looks like 3.3 is faster than 3.0
17:36 dalek winxed: r972 | NotFound++ | trunk/examples/Mysql.winxed:
17:36 dalek winxed: update example Mysql
17:36 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=972
17:36 pmichaud no
17:36 pmichaud 3.3 is *slower* than 3.0
17:36 pmichaud should I change the signs on the percents?
17:37 whiteknight oh, sorry. the percents surprised me
17:37 whiteknight okay, so 3.1 was the slowest
17:37 pmichaud yes
17:37 whiteknight okay okay.
17:37 pmichaud looks like something happened between 3.0 and 3.1 to really slow things down
17:37 pmichaud and then maybe gms is recovering some of that speed loss
17:38 pmichaud should I use +26.0%  to mean "26% slower?"  instead of "-26.0%"?
17:38 cotto_work You could use % of 3.0, i.e. 126%
17:38 whiteknight it doesn't matter now that I know how to read it
17:39 whiteknight okay, 3.1 was pretty big. Looking at news I see a few items that could potentially cause slowdowns
17:39 pmichaud what will be easiest for others?  I plan to post this to the m/l
17:39 cotto_work Yeah.  More important is that we figure out how to act on it.
17:39 whiteknight "Exception PMCs are now subclassable from PIR"
17:39 whiteknight "Improved GC performance on low-memory systems"
17:39 whiteknight "Improved GC latency"
17:39 whiteknight those things all raise red flags for me
17:40 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#16100) fulltest) at 3_3_0-86-ge3ecaf8
17:40 mikehh Kubuntu 11.04 amd64 (g++)
17:44 PerlJam As long as you put a note that say "negative percentages are slower" it should be fine IMHO.
17:44 pmichaud I switched to cotto++'s suggestion
17:45 rurban_ joined #parrot
17:47 * moritz currently has his desktop machine set up to measure rakudo compilation times for 4 releases, three times each
17:47 cotto_work moritz++
17:47 rurban left #parrot
17:48 rurban_ is now known as rurban
17:50 dalek cardinal: c2ad937 | (Kim, Daehyub)++ | Rakefile:
17:50 dalek cardinal: fix: coding miss in Rakefile:335
17:50 dalek cardinal: review: https://github.com/parrot/​cardinal/commit/c2ad9377ae
17:50 dalek cardinal: ef84b79 | (Kim, Daehyub)++ | / (3 files):
17:50 dalek cardinal: Integer#pred
17:50 dalek cardinal: review: https://github.com/parrot/​cardinal/commit/ef84b797dc
17:50 dalek cardinal: 3fa71e7 | dukeleto++ | / (3 files):
17:51 dalek cardinal: Merge pull request #5 from lateau/master.
17:51 dalek cardinal:
17:51 dalek cardinal: fix and add
17:51 dalek cardinal: review: https://github.com/parrot/​cardinal/commit/3fa71e7905
17:51 dukeleto wow, merge buttons really do make merging pull requests dead simple
17:52 dukeleto wow, i think cardinal is alive
17:52 moritz fwiw http://moritz.faui2k3.org/tmp/time-rakudo.txt is the script that I use
17:53 pmichaud The scripts I'm using:  http://pmichaud.com/rakbench
17:56 pmichaud moritz: what part of your script switch rakudo/parrot versions?  I'm not seeing it
17:56 moritz pmichaud: oh shit, I forgot that part :(
17:56 moritz pmichaud: thanks for pointing it out :-)
17:57 pmichaud this is one reason I prefer to work from the tarballs
17:57 pmichaud also we don't have to worry about getting the correct version of the spectests :-)
17:57 moritz I'll abort after the current run, and edit the output data to indicate the actual version it used
17:58 moritz pmichaud: then you can still forget a chdir - it's really one commit each :-)
17:58 moritz s/commit/command/
17:59 * dukeleto is going to miss #ps today
17:59 * coke_ fights with svn and wishes that git had a prayer of working out here.
18:00 cotto_work dukeleto: do we need to reconsider when we have #ps?
18:01 whiteknight has duke been missing it regularly?
18:02 dukeleto cotto_work: not on case of me. I need to see an accountant today to get my state taxes done, before the taxman starts stalking me.
18:02 coke_ lateau?
18:02 lateau left #parrot
18:02 coke_ ... wow.
18:02 dukeleto coke_: ?
18:02 coke_ just seeing if aloha knew him.
18:02 coke_ aloha, lateau?
18:02 aloha coke_: No clue. Sorry.
18:06 rohit_nsit08 joined #parrot
18:07 pmichaud Results after three trials (file location has changed):  http://pmichaud.com/rakbench/results-20110503.txt
18:09 whiteknight pmichaud: I think that's plenty of data, thanks
18:09 whiteknight pmichaud: no need to keep wasting cycles. The trend is clear
18:10 pmichaud I'm a little suspicious of that 254, though.
18:10 pmichaud since the others both came out to 278 +/- 1
18:10 pmichaud (however, earlier today when I was running the same test I was down at 200.... so, *something* is weird about the 2011.01 timings
18:11 pmichaud besides, cycles are cheap, and I have plenty of machines :)
18:12 whiteknight pmichaud: okay :) I won't tell you how to spend your cycles
18:14 whiteknight so there was clearly a major slowdown between 3.0 and 3.1, and another slowdown between 3.2 and 3.3
18:15 whiteknight that's good. That narrows it down and shows us that we have two separate slowdowns to deal with
18:15 pmichaud oh!  does the compiled parrot have any sort of random seed in it?
18:15 pmichaud e.g., for hashing or the like?
18:17 pmichaud I wonder if some of the differences I'm seeing in the 2011.01 test have to do with having compiled different parrot binaries in previous tests
18:17 pmichaud i.e., perhaps some parrot binaries are faster than others...?
18:17 jnthn__ I thought the hash seed was picked at startup and stashed in the interpreter.
18:17 pmichaud I thought so too... but I'm really curious how I got those ~200s numbers earlier.
18:18 jnthn__ Yeah, me too :/
18:18 pmichaud because I'm not seeing them now.
18:18 pmichaud and they were pretty consistent then
18:23 pmichaud I guess I should start looking at a new desktop too, since everyone seems to be getting much faster compiles than I am :)
18:24 whiteknight here's your sign
18:28 whiteknight I need to get a new laptop myself eventually. It still has plenty of power but my son keeps throwing it onto the floor
18:28 whiteknight the one hinge is broken again, and the monitor flickers and makes a buzzing noise
18:29 whiteknight I picked it up off my lap yesterday, and found a screw. I don't know where it came from
18:29 whiteknight I've started hiding the laptop under the couch so my son can't find it
18:30 ShaneC left #parrot
18:30 whiteknight it's only a matter of time
18:34 cotto_work pmichaud: Parrot does pick a random hash seed at startup.  You can fix it by passing --hash-seed=1234 to the parrot executable
18:41 pmichaud cotto_work:  yeah, I'm not sure that's it.
18:41 pmichaud it feels more like it has to be something that's in the executable
18:41 pmichaud either that or I just ended up with a string of lucky seeds
18:42 pmichaud but also, only the 2011.01 build seems to show significant variation.  All of the other builds only have a variation of ~2s
18:42 pmichaud I have another script running now to test multiple runs of the 2011.01, both rebuilding and not rebuilding parrot in between
18:43 moritz (355 - 338) / 355
18:43 aloha 0.047887323943662
18:43 whiteknight pmichaud: maybe a test script to randomize the order you test things in? Maybe you're getting into a really weird cache situation at the beginning of the loop
18:43 moritz that's my max variations for 2011.01
18:43 whiteknight I'm just throwing out weird ideas
18:44 whiteknight I would hope that a single run of the program with fixed parameters would be a little bit more deterministic than that
18:44 ShaneC joined #parrot
18:47 pmichaud whiteknight: yes, I'm wondering about determinism also
18:47 pmichaud but repeatability is important too
18:48 pmichaud anyway, we'll see what this latest script gives me
18:49 jevin left #parrot
18:55 whiteknight pmichaud++
18:59 plobsing NotFound: I tried both
19:00 jevin joined #parrot
19:00 ShaneC left #parrot
19:08 mtk0 left #parrot
19:08 mtk0 joined #parrot
19:08 pmichaud http://pmichaud.com/rakbench/results-20110503.txt   # updated with timings from sin.t test
19:10 jnthn__ pmichaud: #phasers is on at the moment, btw :)
19:12 bubaflub left #parrot
19:21 whiteknight I really need to attend the #phasers meeting more regularly
19:23 Coke__ left #parrot
19:23 Coke joined #parrot
19:28 cotto_work #ps in 60
19:31 Coke left #parrot
19:31 Coke joined #parrot
19:33 bubaflub joined #parrot
19:38 Coke left #parrot
19:38 Coke joined #parrot
19:46 rohit_nsit08 left #parrot
19:46 Coke left #parrot
19:46 Coke joined #parrot
19:50 cotto_work anyone feel like writing an M0 disassembler?
19:51 benabik Sounds fascinating, but I lack tuits.
19:51 KaeseEs .goog M0 spec
19:51 KaeseEs i thought there was a phenny instance itc :(
19:51 tadzik .g M0 spec
19:52 tadzik bah
19:53 Coke left #parrot
19:53 cotto_work in the m0-spec branch in docs/pdds/draft
19:53 Coke joined #parrot
19:54 cotto_work aloha: m0 spec?
19:54 aloha cotto_work: Search me, bub.
19:54 cotto_work aloha: M0 spec is docs/pdds/drafts/pdd32-m0.pod in the m0-spec branch
19:54 aloha cotto_work: Okay.
19:54 cotto_work aloha: m0 spec?
19:54 aloha cotto_work: m0 spec is docs/pdds/drafts/pdd32-m0.pod in the m0-spec branch
19:56 cotto_work #ps in 32
19:56 cotto_work get those reports posted!
19:56 rohit_nsit08 joined #parrot
19:58 luben pmichaud, I know what causes MS2 GC performance variation in parrot 3.1
19:58 * KaeseEs fires up vmware to get at pdd32-m0.pod
19:58 cotto_work KaeseEs: no need for that
19:59 cotto_work KaeseEs: https://github.com/parrot/parrot/blob​/m0-spec/docs/pdds/draft/pdd32_m0.pod
19:59 luben It does not have dynamic (adaptive) triggering - it triggers every 10% of free memory that was allocated by parrot
19:59 luben on linux this means all memory - buffers - cache
20:00 luben so usually it is very little
20:00 luben when you rebooted, you actually freed buffers and cache
20:01 luben you chould achieve the same effect with "echo 2 > /proc/sys/vm/drop_caches"
20:02 luben in later parrots I have fixed that behaviour - the memory for GC is comuted as a fraction of all available memory
20:04 luben s/comuted/computed/
20:05 whiteknight luben: Okay, that's along the lines of what I thought it was
20:06 whiteknight but it's good to hear a real explanation
20:06 luben there was a bug in linux platform files
20:07 luben I think that I wrote mail to parrot-dev at that time
20:07 whiteknight the variances are interesting but they're in the past now. What is most concerning is the big slowdown between 3.0 and 3.1, and the smaller slowdown between 3.2 and 3.3
20:07 whiteknight that's something that we need to profile and understand aggressively
20:09 mj41 joined #parrot
20:09 luben execution time is not the only parameter of GC - peak memory usage is also very important parameter
20:09 luben we have mostly the same exec time but we manage with 1/3 of the memory
20:10 pmichaud luben: I'm not seeing variation in 3.1.  I'm seeing variation in 3.0.
20:10 pmichaud 3.1 is very self-consistent.
20:10 KaeseEs the textual representation of M0 looks comfortingly similar to MIPS r-type instructions
20:10 luben (comparing MS2-without dynamic triggering and GMS)
20:10 luben pmichaud, my fault - I was thinking about 3.0
20:11 pmichaud regardless, 3.0 is still consistently faster than 3.3.
20:11 cotto_work aloha: going to yapc::na?
20:11 aloha cotto_work: Dunno.
20:11 cotto_work aloha: going to yapc::na is cotto
20:11 aloha cotto_work: Okay.
20:11 cotto_work aloha: going to yapc::na is also dukeleto
20:11 aloha cotto_work: Okay.
20:11 pmichaud where's the "not going" list?
20:12 cotto_work sad face
20:12 luben pmichaud, but 3.0 wastes a lot more memory than 3.3
20:13 pmichaud luben: right now speed is far more important to us.
20:13 pmichaud (maybe not for parrot, though)
20:13 cotto_work KaeseEs: are you interested in being recruited for an M0 disassembler?
20:14 luben pmichaud, I am working to make this runtime option
20:14 luben also looking for better defaults
20:14 KaeseEs i don't know much about CPS except that a friend of mine who uses racket talks about it sometimes :(
20:15 dodathome left #parrot
20:15 pmichaud runtime option doesn't seem all that useful -- most people will be using the defaults
20:15 KaeseEs i don't have class on friday, i'll take a look then if someone else hasn't run with it yet
20:15 cotto_work KaeseEs: you won't need to care much about CPS for the disassembler.
20:15 cotto_work It's most relevant to the interp, and once dukeleto and I understand it fully, we'll document it quite thoroughly.
20:16 atrodo aloha: going to yapc::na is also atrodo
20:16 aloha atrodo: Okay.
20:16 KaeseEs ok.  i'll take a look at it.  forgive my wariness for telling people i've got tuits when finals are on the 16th :/
20:17 pmichaud aloha: not going to yapc::na is also pmichaud
20:17 aloha pmichaud: Okay.
20:17 pmichaud aloha:  not going to yapc::na
20:17 pmichaud aloha: not going to yapc::na?
20:17 aloha pmichaud: not going to yapc::na is pmichaud
20:17 cotto_work KaeseEs: no worries.  It won't block anything.  It'd be nice to have as a way to ensure that we can losslessly round-trip between the assembler and disassembler, but that's it.
20:17 * benabik is probably going to yapc::na, but hasn't made any arrangements yet.
20:18 KaeseEs cotto_work: makes sense
20:21 cotto_work aloha: going to yapc::na is also atrodo
20:21 aloha cotto_work: Okay.
20:21 atrodo aloha: going to yapc::na?
20:21 aloha atrodo: going to yapc::na is cotto or dukeleto or atrodo or atrodo
20:21 atrodo quite happy to put me in there twice.  I'm REALLY going
20:21 moritz when did parrot switch to git?
20:22 cotto_work atrodo: I expect both you and your clone.
20:22 bubaflub moritz: a while back. dukeleto handled the conversion
20:22 _dolmen_ joined #parrot
20:22 moritz bubaflub: sorry, I should have asked "what's the parrot parrot release made with git?"
20:22 benabik The last git-svn-id I see is e0da8738, on 10/5/10
20:22 tcurtis moritz: November of last year.
20:23 moritz s/parrot/first/
20:23 moritz thanks
20:23 tcurtis moritz: Which is 2.10, I think.
20:23 mikehh think it was the one tcurtis++ did, let me check
20:23 atrodo cotto_work> what if i bring atrodo 2.0, will that count?
20:23 cotto_work atrodo: sure.
20:24 atrodo cotto_work> Perfect!  Screaming boy in the sessions!  No one will hate me at all!
20:24 rohitnsit08 joined #parrot
20:24 rohitnsit joined #parrot
20:24 cotto_work atrodo: how's his code?
20:24 moritz tahsnk benabik and tcurtis
20:25 atrodo cotto_work> still trying to get him to not eat the keyboard.  so decent
20:25 * moritz can't type today
20:25 rohitnsit08 left #parrot
20:25 rohit_nsit08 left #parrot
20:26 mikehh moritz: definately 2.10 was the firest using git
20:26 rohitnsit left #parrot
20:26 rohit_nsit08 joined #parrot
20:27 rohit_nsit08 hello #parrot
20:28 cotto_work #ps at now
20:28 moritz I'll try to extend my graph (see parrot-dev) to 2010.{11,12}
20:28 moritz but it'll take some time
20:28 davidfetter #parrotsketch ?
20:28 whiteknight left #parrot
20:29 * davidfetter contemplates irc channel aliases
20:29 mikehh davidfetter: for sure
20:33 atrodo pmichaud> If you have anything you want to see from isparrotfastyet.com or have any suggestions, I'd love to know
20:37 pmichaud atrodo: I don't yet understand that site
20:37 pmichaud afk, errands
20:38 atrodo pmichaud> That's good to know.  Thanks
20:39 bubaflub atrodo: how much data do you have in the past?  it might help us determine some of the slow-downs
20:44 atrodo bubaflub> I should have all the releases for 2010, plus everything after 2010-12-3
20:44 atrodo bubaflub> although, i thought i had more then that
20:44 bubaflub atrodo: great - that should be useful in figuring out exactly when the slowdown from 3.0 to 3.3 occured
20:45 moritz to me it looks like the bulk of the slowdown was between 3.0 and 3.1
20:45 moritz http://moritz.faui2k3.org/tm​p/rakudo-perl-2011-05-03.png
20:45 moritz see my last parrot-dev mail of more details
20:45 moritz but don't trust my data yet - I'll have more reliable data tomorrow
20:46 Util aloha: going to yapc::na is also Util
20:46 aloha Util: Okay.
20:54 dalek nqp/ctmo: 932f6da | jonathan++ | src/ (2 files):
20:54 dalek nqp/ctmo: Make sure derived dispatchers are fixed up. Fixes the last two test regressions in the ctmo branch after the full switch to using compile time meta-objects.
20:54 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/932f6dae6a
20:57 plobsing NotFound: never mind. the -I switch appears to be working for me now. not sure what I was doing wrong
20:57 NotFound plobsing: k
20:58 dalek nqp/ctmo: 61e5ea0 | jonathan++ | src/stage0/ (6 files):
20:58 dalek nqp/ctmo: Update bootstrap.
20:58 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/61e5ea04cd
21:05 M_o_C joined #parrot
21:08 darbelo joined #parrot
21:08 dalek Heuristic branch merge: pushed 20 commits to nqp by jnthn
21:09 darbelo left #parrot
21:10 darbelo joined #parrot
21:11 ambs left #parrot
21:27 mj41 left #parrot
21:36 luben atrodo, it will be great to have option to switch scales, eg week, month, year for http://isparrotfastyet.com/
21:37 darbelo_ joined #parrot
21:38 M_o_C left #parrot
21:39 NotFound (moved from #ps) Testing with ohm-eta should be easy, and more realistic than an artificial test.
21:41 benabik Some artificial benchmarks might be useful in pegging performance changes in particular sections of parrot.  Real programs are good for pointing out when problems occur, but its sometimes difficult to figure out what underlying change caused it.
21:41 plobsing The lightest test would be to run the precompiled tests. Medium would be to compile those tests. Heavy would be the bootstrap stage.
21:41 plobsing What time-range do we want our benchmarks to run in?
21:42 darbelo left #parrot
21:42 NotFound For a start, we should find a test that mimics the pattern observed with rakudo.
21:43 mikehh in one sense yes, but I think we need general benchmarks as well
21:43 NotFound If ohm-eta does it, we can bisect it.
21:44 plobsing so the pattern we're looking for was with all the released versions from 3.0 through 3.3?
21:45 mikehh and see if we catch a hiccup somewherte between 3.0 and 2.1
21:45 NotFound mikehh: yes, but isolating first the known problem may be the better way.
21:45 mikehh 3.1
21:46 mikehh NotFound: sure, but I was also thinking long term as well (for later)
21:47 fperrad left #parrot
21:47 NotFound I'm definitely open to any plan involving more winxed usage ;)
21:49 mikehh NotFound: I agree, I think you have something positive there (in winxed that is)
21:50 plobsing I'm going to have to build all the release versions of parrot. It'll be a little while before I can give any results
21:53 mikehh also might need to track branch merges between 3.0 and 3.1
21:54 dalek nqp: 8bffb73 | jonathan++ | / (11 files):
21:54 dalek nqp: Some PBC renaming so we can install without trampling on things already in Parrot's library directory.
21:54 dalek nqp: review: https://github.com/perl6/nqp/commit/8bffb73fca
21:54 dalek nqp: 53e7266 | jonathan++ | src/stage0/ (6 files):
21:54 dalek nqp: Update bootstrap after renaming.
21:54 dalek nqp: review: https://github.com/perl6/nqp/commit/53e7266aa2
22:32 bubaflub left #parrot
22:33 bluescreen left #parrot
22:36 cotto_work NotFound: ping
22:36 cotto_work aloha: clock?
22:36 aloha cotto_work: LAX: Tue, 15:36 PDT / CHI: Tue, 17:36 CDT / NYC: Tue, 18:36 EDT / UTC: Tue, 22:36 UTC / LON: Tue, 23:36 BST / BER: Wed, 00:36 CEST / TOK: Wed, 07:36 JST / SYD: Wed, 08:36 EST
22:36 NotFound cotto_work: pong
22:36 cotto_work NotFound: what (if any) support for regexes does winxed have?
22:40 NotFound cotto_work: there is no direct support.
22:40 cotto_work NotFound: ok
22:41 NotFound BTW, I don't know what the plans are. If tge gets deprecated and killed, Is there any way to use regexes other than nqp?
22:42 cotto_work tge has been on life support since I joined the project, but it's been very stable throughout that time.
22:43 cotto_work We most likely won't kill it while Lua still uses it.
22:44 Andy left #parrot
22:44 hercynium left #parrot
22:44 Tene cotto_work: you could always dlopen libpcre
22:44 cotto_work Tene: sure.  That's an option.
22:46 kid51 joined #parrot
22:47 whiteknight joined #parrot
22:51 kid51 aloha: going to yapc::na is also kid51
22:51 aloha kid51: Okay.
22:56 whiteknight Is anybody looking at the performance issues right now?
22:58 NotFound whiteknight: plobsing said he's going to install the relevant parrot versions and test them with ohm-eta.
22:58 whiteknight NotFound: that's perfect
22:58 whiteknight the first thing we really need to do is isolate the problem to Parrot and not Rakudo
22:59 whiteknight plus, it can't hurt to have a benchmark that doesn't take quite so long to run
23:00 cotto_work whiteknight: plobsing wanted to talk about concurrency.  I said he should catch you.
23:01 whiteknight okay, awesome
23:01 whiteknight I always like talking to plobsing
23:01 cotto_work If the boths of yous are here, now'd be a great time.
23:05 whiteknight ENOPLOBSING
23:06 cotto_work well nuts
23:11 whiteknight I'm still up for talking. Let's talk.
23:11 whiteknight how about that local sports team?
23:12 whiteknight I hear they are doing differently from what was expected of them
23:12 cotto_work I hear they've got a chance for that big event.
23:13 cotto_work whiteknight: how much time do you spend blogging per day?
23:13 whiteknight cotto_work: depends. Most days I don't do it at all
23:13 whiteknight I have a very large pile of half-finished drafts. When it's time to post, I put some polish on them
23:16 whiteknight I used to keep a daily blog/journal for personal stuff. I gave that up, but still have the urge to write pretty frequently
23:16 darbelo_ left #parrot
23:16 whiteknight I gave up poetry because I suck at it, so all I've got left is my technical blog
23:17 darbelo joined #parrot
23:17 whiteknight I had a series of professors in college who were very persuasive about the need to write frequently
23:18 cotto_work I guess it worked.
23:19 cotto_work good for them\
23:20 whiteknight Inspiration comes in waves though. Some days I have a lot to talk about and I write up several drafts at once. Other days I have nothing to say, so I sit around like  lump
23:21 cotto_work on an unrelated note, are you planning on yapc::na?
23:21 whiteknight unfortunately, not this year. We're trying to buy a house, and I'm saving my vacation time for that
23:21 whiteknight next year is a distinct possibility
23:22 cotto_work aloha: not going to yapc::na is also whiteknight
23:22 aloha cotto_work: Okay.
23:22 cotto_work That's too bad, but that's also exciting for you.
23:23 whiteknight It is too bad, really. I really liked YAPC when I went
23:24 cotto_work and I like hanging out
23:24 whiteknight yeah, it was fun to meet you and the rest of the team
23:24 whiteknight extremely high bandwidth
23:24 cotto_work btw, Randall Schwartz was at the Parrot talk.  It was a trip to have him in the audience.
23:24 whiteknight oh really? that's awesome
23:25 whiteknight so there wasn't a video of it or anything?
23:25 whiteknight transcript? powerpoint slides?
23:25 cotto_work no video, though I'll post my slides
23:25 whiteknight second hand account from a guy who knew a guy who was there?
23:25 cotto_work http://mksig.org/slides/lfnw2011/
23:25 whiteknight I'm jonesing for more cotto
23:25 kid51 is now known as kid51_at_dinner
23:26 whiteknight cotto++
23:28 whiteknight nice presentation
23:29 nopaste "plobsing" at 192.168.1.3 pasted "Ωη-bench" (5 lines) at http://nopaste.snit.ch/43358
23:29 whiteknight <parrot git:master> ./parrot examples/benchmarks/stress3.pasm
23:29 whiteknight A total of 76269849 GC runs were made
23:29 plobsing oh hai. i haz can haz benchmark
23:29 cotto_work plobsing: awesome.  We have a small test case!
23:29 whiteknight I suspect that number is a lie
23:30 whiteknight plobsing++
23:30 darbelo left #parrot
23:30 cotto_work plobsing++
23:30 whiteknight it's good to isolate the problem from Rakudo
23:30 plobsing cotto_work: only if the pattern is the same. there is a large jump between 3.0 and 3.1, but the rest isn't correlated so well
23:30 whiteknight and it's good to have a test case that runs in less than 5 minutes
23:31 whiteknight its correlated well enough. the only way to perfectly match the Rakudo usage pattern is to use Rakudo
23:31 cotto_work It looks good for the first slowdown.
23:31 plobsing Ωη is close though. the parsing algo is very similar, and it makes use of exceptions
23:32 cotto_work yup
23:32 whiteknight okay. Let's get valgrind up in this biznatch. I guess I need to get ohm-eta to run the benchmark?
23:33 * cotto_work hopes to see some concurrency talk now that plobsing and whiteknight are both online
23:33 plobsing yep. and you'll need winxed to build it (but not to run)
23:34 whiteknight plobsing: yeah, what's on your mind for concurrency?
23:34 plobsing whiteknight: I've been reading your concurrency blog posts.
23:35 plobsing what you describe is very similar to the architecture we have now (other than the whole not working thing), SFAICT.
23:35 whiteknight plobsing: we don't really have any mechanism for tasks/greenlets
23:36 plobsing we have a scheduler with tasks
23:36 whiteknight and we don't have any data sharing mechanism whatsoever
23:36 whiteknight and our threads are extremely heavy weight, and require cloning the interp
23:36 plobsing we have a message passing architecture
23:36 whiteknight do we?
23:37 plobsing Parrot_cx_send_message()
23:37 whiteknight does that work? Is it used? I mean, I know we have SchedulerMEssage PMC or whatever it's called
23:38 whiteknight and in either case, whether what we have is a vague shadow of what I suggested or not, the work to fix it is probably less than the effort just rewrite it correctly
23:40 plobsing I think working to bring the current framework up to the task has its advantages.
23:41 plobsing It makes considerations for things you haven't mentioned (so I assume you haven't thought about yet)
23:41 plobsing such as OS signals, asynchronous NCI callbacks, etc
23:41 whiteknight I glossed over those things, but I have thought about those plenty
23:41 whiteknight I talked with lucian about those the other day
23:44 whiteknight There are a lot of implementation details that I glossed over
23:45 plobsing but I'm more concerned about the timeline. sure 4.0 or later is acceptable for user-exposed threads, but we can get a lot of mileage out of internals which have a coherent thread-safety strategy
23:45 plobsing even if we're not exposing that to HLLs
23:45 whiteknight do you think our current system represents a "coherent thread-safety strategy"?
23:46 whiteknight I've never seen any bit of it that inspired any kind of confidence
23:46 whiteknight now, if you're up for rewrting the system, and rearranging the timeline, that's fine. The timeline was all hypothetical
23:47 whiteknight like I said, those posts were more an attempt to get the conversation started than a final plan in itself
23:47 plobsing No. The current system far from coherent.
23:47 whiteknight okay
23:47 plobsing There are parts that pay attention to threading, and others that pay no mind
23:48 whiteknight the big problem right now is that the current threading system has been in disrepair for so long that the rest of Parrot has moved on without it
23:48 plobsing we have mutexes in some places, but the allocator, by far the most used susbsystem, is totally exposed
23:49 whiteknight I ripped out the old STM implementations with my bare hands, and nothing broke
23:49 whiteknight no tests failed. No code outside the stm files needed to be changed at all
23:49 plobsing I'm not talking about user-exposed threads. I'm talking about things like embedding in a threaded webserver like apache.
23:49 whiteknight right
23:50 whiteknight okay, so what do you propose? We start with an OS-threading implementation first, and build tasklets on top of that later?
23:50 whiteknight I'm assuming that part of the OS-threading implementation is pervasive thread safety
23:53 plobsing we need the pervasive thread safety before anything, so I think that's where we should start
23:54 whiteknight well, my thinking is that we don't know the system is pervasively thread safe without starting to implement and use threads
23:54 whiteknight that is, make threads, make a suite of tests for threads, fix all test failures, etc
23:57 plobsing we know the other parts and how they fit together currently. we can find a lot of structural problems without even testing.
23:58 whiteknight this is true. No argument there. we can definitely fix some glaring errors
23:58 whiteknight for something like the PMC allocator however, we need a long-term plan for the GC before we attempt that
23:58 whiteknight for instance, do we have per-thread GC? Or do we have a separate GC thred?
23:58 whiteknight or a single stop-the-world global GC?
23:58 plobsing yes, that's the kind of decisions we need to be making
23:59 whiteknight each of them are going to have different strategies for making a thread-safe allocator
23:59 whiteknight I purposefully glossed over GC in my posts, but I'm a big fan of a concurrent algorithm for GC
23:59 whiteknight if the system supports enough threads, devote one to GC
23:59 plobsing and all of that has nothing to do with what flavour of threads HLLs deal with

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

Parrot | source cross referenced