Camelia, the Perl 6 bug

IRC log for #parrot, 2011-09-08

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 Coke chromatic: how's life treating ya?
00:01 chromatic Won't complain. You?
00:08 dalek parrot: 0d3638b | chromatic++ | src/pmc/callcontext.pmc:
00:08 dalek parrot: [PMC] Improved autobox_intval performance.
00:08 dalek parrot:
00:08 dalek parrot: Avoiding the switch where there's no need to autobox is in fact significant in
00:08 dalek parrot: this hot path.
00:08 dalek parrot: review: https://github.com/parrot/parrot/commit/0d3638b8d3
00:08 dalek parrot: 09bfabf | chromatic++ | .gitignore:
00:08 dalek parrot: Added exclusions for callgrind/cachegrind files.
00:08 dalek parrot: review: https://github.com/parrot/parrot/commit/09bfabfbbf
00:08 dalek parrot: 185158c | chromatic++ | src/call/context.c:
00:08 dalek parrot: Optimized register allocation slightly.
00:08 dalek parrot:
00:08 dalek parrot: When there's no need to allocate register memory, waste no time not
00:08 dalek parrot: initializing the non-allocated registers.
00:08 dalek parrot: review: https://github.com/parrot/parrot/commit/185158cecb
00:09 chromatic Not a lot of LHF today. That GC tuning has some promise, but on the order of 2.5% for a reasonably GC heavy program.
00:10 dukeleto chromatic: it is wonderful to see commits from you again
00:11 Coke chromatic: pretty good. Need to get back on the diet snapple.
00:17 dalek Rosella: 3cb2ac0 | Whiteknight++ | src/harness/ (4 files):
00:17 dalek Rosella: Start refactoring the TAP parsing portions of the harness
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/3cb2ac074b
00:17 dalek Rosella: 4e73dab | Whiteknight++ | s (3 files):
00:17 dalek Rosella: Several fixes so we build
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/4e73dab1ea
00:17 dalek Rosella: 644c62b | Whiteknight++ | src/harness/ (7 files):
00:17 dalek Rosella: Several failures so we run the harness again, with bugs
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/644c62b135
00:17 dalek Rosella: a4e0ae3 | Whiteknight++ | src/ (4 files):
00:17 dalek Rosella: Several fixes, still not working correctly
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/a4e0ae3b10
00:17 dalek Rosella: 7231fab | Whiteknight++ | src/harness/ (4 files):
00:17 dalek Rosella: Several fixes so we can run a toy example again
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/7231fab61e
00:17 dalek Rosella: 4b38a6c | Whiteknight++ | / (4 files):
00:17 dalek Rosella: Fix error messages. The full test suite runs like normal again
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/4b38a6c3eb
00:17 dalek Rosella: 4bf2081 | Whiteknight++ | src/ (2 files):
00:17 dalek Rosella: refactor pipes a little
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/4bf2081356
00:17 dalek Rosella: 2c0bb86 | Whiteknight++ | src/harness/testfile/ (2 files):
00:17 dalek Rosella: Remove two files that aren't being used anymore
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/2c0bb86a77
00:17 dalek Rosella: 65294db | Whiteknight++ | s (4 files):
00:17 dalek Rosella: Remove TestRun.ResultSet. Replace most of the logic in TestRun with cleaner query statements. It's less efficient, but we only do this once at the end of the run
00:17 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/65294dbedd
00:19 dukeleto github really spiffed up their web ui recently
00:19 cotto_work lta for some commits, but I like it overall
00:20 cotto_work https://github.com/mlschro​e/parrot/commit/bdbfc213e5 for instance
00:31 dukeleto msg atrodo it would be hella awesome if clicking on data points on IPFY would link to the github commit diff of that commit. If you don't have time, point me in the right direction and I will try to make it work
00:31 aloha OK. I'll deliver the message.
00:34 dukeleto msg atrodo also, we need zooming on IPFY. It looks like you are using Flot, and I have done that before. Is that cool with you?
00:34 aloha OK. I'll deliver the message.
00:35 dukeleto msg whiteknight according to http://isparrotfastyet.com , the pmc_is_ptr merge caused a 22% speedup in stress1. Nice work.
00:35 aloha OK. I'll deliver the message.
00:41 Coke failing in t/pmc/select.t test.
00:41 Coke er, dynpmc
00:43 Coke http://smolder.parrot.org/app/​projects/report_details/22654
00:44 soh_cah_toa joined #parrot
00:46 soh_cah_toa whiteknight: ping
00:46 whiteknight pong
00:46 whiteknight dukeleto: It's amazing that such an innocuous thing was such a drag
00:47 plobsing dukeleto: there is zooming in ipfy. use the sparklines bellow the main graphs
00:47 soh_cah_toa whiteknight: being this month's release manager, i gotta find some info about whiteknight/kill_threads and whiteknight/frontend2
00:47 soh_cah_toa whiteknight: so tell me about the new frontend. why did we need a new frontend and what's new about it?
00:48 dukeleto plobsing: i see now, it isn't quite zooming, more like data selection. But it is close.
00:48 whiteknight soh_cah_toa: because I said so, and I basically pushed around a bunch of stuff randomly
00:48 whiteknight soh_cah_toa: just kidding
00:48 soh_cah_toa :)
00:49 whiteknight soh_cah_toa: the big motivation was the handling of :init flags. Previously, :init subs were executed automatically during packfile load and each one created a nested runloop
00:49 whiteknight soh_cah_toa: by bootstrapping into PIR early and calling the :init subs there, we can avoid nested runloops
00:49 whiteknight also, we can avoid a lot of embedding API calls, which are not and never were intended to be performance conscious
00:50 whiteknight plus, exception handling is much more natural in PIR than it is in C, etc
00:50 soh_cah_toa whiteknight: forgive my ignorance but what's wrong w/ nested runloops?
00:51 plobsing and then there's the advantage of dogfooding. if we do as much as possible in parrot, it shows us the limits of parrot's capabilities (which we then push further out).
00:51 whiteknight soh_cah_toa: performance. See http://whiteknight.github.com/2011/​05/10/timings_vtable_overrides.html
00:51 whiteknight plobsing: yes, that's a good point. It wasn't one of my motivations, but it is a nice side-effect
00:51 dukeleto whiteknight: i am not sure i believe the big performance change now. I looked into other huge performance changes on IPFY, and they were doc changes. I think the VM that the tests are being benchmarked is not stable
00:51 whiteknight for instance, there has long been a problem, and a lingering misunderstanding, that we can't create valid .pbc files from PIR code
00:52 whiteknight the new frontend demonstrates that we can
00:52 soh_cah_toa ok
00:52 whiteknight dukeleto: Rakudo folk confirmed at least some kind of speedup. I'm still going to call it a net win
00:52 dukeleto msg atrodo some huge performance changes on ISPY are for documentation changes, such as 792a1398. What kind of VM are those benchmarks running?
00:52 aloha OK. I'll deliver the message.
00:53 plobsing dukeleto: ipfy has a high signal to noise ratio, and has had it since its inception
00:53 whiteknight dukeleto: ISPY might not be showing all commits, but a random sampling of them
00:53 plobsing ispy?
00:53 plobsing with my little eye?
00:53 dukeleto plobsing: http://isparrotfastyet.com
00:54 dukeleto IPFY, rather.
00:54 dukeleto derp
00:55 soh_cah_toa whiteknight: alright, what about kill_threads? what's the dillyo?
01:02 whiteknight soh_cah_toa: that one is tricky
01:02 whiteknight we're going to kill_threads
01:02 soh_cah_toa why?
01:02 whiteknight soh_cah_toa: it's the only humane option left. The threads are suffering
01:03 whiteknight it's a really bad implementation with tons of bugs, and we've had those bugs for years
01:03 cotto_work how soon's the release?
01:04 soh_cah_toa cotto_work: the 20th
01:04 cotto_work less than 2 weeks.  I wonder if that'll be long enough to get the sub profiler into shape for a merge
01:05 soh_cah_toa whiteknight: so we're nuking our current threading implementation and a) doing a rewrite or b) leaving it be w/ no threads?
01:05 chromatic It didn't look too far from merge to me, cotto_work.
01:06 whiteknight soh_cah_toa: we want a replacement. The current system is both a source of bugs in multiple other subsystems, and is not amenable to developing a replacement in parallel
01:06 soh_cah_toa alright
01:06 cotto_work chromatic: that's encouraging, though it depends on when mls stops adding features
01:06 Coke partcl doesn't care if you nuke threads before replacing it.
01:07 preflex_ joined #parrot
01:07 soh_cah_toa whiteknight: have you noticed a decrease in runtime performance at all in your branch w/o threads?
01:19 whiteknight soh_cah_toa: no decrease.
01:19 soh_cah_toa impressive
01:19 whiteknight Coke: I don't know much about Tcl or it's concurrency needs. Could you point me in a good direction to learn about it?
01:21 soh_cah_toa whiteknight: http://www.tcl.tk/doc/howto/thread_model.html
01:23 whiteknight smartypants
01:23 whiteknight soh_cah_toa++
01:23 soh_cah_toa had that bookmarked for some reason :\
01:24 soh_cah_toa whiteknight: also, does whiteknight/frontend_parrot2 build for you? i get an error w/ winxed.pbc which, oddly enough, i also got on soh_cah_toa/podds
01:24 soh_cah_toa oh, i think i gotta re install
01:24 soh_cah_toa b/c of that whole pbc thing w/ hbdb blah blah blah
01:25 soh_cah_toa nevermind ;)
01:25 Coke whiteknight: partcl hasn't done anything with threading on parrot yet, which is why you get a pass.
01:27 cotto_work It's a chicken and egg problem.  Hopefully nine can hatch something soon.
01:29 whiteknight Coke: Okay, then we'll make sure the new system is compatible with tcl's model, and make a gift
01:29 whiteknight cotto_work: it won't just be nine. We'll assemble a group of highly skilled code ninjas around him to help out
01:33 atrodo dukeleto: ping
01:38 dukeleto atrodo: pong
01:39 atrodo dukeleto: In reverse order.  The machine that IPFY is running is my old P4 that only runs that.  The oddity you saw, i think, is the fact that I only benchmark the head of a pushed commit, not every single commit
01:40 dukeleto atrodo: ok, that makes more sense
01:40 atrodo so that documentation point that you saw, if it's what i remembered, had several commits behind it
01:41 atrodo And yes, I'm using flot, and I did the "zooming" with the data range selection.  was never real happy with how that turned out.
01:41 dukeleto atrodo: you seem to have selection, but not zooming. I can't quite "zoom into" 3 data points. Only selection the commit range
01:41 atrodo dukeleto: right
01:41 dukeleto atrodo: i am thinking of something like: http://people.iola.dk/olau/​flot/examples/zooming.html
01:42 atrodo And I agree on the points to github.  Just never did it
01:42 atrodo dukeleto: Neat.  I like that a bit more
01:42 dukeleto atrodo: how would you feel about modifying IPFY to bench every commit in a push? I know it adds some complication, but I think it is worth it.
01:43 atrodo dukeleto: It's more of an issue with how long it takes to benchmark.  Building and running both parrot and rakudo takes, i want to say, upwards of half an hour each
01:43 atrodo not against it, that was just the motivation
01:44 dukeleto atrodo: jitterbug has code that you can probably steal, which eats github post-receive json and an option to run code on only the tip of the push, or all commits in the push
01:44 atrodo dukeleto: Yea, not a hard thing to change
01:44 dukeleto atrodo: would it be possible to only run on every commit on parrot.git, but run only on commit tips for rakudo ?
01:45 atrodo dukeleto: actually, when I get a parrot commit, i find the closest rakudo that was before the parrot commit
01:49 dukeleto atrodo: ok. so does that mean if we make parrot bench every commit, it won't make rakudo do the same?
01:49 dukeleto atrodo: i think it is really important for parrot to know the exact commit that causes a performance change
01:49 dukeleto atrodo: i am going to try to add the github-link thing now. I forked itfy.git
01:49 atrodo dukeleto: correct.  Parrot is the "parent" project, and rakudo is the "dependent" project
01:50 atrodo dukeleto: Yea, apparently i have quite a few outstanding changes.  thought I had cleaned that up, but apparently not
01:51 dalek Rosella: d49252c | Whiteknight++ | s (4 files):
01:51 dalek Rosella: Add in a new prototype Stream queryable. It takes any iterable object and iterates over it lazily.
01:51 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/d49252ce86
01:54 chromatic One difficulty of profiling Rakudo wrt Parrot is that Rakudo isn't a fixed point itself.
01:55 chromatic In other words, benchmarking two moving targets against each other isn't technically science. It's climatology.
01:56 plobsing I had an idea about testing/benchmarking rakudo vs parrot commits in 2 dimensions, but it would require more compute resources than I have.
01:57 pmichaud_ however, Rakudo in 2011 has thus far been largely fixed.
01:57 pmichaud_ Any changes in the rpbench reports are primarily due to changes in Parrot.
01:58 chromatic Depends if the tests run against master or nom, right?
01:58 pmichaud_ all of the rpbench reports and statistics I reported were against master.
01:58 pmichaud_ We haven't started nom results.  I agree that those will be apples-to-oranges comparisons.
01:59 pmichaud_ I can build versions of ng against Parrot and see how Parrot performance has changed over that time, though.
01:59 atrodo dukeleto: I just pushed to itfy with the newest code
02:00 woosley joined #parrot
02:04 dukeleto atrodo: woot
02:11 cotto ~~
02:25 benabik joined #parrot
02:32 soh_cah_toa msg whiteknight checkout soh-cah-toa/podds and see my comment in src/packfile/api.c +1779 "how do we specify what dde to read? by offset? by address?"
02:32 aloha OK. I'll deliver the message.
02:34 benabik o/
02:40 soh_cah_toa msg cotto i'm thinking of making the 17th our bug day and code freeze day. do i let people know beforehand or on the 17th? docs/project/release_manager_guide.pod says to do so the day of but i think it makes more sense to bring it up at the next #ps and then email parrot-dev
02:40 aloha OK. I'll deliver the message.
02:41 cotto I'm here
02:41 cotto d'oh
02:41 benabik msg panda Was reading through backlogged messages.  If you like power of dynamic language but want C/C++ speed, that's exactly what Lua was designed for.  Write speed-sensitive subsystems in C and bind them together with Lua.  I know several game companies are using that method (Blizzard, Telltale Games)
02:41 aloha OK. I'll deliver the message.
02:42 benabik Don't know if he'll be back, but thought that might be an interesting thing for him to know.
02:44 cotto msg soh_cah_toa bugdays are mostly historical at this point.  I can't remember having done one.  You're welcome to call one, of course.
02:44 aloha OK. I'll deliver the message.
02:47 benabik We need to kill that select test.  It should reincarnate into something using sockets, which is sane to use in select instead of files, which are not.
02:53 benabik (I'm just throwing out comments as I backlog in the theory that someone else might backlog and see them.  :-)
03:00 schmooster joined #parrot
03:07 Khisanth joined #parrot
03:11 Coke I just did: http://feather.perl6.nl/~coke/bench/html/
03:12 Coke (many things needs fixing, but that's a first pass at flotifying https://github.com/pmichaud/rpbench-results/b​lob/master/kiwi-x86_64-2877m-201105200238.txt
03:15 pmichaud_ it would also be good to look at orange or plum, which are more typical in terms of processor/memory
03:16 pmichaud_ kiwi is a particularly fast machine (8GB ram, 6 cores)
03:16 Coke pmichaud_: I could, I suppose, have 3 charts, one for each processor.
03:16 pmichaud_ that would be awesome
03:17 pmichaud_ also note that I sometimes run kiwi with smaller memory footprints
03:17 Coke yah, not showing any information about the processor (which you have accessible.)
03:25 plobsing joined #parrot
03:30 JimmyZ joined #parrot
03:34 dukeleto Coke: nice work on Is Rakudo Fast Yet!
03:35 dukeleto Coke++
03:48 Khisanth joined #parrot
03:50 Khisanth joined #parrot
04:20 davidfetter joined #parrot
04:36 Tene plobsing: I've got a server that doesn't do much, if you want to use it to compile statistics.
04:45 JimmyZ_ joined #parrot
04:46 cotto dukeleto, ping
05:00 dukeleto cotto: pong
05:00 cotto dukeleto, what did you mean when you said we should start distancing ourselves from Rakudo?
05:00 cotto If it means trying to encourage other HLLs, that's great, +1, etc.  Parrot shouldn't have Rakudo as the only major HLL that runs on top of it.
05:00 dukeleto cotto: i guess i meant something like disentangling
05:01 dukeleto cotto: and to focus on interop of languages other than perl 6
05:02 cotto dukeleto, disentangling sounds like more marketing than anything.  Is that what you mean?
05:04 dukeleto cotto: not sure. what do you mean by marketing?
05:05 cotto dukeleto, dealing with how people perceive Parrot
05:06 dukeleto cotto: it has a lot to do with that, but there is a specific kind of product snuggled inside the marketing
05:06 dukeleto cotto: a kind of product parrot needs
05:06 cotto dukeleto, libparrot?
05:06 dukeleto cotto: something that some free/open source community will find useful
05:07 dukeleto cotto: tell me a story about libparrot
05:07 dukeleto cotto: i see some similarities between libgit2 and libparrot, in the niches that they fill
05:08 cotto dukeleto, interesting parallel
05:08 dukeleto cotto: "there was once a pile of code, now we are making it a library"
05:08 dukeleto cotto: the internals of git 1.x makes IMCC look shiny
05:09 dukeleto cotto: git 1.x is an extremely well-tested hairy ball of /bin/sh and perl 5.8.x, with no hope of ever being being linkable
05:10 dukeleto cotto: who would use libparrot and what would they use it for?
05:10 cotto dukeleto, that's the impression I have
05:11 sorear dukeleto: plparrot is the first "real" project that comes to mind
05:13 sorear dukeleto: how about vim?  it currently embeds, optionally, Perl, Tcl, Lua, Ruy, Python, and Scheme.  What if a vim-like project could just bind Parrot instead?
05:13 dukeleto sorear: mod_parrot was the first to embed parrot. But I don't think anybody these days want to use mod_perl, much less mod_parrot. PL/Parrot was the next to embed parrot, but I have had a hard time finding people who want to use stored procedures
05:14 sorear dukeleto: why, has everyone switched to mod_fcgi?
05:14 dukeleto sorear: vim might apply a patch to optionally embed parrot. could be a fun project
05:15 dukeleto sorear: stored procedures are a pain to maintain and test. Most people only use them if they are forced to because of speed, and then they are in C or Perl depending on masochism-level
05:18 sorear stored procedures improve speed?  how?
05:18 sorear (but I was asking about mod_parrot)
05:21 dukeleto rblackwe++ also suggested embedding into screen
05:21 dukeleto sorear: i never met anybody that actually used mod_parrot for anything
05:21 sorear dukeleto: why don't prople use mod_perl?
05:21 * sorear plugs tmux
05:22 dukeleto sorear: people write stored procedures in C for postgres for speed
05:24 dukeleto sorear: i would greatly enjoy seeing parrot embedding in tmux. There is a shiny new embed api...
05:25 dukeleto sorear: mod_perl is also a huge pain to admin and manage. Few people actually need to poke into apache request internals, or know how perl interpreters work
05:26 dukeleto sorear: they just want to sell snake-oil and serve adds. web frameworks do that quite well :)
05:29 dukeleto i finally got Firefox 5 to eat all my RAM. Thanks, github.
05:29 cotto dukeleto, could you post a quick response to jimmy on parrot-dev clarifying what you mean by distancing?  I was going to respond, but I don't want to speak for you.  I think he got the wrong imporession.
05:29 cotto github's great for that
05:30 dukeleto cotto: i haven't read the message, may wait until morning
05:30 cotto dukeleto, wfm
05:30 cotto I just don't anyone to think that we're suddenly going to stop caring about Rakudo.
05:32 dukeleto cotto: no, i wasn't trying to say that. But I figured some people would take it that way.
05:32 dukeleto cotto: currently trying to get m0 to not peg a core on nbrown++'s new pull request
05:33 Tene I used mod_parrot for a few toy apps.
05:33 Tene I gave a presentation on it, and showed a toy mod_lolcode app.
05:34 Tene dukeleto: I think you'll have a big challenge getting parrot folks to care about language interop, personally.
05:34 sorear Parrot suffers from Perl 6's negative reputation in some circles.
05:34 Tene I rather agree with you, though.
05:34 dukeleto Tene: i care about language interop
05:35 sorear If we disassociate Parrot's brand from Perl 6, will it make people in general take Parrot more seriously?
05:35 sorear that is the question that needs asking
05:35 dukeleto Tene: we need a test suite that loads pbc from different HLLs and then converts data between them and calls out to functions between them
05:35 dukeleto sorear: yes
05:35 pmichaud_ I think that disassociating Parrot's brand from Perl 6 was part of the reason for "kicking Rakudo out of the nest".  I don't think it worked.
05:35 dukeleto Tene: we can even have fudge tests, because a lot of those tests can be generated by smart test-writing code
05:36 Tene dukeleto: I've gone into substantial detail about plans to get HLL interop working again several times over the past few years, offered to mentor and assist, etc, and nobody's ever taken me up on it or done any work on it.
05:36 cotto dukeleto, sounds fun
05:36 cotto dukeleto++
05:36 pmichaud_ I think the question is not only "if we disassociate", but also "is it even possible"?
05:36 pmichaud_ I think the experience of the past two years may show that it's not really possible.
05:37 dukeleto Tene: so what if I take you up on it?
05:37 dukeleto pmichaud_: disentangle, not disassociate
05:37 pmichaud_ dukeleto: sorear's question was "disassociate"
05:37 dukeleto pmichaud_: the word distancing was imprecise and I am sure, misunderstood
05:37 pmichaud_ with respect to branding.
05:37 dukeleto pmichaud_: i don't think parrot's failures have anything to do with rakudo leaving the nest
05:38 cotto I hate it when code compiles on the first try.  It makes me feel like there's something worse than a compile-time error lurking in wait.
05:39 Tene dukeleto: I've always said that I'm always glad to help anyone else pick up that work.  pmichaud currently tells me that if I contribute any HLL interop code to rakudo, it'll be dropped on the floor if any refactors or replacements touch it, so I'm very reluctant to do it myself right now.
05:39 SHODAN joined #parrot
05:39 pmichaud_ that's not really what I said, although I admit it could be taken that way :)
05:39 dukeleto Tene: parrot needs interop work in the internals more than rakudo needs interop with parrot, right now
05:39 cotto Tene, could you sketch your thoughts on a wiki page?
05:40 dukeleto Tene: what are the top things that you would change about parrot internals to facilitate hll interop?
05:40 dukeleto Tene: pretend the dep policy doesn't exist, and you have a running chainsaw in your right hand
05:40 dukeleto Tene: and possibly dynamite
05:40 Tene dukeleto: replace the object model with 6model.
05:41 Tene that's the only thing that's really relevant at all; parrot's internals support HLL interop just fine, and have for years.
05:41 dukeleto pmichaud_: i think parrot needs a product that is not perl 6 related, and I think Rakudo will flourish without "parrot and rakudo" pretending to be the same project
05:42 dukeleto Tene: i agree with you, and i think most parrot devs do too, so why isn't the code written?
05:43 Tene dukeleto: I wrote it, more than once.
05:47 pmichaud_ the code's been written.  It's not been maintained.
05:47 pmichaud_ that's of course my (nqp + rakudo's) fault, since we've done some rewrites and refactors that didn't preserve the code.
05:47 pmichaud_ in the case of nom, what existed in earlier versions of rakudo wouldn't make sense anyway.
05:48 sorear dukeleto: I'm trying to keep the distinction between disassociate and disentangle
05:48 sorear dukeleto: I think Rakudo and Parrot are anti-tangled
05:49 sorear Rakudo generally tries to use as few Parrot features as possible
05:50 sorear it's also my fault, I removed hll interop while trying to get blizkost working.  (Why didn't anyone yell at me at the time?)
05:53 Tene sorear: it was long since dead at that point.
05:54 dukeleto Tene: are there hll interop tests that I can run?
05:54 dukeleto Tene: how do I know what works and what doesn't, right now?
05:54 Tene as I recall, I wrote it three or four times around early 2009, and nobody else has touched it since I last dropped it in late 2009 or so.  I don't recall the timeline well, but certainly no later than that.
05:54 dukeleto Tene: i.e. i am not interested the past, but the present and future of hll interop
05:55 dukeleto Tene: what is it? where does the code live?
05:55 * JimmyZ likes hll interop :)
05:55 dukeleto cotto: just read JimmyZ++'s post
05:56 Tene dukeleto: There was an API for languages to implement on the compilers they registered with compreg.  Parrot had a parrot.pbc installed as a language at one point that implemented it for native parrot libraries, and at one point HLLCompiler provided reasonable defaults to languages that used it.
05:56 dukeleto JimmyZ: i am responding to your post now
05:57 dukeleto Tene: does HLL interop in parrot have any tests?
05:57 Tene dukeleto: short answer: no.
05:57 JimmyZ dukeleto: that's trivial
05:57 dukeleto Tene: that is why it is broken
05:59 Tene dukeleto: That comment rather seems to contradict "not interested in the past", unless I'm misunderstanding you.
05:59 Tene It also doesn't tell me anything I didn't already know.
05:59 Tene So, I don't see what you're trying to tell me here.
06:01 JimmyZ Tene:  HLL interop may be low priority in 2009, parrot is not good enoug, which will lead to many large refactors
06:01 JimmyZ s/enoug/enough/
06:01 Tene JimmyZ: yes, I know that HLL interop was low priority in 2009.
06:02 Tene Once I see someone else actually work on it, I'll believe that it's a priority for someone.  Until then, it's low priority.
06:02 cotto Once I see what to do, I'll start working on it.
06:02 Tene I'm certainly not telling anyone that they *should* work on this, or tell anyone how to arrange their priorities.
06:03 fperrad joined #parrot
06:04 JimmyZ Tene: I really like HLL interop :)
06:04 Tene JimmyZ: if you think I'm saying that anyone else did anything wrong, I'm not expressing myself very well.  I'm sorry.
06:04 JimmyZ Tene:  I didn't think anything :)
06:05 JimmyZ Tene:  Things are not always run smoothly
06:07 Tene cotto: afaict, the PDD I wrote for hll interop isn't present in the repo any more.  There's PDD31, which is related, but not really a specification for this, and doesn't really discuss interop much.
06:07 * JimmyZ is happy that the goal is  same
06:08 dukeleto Tene: a PDD about interop was deleted? I've never seen or read it.
06:09 Tene dukeleto: It's entirely possible that I'm misremembering something.  My memory isn't very reliable.
06:10 pmichaud_ iirc, there were aspects of hll interop in pdd21, yes.
06:10 * pmichaud_ looks.
06:10 dukeleto Tene: i think we need a test suite before a spec. I want to convert the float 5 in Python to the float 5 in Javascript, call a javascript function from python, vice-versa
06:10 dukeleto Tene: that doesn't need a spec. It needs some tests.
06:10 Tene Yes, removed in r49249
06:10 dukeleto Tene: what was the filename?
06:11 Tene dukeleto: git log -- docs/pdds/draft/pdd31_hll_interop.pod
06:12 dukeleto Tene++
06:12 Tene I wouldn't be surprised to find out there were also lies in that document when it was deleted.
06:12 cotto Tene, they're common in the pdds
06:12 Tene And, uh, apparently I never committed to that file?
06:12 dalek parrot/m0-prototype: 654dee6 | nbrown++ | t/m0/m0_integration.t:
06:12 dalek parrot/m0-prototype: Fix m0_integration test when using $ENV{M0_INTERP}
06:12 dalek parrot/m0-prototype:
06:12 dalek parrot/m0-prototype: In the m0_integration tests, use "$ENV{M0_INTERP}" or "perl m0_interp.pl",
06:12 dalek parrot/m0-prototype: but not "perl $ENV{M0_INTERP}".
06:12 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/654dee622c
06:12 dalek parrot/m0-prototype: 7a42557 | nbrown++ | config/gen/makefiles/root.in:
06:12 dalek parrot/m0-prototype: Fix setting M0_INTERP on Windows in the Makefile
06:12 dalek parrot/m0-prototype:
06:12 dalek parrot/m0-prototype: The *nix style of setting an environment variable doesn't work in Windows.
06:12 dalek parrot/m0-prototype: So if the platform is win32, set the M0_INTERP using the Windows 'set'
06:12 dalek parrot/m0-prototype: syntax. Also, use backslash as the path seperator on Windows.
06:12 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/7a42557e89
06:12 dalek parrot/m0-prototype: c4b3eb6 | dukeleto++ | src/m0/c/Makefile:
06:13 dalek parrot/m0-prototype: Add a clean target to M0
06:13 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/c4b3eb69b7
06:13 dukeleto [docs]:  Remove obsolete (and incorrect) draft/pdd31_hll_interop.pod .
06:13 Tene So, apparently I wrote some document, and never committed it to the repo.
06:13 dukeleto that is the last commit i see
06:14 dukeleto Tene: huh. That would make it hard to implement.
06:14 dukeleto cotto: can you tell me if "make m0_c_tests" hangs on a non-windows box for you?
06:15 cotto dukeleto, not only can I, but I wll.  Give me a sec
06:15 dukeleto cotto: m0_hash was pegging a cpu for me
06:15 sorear Tene: there was at one point two pdd31s in the repo
06:15 dukeleto cotto: i think the env var for the integration tests only works on windows now
06:17 Tene sorear: yes, apparently the deleted one was not where I put notes about this.
06:17 Tene dukeleto: look at, for example, 2919163e2e7388e74a59c54d78182e4f1b8812af
06:17 Tene I was apparently referring to something there, and iirc I was following changes made (or requested?) by pmichaud there.
06:18 Tene runtime/languages/parrot/parrot.pir is still present, but as I recall, there was something added to pct or nqp that made it impossible for that to be loaded with load_language
06:19 Tene anything using the newer pct got something loaded in its place such that load_language's detection said that it was already loaded
06:19 Tene or maybe it was just that something in pct or hllcompiler somewhere registered something else urnelated as 'compreg "parrot"'
06:19 dukeleto $ parrot runtime/parrot/languages/parrot/parrot.pir
06:19 dukeleto Class Compiler already registered!
06:20 Tene I don't quite recall, but something like that was one of last things that came up that I didn't feel up to fixing.
06:20 dukeleto Tene: that deleted PDD is a very interesting, but it is an overview of HLL interop, not a design document
06:20 Tene dukeleto: YEs, as I already said, twice.
06:20 dukeleto Tene: is that the only way to test parrot.pir ? Does anything use it?
06:21 Tene dukeleto: Sorry if I seem testy here; I seem to be unusually irritable today.  Perhaps I haven't been sleeping well.
06:23 dukeleto Tene: you do seem testy, but I have a thick skin :)
06:23 dukeleto Tene: so, is there a way that you test if parrot.pir works, for yourself? Something that never made it into a file in the repo?
06:25 Tene dukeleto: It's currently broken.  If it's failing like that when loaded by parrot, it's broken.
06:25 Tene unless, uh... maybe it's trying to run the :load sub twice or something?
06:26 dukeleto Tene: i understand that it is broken. But I want an automated way to detect the broken-ness, known as a "test" :)
06:26 Tene yeah, seems to work just fine when loaded with load_language
06:26 Tene so, not broken.
06:30 Tene I'm pretty sure that the issue was that pct was installing something as the "parrot" compiler
06:30 Tene but I can't find evidence of that
06:31 dukeleto Tene: what does the actuall call to load_language look like?
06:32 Tene Ahh, there we go...
06:32 Tene ext/nqp-rx/src/stage0/HLL-s0.pir +7610
06:32 Tene it's nqp
06:33 Tene dukeleto: load_language is a parrot opcode that accepts a single string argument and then looks for a pbc in $(libdir)/languages/$lang/$lang.{pir,pbc}
06:33 cotto dukeleto, m0_c_tests doesn't hang for me
06:35 dukeleto Tene: load_bytecode 'parrot/parrot' doesn't work
06:35 Tene dukeleto: load_bytecode 'parrot'
06:36 Tene most languages should usually register a compiler with compreg
06:37 pmichaud_ all of the HLLCompiler and HLL::Compiler based languages use compreg.
06:37 Tene Yes.
06:38 Tene So when you want to work with another language, you get its compiler by asking for it with compreg
06:38 dukeleto Tene: "load_bytecode" couldn't find file 'parrot'
06:38 Tene if it's not there and you want to load it, you call load_language and then try again
06:38 Tene dukeleto: sorry, I misspoke.  you want: load_language 'parrot'
06:39 Tene load_bytecode 'parrot' will look in $libdir/library/parrot.pbc
06:39 Tene languages live in $libdir/languages/parrot/parrot.pbc
06:41 Tene for some examples of libraries defining export lists through utility functions on the parrot compiler, look at runtime/parrot/library/OpenGL.pir and runtime/parrot/library/NCI/Utils.pir
06:42 Tene and then notice that in the second, it's commented out with "this crashes rakudo", because NQP registers something else as the 'parrot' compiler
06:42 dukeleto Tene: i have seen the light.
06:42 pmichaud_ Tene: just for clarification, note that what you're calling NQP we now call nqp-rx
06:42 pmichaud_ to distinguish it from the new nqp that has 6model included.
06:42 dukeleto pmichaud_: how do you feel about nqp-rx not fiddling with the 'parrot' global namespace ?
06:43 Tene pmichaud_: uhh... yes, that's right.
06:43 Tene I'm a bit out of touch these days. :)
06:43 pmichaud_ I'm pretty sure that nqp (the new one) doesn't create a 'parrot' compiler.
06:44 pmichaud_ dukeleto: there's two answers to that
06:44 dukeleto the mystery deepens...
06:44 pmichaud_ dukeleto: if you want to put the nqp-rx compiler itself into its own hll namespace, no problem.
06:44 pmichaud_ but mostly what nqp-rx provides are shared libraries
06:45 pmichaud_ those can potentially go into a separate hll namespaces as well, but we'd have to retrain user code to look for them in the new place.
06:46 pmichaud_ and the code that nqp-rx generates really shouldn't be associated with any hll namespace on its own, because it's intended to be embedded in larger programs (thus the larger program should determine the hll namespace)
06:46 pmichaud_ i.e., if you use the regex compiler to compile a regex, you want that compiled regex to be in the caller's HLL namespace, not in the regex compiler's HLL namespace.
06:48 dukeleto pmichaud_: does anything actually register a 'parrot' compiler?
06:48 dukeleto pmichaud_: all i know is that nothing but parrot internals should be registering a compiler called 'parrot'
06:49 pmichaud_ dukeleto: iirc, pct registers the 'parrot' compiler.
06:52 dukeleto pmichaud_: ok, so it is PCT, not nqp-rx
06:53 dukeleto Tene: what I am hearing is that when PCT started registering the 'parrot' compiler, it broke parrot.pir . Does that sound about right?
06:53 Tene dukeleto: Not quite.  It broke other programs usage of the 'parrot' compiler.
06:53 pmichaud_ and PCT definitely believes that it can live in the 'parrot' namespace (more)
06:54 Tene "lives in the parrot namespace" is rather different from "registers the parrot compiler"
06:54 pmichaud_ PCT registered a 'parrot' compiler to be able to provide a pdd-compatible interface to the PIR compiler.
06:54 pmichaud_ afaik, it was the first to do so.
06:55 Tene It was only PDD compatible when you added your PDD31, ignoring the work I had done on that, which I apparently never put into a pdd in the repo, afaict.
06:58 Tene But, yeah, something like that.
06:59 dalek parrot: 60c22d7 | dukeleto++ | / (4 files):
06:59 dalek parrot: [t] And then there were HLL interoperability tests
06:59 dalek parrot: review: https://github.com/parrot/parrot/commit/60c22d7410
06:59 dukeleto i am hearing a lot of miscommunications
06:59 Tene the only thing I can see that's registering a parrot compiler (besides languages/parrot/parrot.pir) is nqp-rx
06:59 dukeleto Tene: is there any way you can put whatever you wrote about interop that never made it into parrot.git somewhere?
07:00 cotto or a wiki or github page or a napkin mailed to PaFo
07:01 Tene dukeleto: "whatever I wrote" may or may not still exist anywhere.  I can certainly write something equivalent, though.
07:02 Tene I'll also take a look at my old laptop to see if I can find any clues.
07:08 Tene cotto, dukeleto: Some of this is already documented on http://trac.parrot.org/parr​ot/wiki/HllInteroperability
07:12 cotto Tene, that's great.
07:25 dukeleto we lost a lot of useful info when that hll interop pdd was deleted
07:25 dukeleto it wasn't a design doc, but never-the-less, it was useful info.
07:27 cotto and we'll regain it when it's resurrected into drafts or put on the wiki page
07:27 Tene browsing through the mailing list recently, one thing that seems to have been forgotten in a few cases was that the original intention of the deprecation policy was to try to improve parrot's attractiveness to other projects, to attract new developers and language implementors.
07:27 Tene Not just out of some sense of idealistic virtue or something; there were actual reasons and motivations for that.
07:28 cotto Tene, that's not something I've forgotten.  Perhaps it hasn't gotten enough mention.
07:28 cotto There are real and valid reason to provide a support policy like the one we're moving away from.
07:29 cotto Parrot isn't mature enough for those reasons to be compelling (though we thought we were).
07:29 mj41 joined #parrot
07:30 cotto I talked with kid51++ before sending the first message out and he emphasized that we implemented the deprecation policy for a reason and that we shouldn't forget that.
07:32 pmichaud_ People don't want to actively develop on top of any platform that is going through frequent, disruptive changes.  That's completely normal.
07:32 Tene Cardinal is not beyond resurrection, afaict.  It doesn't need that much work to be up to date and able to steal from other ruby implementations.
07:32 pmichaud_ Rakudo suffers this problem, as well.
07:33 pmichaud_ we try to alleviate that with the Star releases, but in a fast-evolving project it's still hard to handle both "the new shiny" and "the way we used to do things".
07:34 pmichaud_ but we also expect any deprecation policy to accur at the Star level, not at the compiler one.
07:34 pmichaud_ s/Star/distribution/
07:34 pmichaud_ because we don't want to chain language development to userbase needs
08:01 dalek parrot: e934aa8 | chromatic++ | src/packfile/api.c:
08:01 dalek parrot: [PCC] Optimized CS switching invoke.
08:01 dalek parrot:
08:01 dalek parrot: These checks can go away with threading system improvements, but avoiding this
08:01 dalek parrot: function call which is almost always a do-nothing gives a modest performance
08:01 dalek parrot: improvement to the default case of Sub's invoke.
08:01 dalek parrot: review: https://github.com/parrot/parrot/commit/e934aa89c6
08:01 dalek parrot: 39c5578 | chromatic++ | src/packfile/api.c:
08:01 dalek parrot: [PCC] Rearranged CS switching code slightly.
08:01 dalek parrot:
08:01 dalek parrot: I think it's clearer this way.
08:01 dalek parrot: review: https://github.com/parrot/parrot/commit/39c557894c
08:01 dalek parrot: b22c10c | chromatic++ | src/call/context.c:
08:01 dalek parrot: [ctx] Made init_context tailcallable.
08:01 dalek parrot:
08:01 dalek parrot: This modest optimization is in a PCC hot path. A decent optimizing C compiler
08:01 dalek parrot: should shave off a few assembly instructions. As a bonus, it makes our C source
08:01 dalek parrot: code shorter and simpler.
08:01 dalek parrot: review: https://github.com/parrot/parrot/commit/b22c10cb1f
08:01 dalek parrot: f215ea6 | chromatic++ | src/pmc/object.pmc:
08:01 dalek parrot: [OO] Optimized get_attrib_index slightly.
08:01 dalek parrot:
08:01 dalek parrot: Avoiding unnecessary work along this hot path improves performance.
08:01 dalek parrot: review: https://github.com/parrot/parrot/commit/f215ea6d64
08:01 dalek parrot: f457a74 | chromatic++ | src/pmc/object.pmc:
08:01 dalek parrot: [oo] Removed an (unused?) attribute cache.
08:01 dalek parrot:
08:01 dalek parrot: As far as I can tell, this never worked and never should have worked and was
08:01 dalek parrot: probably copy and paste code someone (probably me) never finished. Getting rid
08:01 dalek parrot: of it allows for more interesting possibilities.
08:01 dalek parrot: review: https://github.com/parrot/parrot/commit/f457a74a2e
08:01 dalek parrot: 75f735e | chromatic++ | src/pmc/class.pmc:
08:01 dalek parrot: [oo] Made the class attribute cache an INTVAL hash.
08:01 dalek parrot:
08:01 dalek parrot: This avoids allocating Integer PMCs when caching attribute indices and avoids
08:01 dalek parrot: the need to extract INTVALs from said PMCs when looking up attributes. Clearly
08:01 dalek parrot: this is an improvement.
08:01 dalek parrot: review: https://github.com/parrot/parrot/commit/75f735e664
08:02 chromatic Aggregate total, a 2.65% improvement on a real-world parrot-nqp benchmark.
08:02 chromatic OO and PCC heavy code will benefit the most.
08:03 cotto chromatic, I recently ran into a case where valgrind's simplistic model of a CPU failed to match reality.  Have you played much with a sampling profiler like oprofile?
08:05 cotto The case was with the sub profiling code from mls.  Using Parrot_hires_get_time instead of rdtsc resulted in a doubling (or more) of running time, valgrind gave no indication that either should be a limiting factor.
08:08 Tene I've been curious about https://perf.wiki.kernel.org/ lately.  I don't know how representative it really is, but 'perf record perl6 -e "say 1"' shows perl6 spending the most time in get_free_list_item
08:08 Tene 6.37%
08:08 aloha 0.0637
08:08 Tene although, I think that's an old version of rakudo...
08:15 Tene cotto, dukeleto: do either of you have any good references for how HLL interop works on other VMs?
08:16 Tene iirc, I've heard it's pretty reasonable on JVM?
08:16 moritz all languages act as if they were java :-)
08:19 cotto Tene, no idea.  My best guess is what moritz said.
08:21 JimmyZ Tene:  javascript works well on JVM
08:24 cotto I know that jvm languages like to market that they interoperate well with Java code.  I don't know how much they talk about interoperating with each other.
08:24 JimmyZ Tene: http://download.oracle.com/javase/6/docs/​api/javax/script/ScriptEngineManager.html
08:26 Tene cotto: apparently perf claims to be fairly similar to oprofile.
08:27 cotto Tene, I'll have to look into both of them in the near future.
08:30 mls morning!
08:31 cotto hio mls
08:31 mls cotto: does valgrind measure syscall time?
08:31 cotto mls, no idea
08:31 Tene https://gist.github.com/1202930 -- I'm curious about what this actually means; stalled-cycles-frontend was printed with the number in red, and stalled-cycles-backend in yellow
08:32 cotto mls, have you seen any instability in the sub profiler?  I converted the code to use a hash and found an occasional bus error while profiling Rakudo's setting build.
08:32 mls Parrot_hires_get_time probably does a syscall, that's why it is much slower
08:32 cotto plobsing++ verified that it always does a syscall
08:34 cotto mls, profiling the setting build seems to work most of the time (3/4 so far), so I'm not sure if I'm adding a bug of just running into one that was already there.
08:34 cotto I've got a couple Rakudo builds going so I can leave them profiling overnight and compare the results, but I figured you'd know.
08:36 mls I added a mark() function yesterday, cause the sub pmcs in the sub data were freed causing segfaults
08:36 mls did you run the latest version?
08:36 cotto yup
08:37 nopaste "cotto" at 192.168.1.3 pasted "use Hash in subprof" (166 lines) at http://nopaste.snit.ch/79169
08:37 cotto mls, there's the patch
08:40 Tene oh, very nice, 'perf report' is interactive, lets me zoom in to annotated versions of every symbol, etc.
08:40 cotto want
08:41 Tene I, uh, don't quite understand what I'm seeing, but this is showing a big hotspot in get_free_list_item, I think.
08:42 cotto Tene, what are you profiling?
08:43 Tene cotto: a portion of the rakudo build, right now
08:44 Tene perf record /home/sweeks/parrot/bin/nqp --target=pir --output=src/gen/perl6-metamodel.pir --encoding=utf8 --vmlibs=perl6_ops src/gen/Metamodel.pm
08:44 Tene not as big as all of CORE.setting, but still big-ish
08:45 Tene I could do CORE.setting, if you'd like, and send you the perf.data
08:45 cotto I'll play with it tomorrow.  I need to sleep rsn
08:46 Tene cotto: lemme know what you find out
08:47 Tene If it's really spending 11% of its time getting items from the free list, that's unfortunate.
08:47 Tene after that is 4.8% gc_gms_sweep_pools
08:47 cotto Tene, there's a branch to address that.
08:47 cotto something of whiteknight++'s doing at jnthn++'s suggestion
08:49 Tene cotto: to improve get_free_list_item?
08:50 dalek rakudo/nom: 0c6ec02 | (Martin Berends)++ | lib/Test.pm:
08:50 dalek rakudo/nom: [lib/Test.pm] move time recording operations as near as possible to tests
08:50 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0c6ec02787
08:51 cotto Tene, I think so.  might be something else gc-related
08:51 dalek rakudo/nom: 4967c55 | (Martin Berends)++ | tools/test_summary.pl:
08:51 dalek rakudo/nom: [tools/test_summary.pl] add a --view option to report on test times
08:51 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4967c559a3
08:52 cotto I'm going to bed.  'night
08:55 mls (sorry, had to do some dayjob work)
08:55 mls good night!
09:02 Tene Huh.  When I profile the CORE.setting build, I get 12% in gc_gms_validate_pmc, 10% in gc_gms_validate_objects, 6.3% in Parrot_FixedPMCArray_mark, and 5.8% in get_free_list_items
09:08 mls something different: shouldn't key_hash do some shifting/rotating in the pointer case?
09:09 mls seems it simply uses the (pointer & hash->mask) as bucket index
09:10 mls that means the lower bits are probably constant
09:16 not_gerd joined #parrot
09:16 not_gerd hello, #parrot
09:17 tadzik good morning parrots
09:19 mls Hi tadzik!
09:19 mls (and not_gerd!)
09:19 not_gerd good morning, mls
09:20 not_gerd Tene: did you profile an un-optimized Parrot?
09:20 not_gerd there are some #ifdefs in gc_gms_validate_objects() which probably make it a NOOP in optimized builds...
09:32 woosley left #parrot
09:33 dalek parrot: 91b0b55 | jimmy++ | src/gc/fixed_allocator. (2 files):
09:33 dalek parrot: remove unsed total_objects from struct Pool_Allocator
09:33 dalek parrot: review: https://github.com/parrot/parrot/commit/91b0b55783
09:38 Tene not_gerd: dunno; is optimized default?
09:39 Tene argh wtf am I still doin gup
09:39 * Tene sleep now bye
09:46 JimmyZ joined #parrot
09:49 ambs joined #parrot
09:55 not_gerd msg Tene: --optimize is off by default, but Rakudo's --gen-parrot enables it; if you profile a custum Parrot, you should probably pass --optimize to Configure.pl
09:55 aloha OK. I'll deliver the message.
10:09 lateau joined #parrot
10:18 plobsing joined #parrot
10:21 lateau left #parrot
10:49 ambs joined #parrot
10:49 nbrown_ msg dukeleto: the m0_c_tests target hangs on Windows too. That was why i originally disabled some of the tests where I hadn't implemented all of their opcodes
10:49 aloha OK. I'll deliver the message.
10:50 nbrown_ msg dukeleto: I was just targetting the LHF for opcode implementation :)
10:50 aloha OK. I'll deliver the message.
10:51 ambs joined #parrot
11:16 * Coke ponders a parrot plack alike.
11:17 woosley joined #parrot
11:32 cosimo joined #parrot
11:34 Psyche^ joined #parrot
11:41 JimmyZ joined #parrot
11:49 benabik joined #parrot
11:55 pmichaud joined #parrot
12:00 SHODAN joined #parrot
12:11 benabik o/
12:14 mls seen whiteknight
12:14 aloha whiteknight was last seen in #parrot 10 hours 45 mins ago saying "cotto_work: it won't just be nine. We'll assemble a group of highly skilled code ninjas around him to help out".
12:15 benabik mls: whiteknight should be on shortly, based on his normal habits.  :-)
12:15 mls ok, thanks.
12:30 mls why does Parrot_pcc_invoke_from_sig_object() call Parrot_push_context()?
12:32 mls (I see the extra frame in the profiler output)
12:33 mls the invoke() call also allocates a context (or uses the call_object) so I don't see the point of the extra context
12:35 benabik mls: invoke_from_sig_object calls push_context then invokes the right function, which itself calls push_context?
12:36 mls more or less. sub's invoke doesn't call push_context, but it pushes a context ;)
12:36 benabik I wonder if it didn't used to and the context from _from_sig_object is a fossil.  Or something.  Looks like a bug.
12:36 benabik Rip it out and see if anything breaks?  :-D
12:37 mls I'll check the code of methods/nci subs first. Maybe it's done for them.
12:38 mls It might be a fossil of the time where call object and context were two PMCs
12:39 benabik Sounds like bad times.
12:39 mls Well, I think the code was cleaner, but it was one extra PMC to alloc for each call
12:42 ambs_ joined #parrot
13:02 mls running 'make test'...
13:04 JimmyZ joined #parrot
13:05 cotto mls, I did 15 additional runs of the sub profiler on Rakudo's setting and didn't get any further bus errors.  I'm assuming that it was a one-time fluke.
13:06 mls good to hear! Btw, I updated it to parrot master
13:06 cotto I saw, after attempting to commit my changes. ;)
13:06 mls sorry ;)
13:06 cotto that'll teach me
13:07 mls But I also pushed your Hash change
13:07 cotto thanks for keeping it current
13:07 cotto are you interested in a commit bit
13:07 cotto ?
13:07 cotto and do you mind sending in a CLA?
13:07 benabik mls: You are interested in a commit bit.  </jedi>
13:08 mls Yes, I'll ask my employer about signing the CLA
13:08 cotto mls, are you writing the code on company time?  (mostly ooc)
13:08 mls yes
13:09 cotto on the one hand, awesome.  On the other, I hope they're ok with it going into parrot.
13:09 cotto what company?
13:09 mls I don't see any problems, as SUSE is doing OSS work anyway. Upstream work is pretty common.
13:11 mls (The patched Parrot_pcc_invoke_from_sig_object() seems to work! \o/ )
13:11 cotto ok.  They're known for doing the occasional bit of oss work. ;)
13:11 mls yes, from time to time ;)
13:11 cotto Are they paying you specifically to work on profiling or is it something discretionary?
13:12 mls no profiling at all.
13:12 mls I'm the maintainer of the 'perl' package, thus when perl6 arrived I also created the 'rakudo' and 'parrot' packages
13:13 tadzik that's cool
13:13 cotto good deal
13:13 mls therefore I lurked on the channels for quite some time
13:13 cotto I'm glad to know that you'll be sticking around.
13:13 moritz mls: are you still in the Nuernberg/Erlangen area?
13:13 mls yes, Nuernberg
13:13 moritz mls: there's a monthly perlmongers meeting in Erlangen :-)
13:14 moritz if you ever want to meet me (and other perl hackers) personally
13:14 mls I confess I've never been there yet
13:15 mls (But I gave a perl6 talk at the last openSUSE conference and met some of you guys)
13:17 mls (Now testing the setting compilation with the patched Parrot_pcc_invoke_from_sig_object...)
13:18 mls diff: https://gist.github.com/1203368
13:19 mls that's two PMC allocs less, should make pcc_invoke_from_sig_object quite a bit faster
13:19 mls and the profile output is nicer, too ;)
13:20 tadzik like
13:20 tadzik trying it too
13:21 benabik mls: OOC, any numbers on speed change?
13:22 cotto mls, I toyed with the idea of using a pre-sized hash in the sub profiler code but got distracted by the bus error.  It might be worth playing with.
13:22 mls I didn't measure it (mostly becaue I don't know how)
13:22 tadzik I
13:22 tadzik 'll measure it once it build it
13:22 mls thanks!
13:23 mls cotto: I don't think it's worth it, as the number of subs isn't that big
13:24 cotto probably not
13:25 mls what worries me more is that the hash code just uses the pointer as key
13:26 cotto Isn't that what the previous code did?
13:26 mls i.e. bucket_index = pointer & hash->mask
13:26 mls no, it shifted the pointer a bit
13:27 mls the problem is that most allocators return aligned memory, thus the lower bits are zero all the time
13:29 cotto interesting question
13:30 tadzik make  403.49s user 4.91s system 109% cpu 6:12.61 total
13:30 mls success! with the pcc_invoke_from_sig_object patch the spurious function duplications are gone
13:30 mls wow, overclocked!
13:30 tadzik was make  400.76s user 5.18s system 108% cpu 6:12.86 last time I measured
13:31 mls so 6% less.
13:31 mls 5.18 -> 4.91
13:31 tadzik maybe. I'm not sure how to read this :)
13:31 mls oh wait, read it the wrong way
13:32 mls so it's slower!
13:32 tadzik no, not really. Was 5.18s, is 4.91s
13:32 tadzik trying spectest now
13:32 * cotto tries to go back to sleep
13:33 mls sleep well!
13:44 dod joined #parrot
13:55 whiteknight joined #parrot
13:56 whiteknight good morning, #parrot
13:56 mls morning!
13:56 benabik o/ whiteknight
13:57 whiteknight good morning mls, benabik
13:57 mls I've a little idea that would make parrot calls quite a bit faster.
13:58 whiteknight do tell
13:58 mls (my numbers are from compiling rakudo's setting)
13:58 mls but I promise you won't like it ;)
13:58 benabik mls: whiteknight loves removing things.
13:59 mls so, it currently spends 28% in invoke()
13:59 mls more than half of the time in invoke is spend in allocating the continuation PMC
13:59 moritz .oO( remove invoke()! )
14:00 mls My (ugly) idea is to get rid of that
14:00 tadzik make spectest  1407.13s user 73.23s system 98% cpu 24:55.87 total
14:01 mls i.e. put the continuation data into the callcontext
14:01 tadzik last time when I measured it was 1465.13s, but it was a while ago
14:01 mls That's why I said you won't like it, as IMHO you want to split the continuation again
14:01 * tadzik tries again w/o the new patch
14:01 mls err callcontext
14:02 cotto didn't work
14:02 cotto so, good morning!
14:02 JimmyZ ....
14:02 mls we could do it in a compatible way, i.e. when somebody asks for the continuation, we can generate it
14:03 benabik cotto: Mornings where I don't have to work are usually good.  (But I don't think that's what you meant.)
14:03 JimmyZ looks like cotto needs  beer :)
14:03 cotto (sleep didn't work, not referring to mls' work)
14:03 whiteknight mls: lazy create the continuation? I like the concept
14:03 mls returncc would only use the continuation if it was generated, otherwise use the data from the callcontext
14:03 mls (all this is because PMC alloc is so slow)
14:03 whiteknight for the simple case of a subroutine return, we can definitely do an optimization like that
14:04 whiteknight mls: would you be able to prototype such a thing?
14:04 whiteknight or, do you need some help to do it?
14:04 mls It's not hard to do, I think.
14:04 mls But didn't you want to split the callcontext again?
14:05 whiteknight mls: I want to follow whichever path gives us the biggest gains in terms of performance and optimization potential
14:05 benabik Hopefully, someday, PMC alloc won't be slow.
14:05 mls (basically we want one PMC which is a mixin of callerargs, context and continuation ;) )
14:05 whiteknight mls: we can still split the callcontext, but on a different axis
14:05 benabik Why is allocating a Continuation slow?  If we're CPS, we'd rather like that to be fast.
14:06 whiteknight yes, that is a good point. We should try to make pmc allocation faster in either case
14:06 mls allocating *any* pmc is slow
14:06 benabik Poor.
14:06 whiteknight right now it requires two allocations: the fixed-size PMC header and the attributes structure
14:07 whiteknight we can try to merge that down into one, but that's going to require some non-trivial changes to GC
14:07 mls (it's slow because of GC, I think)
14:07 mls half of the pmc_new time is spent in GC (on average)
14:08 whiteknight allocating a new PMC can trigger a GC run, so that throws off the numbers
14:08 nbrown joined #parrot
14:09 whiteknight in otherwords, all GC cost is going to appear to occur inside pmc allocatation, when most allocations don't trigger GC
14:09 mls it doesn't matter if most allocations don't trigger GC
14:10 whiteknight individual allocations can be made faster, and GC can always be kicked and tuned
14:11 mls anyway, I'll try the continuation change and try to verify the numbers
14:11 whiteknight mls++
14:12 whiteknight I don't want to go down the path of making small premature optimizations in lieu of larger optimization potential later
14:12 mls oh, btw, I have a patch for Parrot_pcc_invoke_from_sig_object: https://gist.github.com/1203368
14:12 whiteknight but, if the numbers look really good here, it is a data point to consider
14:12 mls (premature optimization: right)
14:12 whiteknight what does that patch do?
14:13 mls it gets rid of a push_context and a continuation alloc
14:13 benabik mls: whiteknight's right though… avoiding that allocation will probably just move the GC runs out of invoke… if it doesn't make a significant total runtime difference, it's probably unneeded.
14:13 mls (I saw the extra context in the profile output)
14:13 mls benabik: I don't think so. It could mean less GC runs, thus a speed improvement
14:14 mls but that's why I want to verify it in a branch
14:14 benabik mls: Well, if it only _moves_ the GC run, that's no good.  Hence my comment on "total runtime"
14:14 benabik mls: Don't be fooled by "oh, invoke takes less time"
14:14 mtk joined #parrot
14:15 mls yes, the goal is to reduce the runs, not move them
14:15 cotto fewer GCables is fewer GCables
14:15 mls whiteknight: make test didn't show any error with the patch, but I'm no callcontext expert
14:15 mls so I like to hear what you think of the patch
14:16 JimmyZ_ joined #parrot
14:19 JimmyZ__ joined #parrot
14:21 benabik mls: What continuation are you killing?  The return continuation?  Wouldn't that have to be created eventually anyway?
14:22 JimmyZ joined #parrot
14:22 mls the contination created by invoke (as NEED_CONTINUATION was set)
14:23 JimmyZ___ joined #parrot
14:23 whiteknight mls: let me fire up a vm and try that patch
14:25 JimmyZ_ joined #parrot
14:29 benabik mls: In Sub.invoke(), you mean?
14:31 mls yes
14:32 JimmyZ_ joined #parrot
14:32 benabik Created if NEED_CONTINUATION is set, which is set by invokecc…  So that would be the return continuation.  I would think that it would eventually be called by 99% of subs, so I'm not sure you can avoid creating it.
14:33 * benabik could be wrong.
14:34 mls are you talking about the pcc_invoke_from_sig_object path or the idea I was talking about earlier?
14:34 benabik The idea from earlier.
14:35 mls with the idea, invoke() would not create the continuation right away when NEED_CONTINUATION is set, but just store the relevant data in the callcontext
14:35 mls when somebody asks for the continuation, it would get created from the stored data, so we stay compatible
14:36 mls returncc would use the continuation if present, otherwise it would not create the continuation but use the stored data
14:37 benabik Ah.  Only create the continuation if someone's trying to do something clever with it.  I see.
14:37 mls so for normal invoke...return no continuation would get created
14:38 mls what exactly triggers the GC?
14:40 JimmyZ_ joined #parrot
14:41 mls ah, mem_used_last_collect > gc_threshold
14:42 tadzik without the patch: make spectest  1418.80s user 71.44s system 99% cpu 25:03.36 total
14:42 tadzik rakudo: say (1418.80 - 1407.13) / 1418.80
14:42 p6eval rakudo 4967c5: OUTPUT«0.00822526078376092␤»
14:42 benabik (1418.80 - 1407.13) / 1418.80
14:42 benabik 0.8%
14:43 benabik Fun.
14:43 aloha 0.00822526078376082
14:43 aloha 0.008
14:43 tadzik aloha: you should switch from abacus to a calculator
14:43 benabik tadzik: No kidding.
14:44 tadzik mls: almost 1% win it seems :)
14:45 tadzik (in this specific case)
14:45 dukeleto ~~
14:45 mls not much. But it also improves the profiler output ;)
14:46 tadzik (:
14:46 benabik I like speed win and better output.
14:48 whiteknight benabik: commit and push it
14:48 benabik whiteknight: It ain't mine.  :-D
14:48 benabik tadzik: commit and push it
14:48 benabik :-D
14:48 whiteknight whoever did it, push the damn thing
14:49 tadzik benabik: It ain't mine.  :-D
14:49 tadzik but I can push it, free karma
14:49 benabik tadzik: mls doesn't have a bit yet.  Sadface
14:49 tadzik that's wrong
14:49 tadzik Commit message?
14:52 mls get rid of superfluous context creation in Parrot_pcc_invoke_from_sig_object
14:52 mls something like that
14:52 mls whitknight: so no objections from your side?
14:53 mls whiteknight: so no objections from your side?
14:53 dalek parrot: bf43ce2 | tadzik++ | src/call/pcc.c:
14:53 dalek parrot: Get rid of superfluous context creation in Parrot_pcc_invoke_from_sig_object. Patch courtesy of mls++
14:53 dalek parrot: review: https://github.com/parrot/parrot/commit/bf43ce2216
14:54 whiteknight mls: no objections
14:54 dmalcolm joined #parrot
14:55 whiteknight cotto_work: ping
14:59 Kulag joined #parrot
15:01 whiteknight dukeleto: ping
15:04 cotto_work ~~
15:04 cotto_work whiteknight: pong
15:05 whiteknight cotto_work: mls is kicking too much ass to be contained. Can we set him up with a bit today and make it "official" at next #ps?
15:05 benabik whiteknight: ENOCLA
15:05 whiteknight benabik: EITCANWAIT
15:05 cotto_work mls: I want to make sure he can sign a cla.  Apparently he needs to talk to some people at $dayjob.
15:05 cotto_work I know what you mean though.
15:06 benabik whiteknight: Lawyers disagree. :-/
15:06 cotto_work he works for SUSE, so hopefully they're cool
15:06 whiteknight it makes no functional difference whether he commits to a fork and we pull, or whether he commits directly to our repo
15:06 dukeleto whiteknight: pong
15:07 whiteknight dukeleto: I was going to ask you the same thing I just asked cotto RE: mls getting a commit bit
15:07 alester joined #parrot
15:08 whiteknight benabik: lawyers don't just disagree with things. They need grounds. A CLA doesn't really do anything to protect people if there's wrongdoing that would involve a lawyer
15:08 whiteknight the biggest thing a CLA does is grant Parrot an explicit license to use the contributions
15:09 benabik As opposed to the implicit one from saying "pull this".  Eh.
15:09 whiteknight If he has entanglements with an employer, I don't think a CLA resolves that anyway, so that's not a sticking point
15:11 moritz (note that in .de, entanglement with employer isn't as bad as in the US)
15:12 whiteknight is mls in .de?
15:12 moritz yes
15:12 moritz about 20km from my place :-)
15:12 whiteknight moritz: I may have to send you over to his house one day with a case of beer.
15:12 moritz whiteknight: :-)
15:13 moritz or better yet, there'll be a German Perl Workshop in March 2012 at my place (Erlangen)
15:13 moritz that should be a nice incentive for a visit, and could warrant a beer or two
15:14 dalek rakudo/nom: a392725 | jonathan++ | src/Perl6/Actions.pm:
15:14 dalek rakudo/nom: Toss unused variables and initializations.
15:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a392725ec5
15:14 dalek rakudo/nom: 842c4f7 | jonathan++ | src/core/EXPORTHOW.pm:
15:14 dalek rakudo/nom: Remove workarounds; replace a bunch of PIR ops with NQP ops.
15:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/842c4f7955
15:14 cotto_work and there's yapc::eu 2012
15:14 mls beer? where? ;)
15:15 moritz cotto_work: right, also a mere 200km away
15:15 cotto_work moritz: in America that's not far. ;)
15:16 atrodo 200m, isn't that like across the hall around here? ;)
15:16 moritz cotto_work: it's 3 hours by train here, a bit less if you're willing to pay more
15:17 dalek parrot: 77e1274 | dukeleto++ | tools/dev/README (2 files):
15:17 dalek parrot: Markdownify toos/dev/README
15:17 dalek parrot: review: https://github.com/parrot/parrot/commit/77e1274c54
15:17 dalek parrot: 34e7377 | dukeleto++ | tools/dev/ (2 files):
15:17 dalek parrot: [doc] Add useful information to tools/dev/README
15:17 dalek parrot: review: https://github.com/parrot/parrot/commit/34e73772b0
15:17 dalek parrot: 863ad6d | dukeleto++ | MANIFEST:
15:17 dalek parrot: Update manifest
15:17 dalek parrot: review: https://github.com/parrot/parrot/commit/863ad6dc90
15:20 dukeleto mls: do you actually commit work while physically at $dayjob ?
15:20 dukeleto whiteknight: i am inclined to say no commit bit unless there is a CLA. It is the prudent thing to do, though annoying.
15:20 mls yes.
15:21 mls I also think you should wait for the CLA.
15:21 dukeleto mls: until you can get the CLA signed, I would suggest working in a fork of parrot.git and sending pull requests
15:21 benabik Sometimes I think the acronym is off by a letter.  It's more a CYA.
15:21 dukeleto mls: https://github.com/parrot/parrot/blob​/master/docs/project/git_workflow.pod tells you everything you need to know about working in a fork
15:22 mls I already do that with the sub-profiler: https://github.com/mlschroe/parrot
15:23 dalek rakudo/nom: 7360e33 | jonathan++ | src/Perl6/Grammar.pm:
15:23 dalek rakudo/nom: Unify EXPORTHOW handling, avoid some code duplication, make nested settings work.
15:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7360e33ec0
15:23 dalek rakudo/nom: 7c001ff | jonathan++ | / (3 files):
15:23 dalek rakudo/nom: Add first cut of SAFE.setting, for the benefit of p6eval. Plenty missing, but should make it clear to other interested folks how to do more.
15:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7c001ff636
15:25 dalek parrot: 8299931 | dukeleto++ | tools/dev/README.md:
15:25 dalek parrot: [doc] Add some useful docs about dedeprecator.nqp
15:25 dalek parrot: review: https://github.com/parrot/parrot/commit/82999319a7
15:25 dukeleto mls: yes, that works well for now
15:26 cotto_work mls: that said, I'm eager for you to get a commit bit
15:27 mls I must warn you: I'm currently spending too much time on parrot
15:27 dukeleto mls: aren't we all :)
15:27 whiteknight mls: it's a disease :)
15:28 mls ;) What I'm trying to say is that i've got a couple of other projects that I need to work on
15:28 dukeleto ... o/` Whose got parrot fever? She's got Parrot fever o/` ...
15:28 mls like the opensuse build service (my main project actually)
15:29 mls which I'm currently neglecting a bit
15:30 mls (I just had too much fun implementing the profiler, I guess ;) )
15:33 darbelo joined #parrot
15:33 cotto_work mls: it happens
15:35 cotto_work probably not often enough
15:38 moritz speaking of awesome coding robots, anybody knows what's up with bacek++?
15:38 cotto_work heh.  You're the third person to think of that in the last few days.  He's been mia for a while.
15:38 dukeleto moritz: i have been trying to contact him. He seems to still exist on Twitter
15:38 JimmyZ bacek is active on facebook :)
15:41 tadzik (:
15:52 darbelo_ joined #parrot
16:06 JimmyZ_ joined #parrot
16:11 dalek Rosella: 856b944 | Whiteknight++ | s (4 files):
16:11 dalek Rosella: Add in a new Tokenizer.Iterator for String. Add a few other enhancements to make tokenizers and tokens easier to use
16:11 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/856b944760
16:11 dalek Rosella: edaa0f5 | Whiteknight++ | src/template/ (2 files):
16:11 dalek Rosella: Use the new tokenizer iterator in the Template library for modest cleanups
16:11 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/edaa0f530d
16:16 ambs_ joined #parrot
16:27 darbelo joined #parrot
16:56 dalek rakudo/nom: a2a5ab8 | jonathan++ | src/Perl6/Actions.pm:
16:56 dalek rakudo/nom: Implement usage of parametric roles in term position. We specialize them runtime at latest, but if all the arguments are constants (including other types) then we just resolve it once at compile time, which will be faster.
16:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a2a5ab896b
17:00 tadzik Failed allocation of 7166182913849190824 bytes
17:00 tadzik Parrot VM: PANIC: Out of mem!
17:00 tadzik now, that I haven't seen before :)
17:00 benabik That's a lot of bytes.
17:00 tadzik b: say 7166182913849190824 / (1024*1024)
17:00 p6eval b 1b7dd1: OUTPUT«6834204591607.28␤»
17:00 tadzik ...how many>?
17:01 tadzik Sorry, coredump is not yet implemented for this platform.
17:01 tadzik ...for linux?
17:01 tadzik Parrot crashes could be better :P
17:03 dalek rakudo/nom: c8b7c99 | jonathan++ | src/Perl6/Metamodel/ (2 files):
17:03 dalek rakudo/nom: Curried roles should be punnable and able to be passed around.
17:03 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c8b7c995d1
17:10 JimmyZ_ joined #parrot
17:12 dalek winxed: 517d063 | NotFound++ | winxedst0.cpp:
17:12 dalek winxed: constant propagation for operators << and >> in stage 0
17:12 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/517d063fd6
17:16 dalek winxed: 20bcd02 | NotFound++ | winxedst1.winxed:
17:16 dalek winxed: use << operator in the definition of some flas
17:16 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/20bcd024b4
17:17 contingencyplan joined #parrot
17:25 darbelo_ joined #parrot
17:27 darbelo joined #parrot
17:42 darbelo joined #parrot
17:42 darbelo joined #parrot
17:42 darbelo joined #parrot
17:55 darbelo_ joined #parrot
17:58 darbelo joined #parrot
18:02 chromatic joined #parrot
18:25 dalek winxed: 3374e4f | NotFound++ | / (3 files):
18:25 dalek winxed: new builtin __ASSERT__ in stage 0
18:25 dalek winxed: Not very informative but the zero means something
18:25 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/3374e4f952
18:49 chromatic Hm, opsc reads its files as UTF-8 but they can probably be transcoded to ASCII or ISO-8859-1.
18:50 chromatic There's a 33% speedup waiting for that.
18:56 whiteknight improving opsc by 33% would be gorgeous
19:01 preflex_ joined #parrot
19:02 Coke joined #parrot
19:02 nine Is there some easy way in git to get the differences of a branch to it's base?
19:02 whiteknight git diff base..branch
19:03 whiteknight so like if you wanted to see what had changed in the whiteknight/kill_threads branch, you would do git diff master..whiteknight/kill_threads
19:04 nine that seems to include all commits that have been on master. I would like to see the commits on the branch only
19:07 whiteknight oh, then use ...
19:07 whiteknight instead if two ..
19:07 whiteknight one of those does the right thing
19:07 nine aaah...huge difference
19:17 dalek rakudo/nom: 591c694 | moritz++ | tools/build/Makefile.in:
19:17 dalek rakudo/nom: whitespace fix in Makefile.in, GNU make really wants tab characters
19:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/591c6944df
19:17 chromatic Hm, I was wrong. It's 35%.
19:18 * nine is trying to find out what exactly the status of gsoc_threads is and where to start
19:18 p6eval joined #parrot
19:20 cotto_work nine: look for gsoc blog posts on parrot.org
19:25 dalek parrot: 58e1e20 | chromatic++ | lib/Parrot/Pmc2c/PMC.pm:
19:25 dalek parrot: [Pmc2c] Replaced a string with a constant string.
19:25 dalek parrot:
19:25 dalek parrot: This is a tiny bit of bookkeeping I noticed on the way to something better.
19:25 dalek parrot: review: https://github.com/parrot/parrot/commit/58e1e20e54
19:25 dalek parrot: a23acf4 | chromatic++ | compilers/opsc/src/ (2 files):
19:25 dalek parrot: [opsc] Added fixed-width transcoding to opsc.
19:25 dalek parrot:
19:25 dalek parrot: Where this is possible, it speeds up opsc on one benchmark by 35%, at the
19:25 dalek parrot: expense of a one-time transcoding cost. As our .ops files are primarily ASCII
19:25 dalek parrot: and only theoretically Latin-1, this is a huge improvement.
19:25 dalek parrot: review: https://github.com/parrot/parrot/commit/a23acf45f2
19:27 darbelo joined #parrot
19:30 dukeleto ~~
19:30 cotto_work hio dukeleto
19:33 dalek winxed: e171a2f | NotFound++ | winxedst1.winxed:
19:33 dalek winxed: implement __ASSERT__ in stage 1
19:33 dalek winxed: review: https://github.com/NotFoun​d/winxed/commit/e171a2f430
19:35 mj41 joined #parrot
19:35 benabik joined #parrot
19:35 nine I wonder, if AIO could actually make this stuff simpler. One could preemt a task upon issuing the operation and schedule it again on IO completion. Would make task feel more like real threads without the locking hassle.
19:36 dalek Rosella: d79fc7f | Whiteknight++ | src/harness/TapParser.winxed:
19:36 dalek Rosella: fix a case where a test without a name caused an index out of bounds
19:36 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/d79fc7fac2
19:36 dalek jaesop: df19d0a | Whiteknight++ | / (3 files):
19:36 dalek jaesop: Cleanup the harness with new improvements to Rosella. Sort test files by name
19:36 dalek jaesop: review: https://github.com/Whiteknig​ht/jaesop/commit/df19d0a757
19:37 whiteknight nine: I've considered a very similar thing in the past
19:37 whiteknight we could definitely implement AIO in terms of green threads. The green thread scheduler could poll each task, and the IO tasks wouldn't be ready until the operation was complete
19:38 whiteknight nine: If we could do nothing but implement just that little feature, I would call it a big success
19:40 benabik AIO implemented as blocking IO on a thread has the virtue of simplicity.
19:40 dalek rakudo/nom: c34ac6e | moritz++ | src/SAFE.setting:
19:40 dalek rakudo/nom: forbid more functions in SAFE.setting
19:40 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c34ac6eac3
19:41 whiteknight benabik: the more we can have everything integrated into a single dispatch/scheduling framework, the better
19:42 dukeleto cotto_work: how goes? did you get any sleep last night?
19:42 nine benabik: it depends on the view point. It saves you the event stuff of AIO, but brings you the complications of threading. If we implement IO primitives in terms of AIO and just use the existing green threads infrastructure, it would be as simple to use for HLL as blocking IO, but save us from having to deal with real threads for that
19:43 dukeleto nine: did you find something to hack on?
19:43 benabik nine: If threading works, AIO as threaded IO is quick to implement.
19:43 cotto_work dukeleto: not enough
19:44 benabik Personally I'd almost prefer blocking IO as AIO with waiting.  :-D
19:44 cotto_work but I got an early start
19:44 benabik Although I suppose realistically, we _want_ AIO and IO to be implemented on top of the system level versions of same.
19:45 benabik nine: Really, as soon as you have threading you want some kind of event/notification system anyway.
19:46 NotFound Non-blocking and asynch should be orthogonal
19:46 benabik (Even if it's as simple as Java's object.wait() and object.notify())
19:47 benabik NotFound: Perhaps I am unfamiliar with terminology here, but doesn't AIO == non-blocking?
19:47 whiteknight benabik: depends who you talk to
19:47 benabik whiteknight: I'm apparently talking to NotFound.  ;-)
19:47 jevin joined #parrot
19:47 NotFound benabik: AIO is usually: call some notification or termination function when you are ready.
19:48 whiteknight benabik: Here's a very old post I wrote on my blog that talks about it
19:48 benabik NotFound: Ah.  AIO == non-blocking + callbacks
19:48 whiteknight http://whiteknight.github.com/2009/0​5/01/asynchronous_io_in_parrot.html
19:48 benabik (Roughly)
19:48 NotFound benabik: non-blocking synchronous is just: if the task can't be done right now, return.
19:49 benabik NotFound: That's not how I've generally used it.  non-blocking can be "read into this buffer whenever you can, but return immediately".  ref: java.nio.*
19:49 whiteknight benabik: again, depends who you ask
19:49 whiteknight not everybody is very precise when throwing those terms around
19:49 benabik whiteknight: Fair enough.
19:50 NotFound benabik: well, the part that reads whenever can is the termination function, just isn't user provided.
19:51 NotFound In this field I prefer the windows terms.
19:52 NotFound The win32 api is very good in that things.
19:54 Coke joined #parrot
19:54 NotFound But yes, you can avoid the callback and check later the state of the object to see when the operation is completed.
19:56 NotFound In non-blocking synch, on the contrary, you must redo the operation later, if not completed at the first attempt.
19:57 benabik NotFound: I see the distinction.
19:57 nine Of course even AIO brings green threads only so far. Any call into an external library could block the interpreter for an arbitrary time.
19:57 NotFound (or partially redo, if some bytes have been read/writen)
19:58 whiteknight nine: Right, that's where we need full OS threads at some point
19:58 whiteknight the hybrid situation works the best, in my estimation
19:58 benabik Even if the interpreter can't be spread across multiple threads, we can spawn limited OS threads as workers.
19:59 NotFound Just being able to use the timers without the need to use sleep frequently will be helpful for some tasks.
19:59 whiteknight benabik: exactly
20:00 whiteknight and where we can't use any OS threads at all, a robust green threads API means programs don't need to be re-written
20:00 whiteknight performance will suck eggs on those systems, but the code will still work
20:00 NotFound We can probably fake some async IO just using non-blocking and timers.
20:00 dalek parrot: 7b8bf15 | chromatic++ | src/pmc/class.pmc:
20:00 dalek parrot: [OO] Added object attribute storage initialization.
20:00 dalek parrot:
20:00 dalek parrot: This presized cache avoids the need to allocate (and re-allocate) storage for
20:00 dalek parrot: object attributes on access. It's a small improvement until a unified
20:00 dalek parrot: object-and-storage strategy exists.
20:00 dalek parrot: review: https://github.com/parrot/parrot/commit/7b8bf15143
20:00 dalek parrot: 35318ef | chromatic++ | src/gc/fixed_allocator.c:
20:00 dalek parrot: [GC] Rearranged code in pool allocator.
20:00 dalek parrot:
20:00 dalek parrot: This is a tiny simplification which should give a very modest performance
20:00 dalek parrot: improvement.
20:00 dalek parrot: review: https://github.com/parrot/parrot/commit/35318ef296
20:00 wagle joined #parrot
20:00 dalek parrot: ac4409f | chromatic++ | src/call/args.c:
20:00 dalek parrot: [PCC] Set arg_flags on CallContext directly.
20:00 dalek parrot:
20:00 dalek parrot: This avoids a vtable call and a STRING comparison in the common case, and
20:00 dalek parrot: should not harm subclassing at all. This ought to improve performance of
20:00 dalek parrot: external calls by a modest amount.
20:00 dalek parrot: review: https://github.com/parrot/parrot/commit/ac4409f9b7
20:01 chromatic When does IPFY update?
20:01 benabik gtg
20:01 whiteknight chromati: that's a good question
20:01 whiteknight or chromatic
20:03 NotFound chromatic: 7b8bf15  Can't that array be fixed length?
20:04 dukeleto chromatic: it gets a post-receive hook from github
20:04 dukeleto chromatic: but it takes roughly 30 mins to build on that machine, which is an old p4
20:04 chromatic NotFound, the only possible reason it might not be is to support morph, but I think you're right.
20:05 chromatic Just curious about these tuning results, as I expect ~6% improvement on OO/PCC heavy code.
20:05 whiteknight that's not bad
20:07 chromatic Yeah, that's decent tuning.
20:10 atrodo chromatic> That's not entirely true.  Sometimes (a lot of times), the post from github doesn't trigger the insert into the database.  I get the data, and it's saved.  I push it again with lwp and it works
20:11 atrodo haven't figured that one out yet
20:22 NotFound chromatic: pass all test with Fixed
20:24 NotFound Now that I look at it, I've buil unoptimized and the test wallclock time is better than my lasts optimized builds.
20:34 NotFound No noticeable difference between Resizable and Fixed
20:34 darbelo joined #parrot
20:38 dukeleto atrodo: i occasionally notice that a post-receive doesn't get sent, but i would say for me it is somewhere around 1% of the time
21:04 chromatic What's the message bot on here again?
21:04 cotto_work aloha msg chromatic this one
21:04 aloha cotto_work: OK. I'll deliver the message.
21:05 chromatic aloha msg masak If I'd meant to write "Rakudo and Parrot" I'd have written "Rakudo and Parrot".
21:05 aloha chromatic: OK. I'll deliver the message.
21:41 plobsing joined #parrot
22:15 whiteknight joined #parrot
22:16 whiteknight good afternoon, #parrot
22:16 dalek rakudo/nom: c9246f9 | jonathan++ | src/binder/container.c:
22:16 dalek rakudo/nom: Fix bug in handling of Scalar type object.
22:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c9246f9dee
22:16 dalek rakudo/nom: bf08c52 | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
22:16 dalek rakudo/nom: Generics handling for Scalar.
22:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bf08c52dcc
22:16 dalek rakudo/nom: aa90c55 | jonathan++ | src/Perl6/Actions.pm:
22:16 dalek rakudo/nom: Specialize generically typed lexically scoped scalars.
22:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/aa90c55591
22:17 dalek rakudo/nom: 2c31255 | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
22:17 dalek rakudo/nom: Need to specialize the default value if that's generic also.
22:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2c312555a5
22:17 dalek rakudo/nom: db4495a | jonathan++ | NOMMAP.markdown:
22:17 dalek rakudo/nom: Update nommap.
22:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/db4495a4e7
22:17 tadzik good afternoon whiteknight. I'm not a bot
22:24 Tene good afternoon whiteknight.  I'm at least one bot.
22:26 dukeleto Tene: how goes it? Any luck finding your interop writings?
22:27 Tene dukeleto: I haven't had a chance to look yet.  I should be able to late tonight.
22:32 wagle joined #parrot
22:34 chromatic whiteknight, are you getting rid of do_sub_pragmas?
22:42 dukeleto Tene: may the force be with you
22:43 chromatic Ha ha, how silly is this!
22:48 preflex_ joined #parrot
22:54 wagle joined #parrot
23:01 rfw joined #parrot
23:06 dalek nqp: 71c8f92 | chromatic++ | src/6model/reprs/ (6 files):
23:06 dalek nqp: [6model] Added annotations to exception throwers.
23:06 dalek nqp:
23:06 dalek nqp: This clears up several compiler warnings.
23:06 dalek nqp: review: https://github.com/perl6/nqp/commit/71c8f924cb
23:06 dalek nqp: 93a634d | chromatic++ | src/6model/reprs/P6opaque.c:
23:06 dalek nqp: [6model] Made a private function static.
23:06 dalek nqp:
23:06 dalek nqp: This cleans up a warning about the undeclared function.
23:06 dalek nqp: review: https://github.com/perl6/nqp/commit/93a634d1d3
23:06 dalek nqp: 2922924 | chromatic++ | src/6model/reprs/P6opaque.c:
23:06 dalek nqp: [6model] Fixed a constness conversion warning.
23:06 dalek nqp: review: https://github.com/perl6/nqp/commit/29229246bd
23:09 whiteknight chromatic: That's the plan. I have most of the pragmas untangled, but we're working on the rest of them
23:10 whiteknight I suspect it will stay around in a simplified way for handling :immediate and :postcomp
23:10 chromatic Good. do_sub_pragmas is ugly.
23:15 cotto ~~
23:48 cottoo joined #parrot

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

Parrot | source cross referenced