Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 6 September 2011.
Coke chromatic: how's life treating ya? 00:01
chromatic Won't complain. You?
dalek rrot: 0d3638b | chromatic++ | src/pmc/callcontext.pmc:
[PMC] Improved autobox_intval performance.

Avoiding the switch where there's no need to autobox is in fact significant in this hot path.		 00:08
rrot: 09bfabf | chromatic++ | .gitignore:
Added exclusions for callgrind/cachegrind files.
rrot: 185158c | chromatic++ | src/call/context.c:
Optimized register allocation slightly.

When there's no need to allocate register memory, waste no time not initializing the non-allocated registers.
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:09
dukeleto chromatic: it is wonderful to see commits from you again 00:10
Coke chromatic: pretty good. Need to get back on the diet snapple. 00:11
dalek sella: 3cb2ac0 | Whiteknight++ | src/harness/ (4 files):
Start refactoring the TAP parsing portions of the harness
 00:17
sella: 4e73dab | Whiteknight++ | s (3 files):
Several fixes so we build
sella: 644c62b | Whiteknight++ | src/harness/ (7 files):
Several failures so we run the harness again, with bugs
sella: a4e0ae3 | Whiteknight++ | src/ (4 files):
Several fixes, still not working correctly
sella: 7231fab | Whiteknight++ | src/harness/ (4 files):
Several fixes so we can run a toy example again
sella: 4b38a6c | Whiteknight++ | / (4 files):
Fix error messages. The full test suite runs like normal again
sella: 4bf2081 | Whiteknight++ | src/ (2 files):
refactor pipes a little
sella: 2c0bb86 | Whiteknight++ | src/harness/testfile/ (2 files):
Remove two files that aren't being used anymore
sella: 65294db | Whiteknight++ | s (4 files):
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
dukeleto github really spiffed up their web ui recently 00:19
cotto_work lta for some commits, but I like it overall
github.com/mlschroe/parrot/commit/bdbfc213e5 for instance 00:20
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.
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.
dukeleto msg whiteknight according to isparrotfastyet.com , the pmc_is_ptr merge caused a 22% speedup in stress1. Nice work. 00:35
aloha OK. I'll deliver the message.
Coke failing in t/pmc/select.t test. 00:41
er, dynpmc
smolder.parrot.org/app/projects/rep...ails/22654 00:43
00:44 soh_cah_toa joined
soh_cah_toa whiteknight: ping 00:46
whiteknight pong
dukeleto: It's amazing that such an innocuous thing was such a drag
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
whiteknight: so tell me about the new frontend. why did we need a new frontend and what's new about it?
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
soh_cah_toa: just kidding
soh_cah_toa :)
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
soh_cah_toa: by bootstrapping into PIR early and calling the :init subs there, we can avoid nested runloops
also, we can avoid a lot of embedding API calls, which are not and never were intended to be performance conscious
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?
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 whiteknight.github.com/2011/05/10/t...rides.html
plobsing: yes, that's a good point. It wasn't one of my motivations, but it is a nice side-effect
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
whiteknight for instance, there has long been a problem, and a lingering misunderstanding, that we can't create valid .pbc files from PIR code
the new frontend demonstrates that we can 00:52
soh_cah_toa ok
whiteknight dukeleto: Rakudo folk confirmed at least some kind of speedup. I'm still going to call it a net win
dukeleto msg atrodo some huge performance changes on ISPY are for documentation changes, such as 792a1398. What kind of VM are those benchmarks running?
aloha OK. I'll deliver the message.
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
plobsing ispy?
with my little eye?
dukeleto plobsing: isparrotfastyet.com
IPFY, rather. 00:54
derp
soh_cah_toa whiteknight: alright, what about kill_threads? what's the dillyo? 00:55
whiteknight soh_cah_toa: that one is tricky 01:02
we're going to kill_threads
soh_cah_toa why?
whiteknight soh_cah_toa: it's the only humane option left. The threads are suffering
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?
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
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.
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
cotto_work chromatic: that's encouraging, though it depends on when mls stops adding features
Coke partcl doesn't care if you nuke threads before replacing it.
01:07 preflex_ joined
soh_cah_toa whiteknight: have you noticed a decrease in runtime performance at all in your branch w/o threads? 01:07
whiteknight soh_cah_toa: no decrease. 01:19
soh_cah_toa impressive
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?
soh_cah_toa whiteknight: www.tcl.tk/doc/howto/thread_model.html 01:21
whiteknight smartypants 01:23
soh_cah_toa++
soh_cah_toa had that bookmarked for some reason :\\
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
oh, i think i gotta re install
b/c of that whole pbc thing w/ hbdb blah blah blah
nevermind ;) 01:25
Coke whiteknight: partcl hasn't done anything with threading on parrot yet, which is why you get a pass.
cotto_work It's a chicken and egg problem. Hopefully nine can hatch something soon. 01:27
whiteknight Coke: Okay, then we'll make sure the new system is compatible with tcl's model, and make a gift 01:29
cotto_work: it won't just be nine. We'll assemble a group of highly skilled code ninjas around him to help out
atrodo dukeleto: ping 01:33
dukeleto atrodo: pong 01:38
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:39
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
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
atrodo dukeleto: right
dukeleto atrodo: i am thinking of something like: people.iola.dk/olau/flot/examples/zooming.html
atrodo And I agree on the points to github. Just never did it 01:42
dukeleto: Neat. I like that a bit more
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.
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
not against it, that was just the motivation
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
dukeleto atrodo: would it be possible to only run on every commit on parrot.git, but run only on commit tips for rakudo ?
atrodo dukeleto: actually, when I get a parrot commit, i find the closest rakudo that was before the parrot commit 01:45
dukeleto atrodo: ok. so does that mean if we make parrot bench every commit, it won't make rakudo do the same? 01:49
atrodo: i think it is really important for parrot to know the exact commit that causes a performance change
atrodo: i am going to try to add the github-link thing now. I forked itfy.git
atrodo dukeleto: correct. Parrot is the "parent" project, and rakudo is the "dependent" project
dukeleto: Yea, apparently i have quite a few outstanding changes. thought I had cleaned that up, but apparently not 01:50
dalek sella: d49252c | Whiteknight++ | s (4 files):
Add in a new prototype Stream queryable. It takes any iterable object and iterates over it lazily.
 01:51
chromatic One difficulty of profiling Rakudo wrt Parrot is that Rakudo isn't a fixed point itself. 01:54
In other words, benchmarking two moving targets against each other isn't technically science. It's climatology. 01:55
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:56
pmichaud_ however, Rakudo in 2011 has thus far been largely fixed. 01:57
Any changes in the rpbench reports are primarily due to changes in Parrot.
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.
We haven't started nom results. I agree that those will be apples-to-oranges comparisons.
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
dukeleto atrodo: woot 02:04
cotto ~~ 02:11
02:25 benabik joined
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.
benabik o/ 02:34
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.
cotto I'm here 02:41
d'oh
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)
aloha OK. I'll deliver the message.
benabik Don't know if he'll be back, but thought that might be an interesting thing for him to know. 02:42
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.
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:47
(I'm just throwing out comments as I backlog in the theory that someone else might backlog and see them. :-) 02:53
03:00 schmooster joined 03:07 Khisanth joined
Coke I just did: feather.perl6.nl/~coke/bench/html/ 03:11
(many things needs fixing, but that's a first pass at flotifying github.com/pmichaud/rpbench-result...200238.txt 03:12
pmichaud_ it would also be good to look at orange or plum, which are more typical in terms of processor/memory 03:15
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.
pmichaud_ that would be awesome
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 03:30 JimmyZ joined
dukeleto Coke: nice work on Is Rakudo Fast Yet! 03:34
Coke++ 03:35
03:48 Khisanth joined 03:50 Khisanth joined 04:20 davidfetter joined
Tene plobsing: I've got a server that doesn't do much, if you want to use it to compile statistics. 04:36
04:45 JimmyZ_ joined
cotto dukeleto, ping 04:46
dukeleto cotto: pong 05:00
cotto dukeleto, what did you mean when you said we should start distancing ourselves from Rakudo?
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.
dukeleto cotto: i guess i meant something like disentangling
cotto: and to focus on interop of languages other than perl 6 05:01
cotto dukeleto, disentangling sounds like more marketing than anything. Is that what you mean? 05:02
dukeleto cotto: not sure. what do you mean by marketing? 05:04
cotto dukeleto, dealing with how people perceive Parrot 05:05
dukeleto cotto: it has a lot to do with that, but there is a specific kind of product snuggled inside the marketing 05:06
cotto: a kind of product parrot needs
cotto dukeleto, libparrot?
dukeleto cotto: something that some free/open source community will find useful
cotto: tell me a story about libparrot 05:07
cotto: i see some similarities between libgit2 and libparrot, in the niches that they fill
cotto dukeleto, interesting parallel 05:08
dukeleto cotto: "there was once a pile of code, now we are making it a library"
cotto: the internals of git 1.x makes IMCC look shiny
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:09
cotto: who would use libparrot and what would they use it for? 05:10
cotto dukeleto, that's the impression I have
sorear dukeleto: plparrot is the first "real" project that comes to mind 05:11
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
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
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:15
sorear stored procedures improve speed? how? 05:18
(but I was asking about mod_parrot)
dukeleto rblackwe++ also suggested embedding into screen 05:21
sorear: i never met anybody that actually used mod_parrot for anything
sorear dukeleto: why don't prople use mod_perl?
sorear plugs tmux
dukeleto sorear: people write stored procedures in C for postgres for speed 05:22
sorear: i would greatly enjoy seeing parrot embedding in tmux. There is a shiny new embed api... 05:24
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:25
sorear: they just want to sell snake-oil and serve adds. web frameworks do that quite well :) 05:26
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.
github's great for that
dukeleto cotto: i haven't read the message, may wait until morning 05:30
cotto dukeleto, wfm
I just don't anyone to think that we're suddenly going to stop caring about Rakudo.
dukeleto cotto: no, i wasn't trying to say that. But I figured some people would take it that way. 05:32
cotto: currently trying to get m0 to not peg a core on nbrown++'s new pull request
Tene I used mod_parrot for a few toy apps. 05:33
I gave a presentation on it, and showed a toy mod_lolcode app.
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.
Tene I rather agree with you, though.
dukeleto Tene: i care about language interop
sorear If we disassociate Parrot's brand from Perl 6, will it make people in general take Parrot more seriously? 05:35
that is the question that needs asking
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
sorear: yes
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.
dukeleto Tene: we can even have fudge tests, because a lot of those tests can be generated by smart test-writing code
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
dukeleto++
pmichaud_ I think the question is not only "if we disassociate", but also "is it even possible"?
I think the experience of the past two years may show that it's not really possible.
dukeleto Tene: so what if I take you up on it? 05:37
pmichaud_: disentangle, not disassociate
pmichaud_ dukeleto: sorear's question was "disassociate"
dukeleto pmichaud_: the word distancing was imprecise and I am sure, misunderstood
pmichaud_ with respect to branding.
dukeleto pmichaud_: i don't think parrot's failures have anything to do with rakudo leaving the nest
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:38
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
05:39 SHODAN joined
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
cotto Tene, could you sketch your thoughts on a wiki page?
dukeleto Tene: what are the top things that you would change about parrot internals to facilitate hll interop? 05:40
Tene: pretend the dep policy doesn't exist, and you have a running chainsaw in your right hand
Tene: and possibly dynamite
Tene dukeleto: replace the object model with 6model.
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
Tene: i agree with you, and i think most parrot devs do too, so why isn't the code written? 05:42
Tene dukeleto: I wrote it, more than once. 05:43
pmichaud_ the code's been written. It's not been maintained. 05:47
that's of course my (nqp + rakudo's) fault, since we've done some rewrites and refactors that didn't preserve the code.
in the case of nom, what existed in earlier versions of rakudo wouldn't make sense anyway.
sorear dukeleto: I'm trying to keep the distinction between disassociate and disentangle 05:48
dukeleto: I think Rakudo and Parrot are anti-tangled
Rakudo generally tries to use as few Parrot features as possible 05:49
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:50
Tene sorear: it was long since dead at that point. 05:53
dukeleto Tene: are there hll interop tests that I can run? 05:54
Tene: how do I know what works and what doesn't, right now?
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.
dukeleto Tene: i.e. i am not interested the past, but the present and future of hll interop
Tene: what is it? where does the code live? 05:55
JimmyZ likes hll interop :)
dukeleto cotto: just read JimmyZ++'s post
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
Tene: does HLL interop in parrot have any tests? 05:57
Tene dukeleto: short answer: no.
JimmyZ dukeleto: that's trivial
dukeleto Tene: that is why it is broken
Tene dukeleto: That comment rather seems to contradict "not interested in the past", unless I'm misunderstanding you. 05:59
It also doesn't tell me anything I didn't already know.
So, I don't see what you're trying to tell me here.
JimmyZ Tene: HLL interop may be low priority in 2009, parrot is not good enoug, which will lead to many large refactors 06:01
s/enoug/enough/
Tene JimmyZ: yes, I know that HLL interop was low priority in 2009.
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.
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
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.
JimmyZ Tene: I didn't think anything :)
Tene: Things are not always run smoothly 06:05
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
dukeleto Tene: a PDD about interop was deleted? I've never seen or read it. 06:08
Tene dukeleto: It's entirely possible that I'm misremembering something. My memory isn't very reliable. 06:09
pmichaud_ iirc, there were aspects of hll interop in pdd21, yes. 06:10
pmichaud_ looks.
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
Tene: that doesn't need a spec. It needs some tests.
Tene Yes, removed in r49249
dukeleto Tene: what was the filename?
Tene dukeleto: git log -- docs/pdds/draft/pdd31_hll_interop.pod 06:11
dukeleto Tene++ 06:12
Tene I wouldn't be surprised to find out there were also lies in that document when it was deleted.
cotto Tene, they're common in the pdds
Tene And, uh, apparently I never committed to that file?
dalek rrot/m0-prototype: 654dee6 | nbrown++ | t/m0/m0_integration.t:
Fix m0_integration test when using $ENV{M0_INTERP}

In the m0_integration tests, use "$ENV{M0_INTERP}" or "perl m0_interp.pl", but not "perl $ENV{M0_INTERP}".
rrot/m0-prototype: 7a42557 | nbrown++ | config/gen/makefiles/root.in:
Fix setting M0_INTERP on Windows in the Makefile

The *nix style of setting an environment variable doesn't work in Windows. So if the platform is win32, set the M0_INTERP using the Windows 'set' syntax. Also, use backslash as the path seperator on Windows.
rrot/m0-prototype: c4b3eb6 | dukeleto++ | src/m0/c/Makefile:
Add a clean target to M0
dukeleto [docs]: Remove obsolete (and incorrect) draft/pdd31_hll_interop.pod .
Tene So, apparently I wrote some document, and never committed it to the repo.
dukeleto that is the last commit i see
Tene: huh. That would make it hard to implement. 06:14
cotto: can you tell me if "make m0_c_tests" hangs on a non-windows box for you?
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
sorear Tene: there was at one point two pdd31s in the repo
dukeleto cotto: i think the env var for the integration tests only works on windows now
Tene sorear: yes, apparently the deleted one was not where I put notes about this. 06:17
dukeleto: look at, for example, 2919163e2e7388e74a59c54d78182e4f1b8812af
I was apparently referring to something there, and iirc I was following changes made (or requested?) by pmichaud there.
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:18
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
or maybe it was just that something in pct or hllcompiler somewhere registered something else urnelated as 'compreg "parrot"'
dukeleto $ parrot runtime/parrot/languages/parrot/parrot.pir
Class Compiler already registered!
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
Tene dukeleto: YEs, as I already said, twice.
dukeleto Tene: is that the only way to test parrot.pir ? Does anything use it?
Tene dukeleto: Sorry if I seem testy here; I seem to be unusually irritable today. Perhaps I haven't been sleeping well. 06:21
dukeleto Tene: you do seem testy, but I have a thick skin :) 06:23
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?
Tene dukeleto: It's currently broken. If it's failing like that when loaded by parrot, it's broken. 06:25
unless, uh... maybe it's trying to run the :load sub twice or something?
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
so, not broken.
I'm pretty sure that the issue was that pct was installing something as the "parrot" compiler 06:30
but I can't find evidence of that
dukeleto Tene: what does the actuall call to load_language look like? 06:31
Tene Ahh, there we go... 06:32
ext/nqp-rx/src/stage0/HLL-s0.pir +7610
it's nqp
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
dukeleto Tene: load_bytecode 'parrot/parrot' doesn't work 06:35
Tene dukeleto: load_bytecode 'parrot'
most languages should usually register a compiler with compreg 06:36
pmichaud_ all of the HLLCompiler and HLL::Compiler based languages use compreg. 06:37
Tene Yes.
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'
Tene if it's not there and you want to load it, you call load_language and then try again
dukeleto: sorry, I misspoke. you want: load_language 'parrot'
load_bytecode 'parrot' will look in $libdir/library/parrot.pbc 06:39
languages live in $libdir/languages/parrot/parrot.pbc
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:41
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.
pmichaud_ Tene: just for clarification, note that what you're calling NQP we now call nqp-rx
to distinguish it from the new nqp that has 6model included.
dukeleto pmichaud_: how do you feel about nqp-rx not fiddling with the 'parrot' global namespace ?
Tene pmichaud_: uhh... yes, that's right. 06:43
I'm a bit out of touch these days. :)
pmichaud_ I'm pretty sure that nqp (the new one) doesn't create a 'parrot' compiler.
dukeleto: there's two answers to that 06:44
dukeleto the mystery deepens...
pmichaud_ dukeleto: if you want to put the nqp-rx compiler itself into its own hll namespace, no problem.
but mostly what nqp-rx provides are shared libraries
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:45
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
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.
dukeleto pmichaud_: does anything actually register a 'parrot' compiler? 06:48
pmichaud_: all i know is that nothing but parrot internals should be registering a compiler called 'parrot'
pmichaud_ dukeleto: iirc, pct registers the 'parrot' compiler. 06:49
dukeleto pmichaud_: ok, so it is PCT, not nqp-rx 06:52
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.
pmichaud_ and PCT definitely believes that it can live in the 'parrot' namespace (more)
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.
afaik, it was the first to do so.
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:55
But, yeah, something like that. 06:58
dalek rrot: 60c22d7 | dukeleto++ | / (4 files):
[t] And then there were HLL interoperability tests
 06:59
dukeleto i am hearing a lot of miscommunications
Tene the only thing I can see that's registering a parrot compiler (besides languages/parrot/parrot.pir) is nqp-rx
dukeleto Tene: is there any way you can put whatever you wrote about interop that never made it into parrot.git somewhere?
cotto or a wiki or github page or a napkin mailed to PaFo 07:00
Tene dukeleto: "whatever I wrote" may or may not still exist anywhere. I can certainly write something equivalent, though. 07:01
I'll also take a look at my old laptop to see if I can find any clues. 07:02
cotto, dukeleto: Some of this is already documented on trac.parrot.org/parrot/wiki/HllInteroperability 07:08
cotto Tene, that's great. 07:12
dukeleto we lost a lot of useful info when that hll interop pdd was deleted 07:25
it wasn't a design doc, but never-the-less, it was useful info.
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.
Not just out of some sense of idealistic virtue or something; there were actual reasons and motivations for that.
cotto Tene, that's not something I've forgotten. Perhaps it hasn't gotten enough mention. 07:28
There are real and valid reason to provide a support policy like the one we're moving away from.
Parrot isn't mature enough for those reasons to be compelling (though we thought we were). 07:29
07:29 mj41 joined
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:30
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.
pmichaud_ Rakudo suffers this problem, as well.
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:33
but we also expect any deprecation policy to accur at the Star level, not at the compiler one. 07:34
s/Star/distribution/
because we don't want to chain language development to userbase needs
dalek rrot: e934aa8 | chromatic++ | src/packfile/api.c:
[PCC] Optimized CS switching invoke.

These checks can go away with threading system improvements, but avoiding this function call which is almost always a do-nothing gives a modest performance improvement to the default case of Sub's invoke.		 08:01
rrot: 39c5578 | chromatic++ | src/packfile/api.c:
[PCC] Rearranged CS switching code slightly.

I think it's clearer this way.
rrot: b22c10c | chromatic++ | src/call/context.c:
[ctx] Made init_context tailcallable.

This modest optimization is in a PCC hot path. A decent optimizing C compiler should shave off a few assembly instructions. As a bonus, it makes our C source code shorter and simpler.
rrot: f215ea6 | chromatic++ | src/pmc/object.pmc:
[OO] Optimized get_attrib_index slightly.

Avoiding unnecessary work along this hot path improves performance.
rrot: f457a74 | chromatic++ | src/pmc/object.pmc:
[oo] Removed an (unused?) attribute cache.

As far as I can tell, this never worked and never should have worked and was probably copy and paste code someone (probably me) never finished. Getting rid of it allows for more interesting possibilities.
rrot: 75f735e | chromatic++ | src/pmc/class.pmc:
[oo] Made the class attribute cache an INTVAL hash.

This avoids allocating Integer PMCs when caching attribute indices and avoids the need to extract INTVALs from said PMCs when looking up attributes. Clearly this is an improvement.
chromatic Aggregate total, a 2.65% improvement on a real-world parrot-nqp benchmark. 08:02
OO and PCC heavy code will benefit the most.
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:03
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:05
Tene I've been curious about 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
6.37%
aloha 0.0637
Tene although, I think that's an old version of rakudo...
cotto, dukeleto: do either of you have any good references for how HLL interop works on other VMs? 08:15
iirc, I've heard it's pretty reasonable on JVM? 08:16
moritz all languages act as if they were java :-)
cotto Tene, no idea. My best guess is what moritz said. 08:19
JimmyZ Tene: javascript works well on JVM 08:21
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: download.oracle.com/javase/6/docs/a...nager.html
Tene cotto: apparently perf claims to be fairly similar to oprofile. 08:26
cotto Tene, I'll have to look into both of them in the near future. 08:27
mls morning! 08:30
cotto hio mls 08:31
mls cotto: does valgrind measure syscall time?
cotto mls, no idea
Tene 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
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
cotto plobsing++ verified that it always does a syscall
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
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.
mls I added a mark() function yesterday, cause the sub pmcs in the sub data were freed causing segfaults 08:36
did you run the latest version?
cotto yup
nopaste "cotto" at 192.168.1.3 pasted "use Hash in subprof" (166 lines) at nopaste.snit.ch/79169 08:37
cotto mls, there's the patch
Tene oh, very nice, 'perf report' is interactive, lets me zoom in to annotated versions of every symbol, etc. 08:40
cotto want
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:41
cotto Tene, what are you profiling? 08:42
Tene cotto: a portion of the rakudo build, right now 08:43
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
not as big as all of CORE.setting, but still big-ish
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
Tene cotto: lemme know what you find out 08:46
If it's really spending 11% of its time getting items from the free list, that's unfortunate. 08:47
after that is 4.8% gc_gms_sweep_pools
cotto Tene, there's a branch to address that.
something of whiteknight++'s doing at jnthn++'s suggestion
Tene cotto: to improve get_free_list_item? 08:49
dalek kudo/nom: 0c6ec02 | (Martin Berends)++ | lib/Test.pm:
[lib/Test.pm] move time recording operations as near as possible to tests
 08:50
cotto Tene, I think so. might be something else gc-related 08:51
dalek kudo/nom: 4967c55 | (Martin Berends)++ | tools/test_summary.pl:
[tools/test_summary.pl] add a --view option to report on test times
cotto I'm going to bed. 'night 08:52
mls (sorry, had to do some dayjob work) 08:55
good night!
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:02
mls something different: shouldn't key_hash do some shifting/rotating in the pointer case? 09:08
seems it simply uses the (pointer & hash->mask) as bucket index 09:09
that means the lower bits are probably constant 09:10
09:16 not_gerd joined
not_gerd hello, #parrot 09:16
tadzik good morning parrots 09:17
mls Hi tadzik! 09:19
(and not_gerd!)
not_gerd good morning, mls
Tene: did you profile an un-optimized Parrot? 09:20
there are some #ifdefs in gc_gms_validate_objects() which probably make it a NOOP in optimized builds...
09:32 woosley left
dalek rrot: 91b0b55 | jimmy++ | src/gc/fixed_allocator. (2 files):
remove unsed total_objects from struct Pool_Allocator
 09:33
Tene not_gerd: dunno; is optimized default? 09:38
argh wtf am I still doin gup 09:39
Tene sleep now bye
09:46 JimmyZ joined 09:49 ambs joined
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 10:18 plobsing joined 10:21 lateau left 10:49 ambs joined
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.
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
Coke ponders a parrot plack alike. 11:16
11:17 woosley joined 11:32 cosimo joined 11:34 Psyche^ joined 11:41 JimmyZ joined 11:49 benabik joined 11:55 pmichaud joined 12:00 SHODAN joined
benabik o/ 12:11
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".
benabik mls: whiteknight should be on shortly, based on his normal habits. :-) 12:15
mls ok, thanks.
why does Parrot_pcc_invoke_from_sig_object() call Parrot_push_context()? 12:30
(I see the extra frame in the profiler output) 12:32
the invoke() call also allocates a context (or uses the call_object) so I don't see the point of the extra context 12:33
benabik mls: invoke_from_sig_object calls push_context then invokes the right function, which itself calls push_context? 12:35
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.
Rip it out and see if anything breaks? :-D
mls I'll check the code of methods/nci subs first. Maybe it's done for them. 12:37
It might be a fossil of the time where call object and context were two PMCs 12:38
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
mls running 'make test'... 13:02
13:04 JimmyZ joined
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:05
mls good to hear! Btw, I updated it to parrot master 13:06
cotto I saw, after attempting to commit my changes. ;)
mls sorry ;)
cotto that'll teach me
mls But I also pushed your Hash change 13:07
cotto thanks for keeping it current
are you interested in a commit bit
?
and do you mind sending in a CLA?
benabik mls: You are interested in a commit bit. </jedi>
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)
mls yes
cotto on the one hand, awesome. On the other, I hope they're ok with it going into parrot. 13:09
what company?
mls I don't see any problems, as SUSE is doing OSS work anyway. Upstream work is pretty common.
(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. ;)
mls yes, from time to time ;)
cotto Are they paying you specifically to work on profiling or is it something discretionary?
mls no profiling at all. 13:12
I'm the maintainer of the 'perl' package, thus when perl6 arrived I also created the 'rakudo' and 'parrot' packages
tadzik that's cool 13:13
cotto good deal
mls therefore I lurked on the channels for quite some time
cotto I'm glad to know that you'll be sticking around.
moritz mls: are you still in the Nuernberg/Erlangen area?
mls yes, Nuernberg
moritz mls: there's a monthly perlmongers meeting in Erlangen :-)
if you ever want to meet me (and other perl hackers) personally 13:14
mls I confess I've never been there yet
(But I gave a perl6 talk at the last openSUSE conference and met some of you guys) 13:15
(Now testing the setting compilation with the patched Parrot_pcc_invoke_from_sig_object...) 13:17
diff: gist.github.com/1203368 13:18
that's two PMC allocs less, should make pcc_invoke_from_sig_object quite a bit faster 13:19
and the profile output is nicer, too ;)
tadzik like 13:20
trying it too
benabik mls: OOC, any numbers on speed change? 13:21
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)
tadzik I
'll measure it once it build it
mls thanks!
cotto: I don't think it's worth it, as the number of subs isn't that big 13:23
cotto probably not 13:24
mls what worries me more is that the hash code just uses the pointer as key 13:25
cotto Isn't that what the previous code did? 13:26
mls i.e. bucket_index = pointer & hash->mask
no, it shifted the pointer a bit
the problem is that most allocators return aligned memory, thus the lower bits are zero all the time 13:27
cotto interesting question 13:29
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
wow, overclocked!
tadzik was make 400.76s user 5.18s system 108% cpu 6:12.86 last time I measured
mls so 6% less. 13:31
5.18 -> 4.91
tadzik maybe. I'm not sure how to read this :)
mls oh wait, read it the wrong way
so it's slower! 13:32
tadzik no, not really. Was 5.18s, is 4.91s
trying spectest now
cotto tries to go back to sleep
mls sleep well! 13:33
13:44 dod joined 13:55 whiteknight joined
whiteknight good morning, #parrot 13:56
mls morning!
benabik o/ whiteknight
whiteknight good morning mls, benabik 13:57
mls I've a little idea that would make parrot calls quite a bit faster.
whiteknight do tell 13:58
mls (my numbers are from compiling rakudo's setting)
but I promise you won't like it ;)
benabik mls: whiteknight loves removing things.
mls so, it currently spends 28% in invoke() 13:59
more than half of the time in invoke is spend in allocating the continuation PMC
moritz
.oO( remove invoke()! )
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
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
mls That's why I said you won't like it, as IMHO you want to split the continuation again
tadzik tries again w/o the new patch
mls err callcontext
cotto didn't work 14:02
so, good morning!
JimmyZ ....
mls we could do it in a compatible way, i.e. when somebody asks for the continuation, we can generate it
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 :)
cotto (sleep didn't work, not referring to mls' work)
whiteknight mls: lazy create the continuation? I like the concept
mls returncc would only use the continuation if it was generated, otherwise use the data from the callcontext
(all this is because PMC alloc is so slow)
whiteknight for the simple case of a subroutine return, we can definitely do an optimization like that
mls: would you be able to prototype such a thing? 14:04
or, do you need some help to do it?
mls It's not hard to do, I think.
But didn't you want to split the callcontext again?
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.
mls (basically we want one PMC which is a mixin of callerargs, context and continuation ;) )
whiteknight mls: we can still split the callcontext, but on a different axis
benabik Why is allocating a Continuation slow? If we're CPS, we'd rather like that to be fast.
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
benabik Poor.
whiteknight right now it requires two allocations: the fixed-size PMC header and the attributes structure
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)
half of the pmc_new time is spent in GC (on average)
whiteknight allocating a new PMC can trigger a GC run, so that throws off the numbers 14:08
14:08 nbrown joined
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
whiteknight individual allocations can be made faster, and GC can always be kicked and tuned 14:10
mls anyway, I'll try the continuation change and try to verify the numbers 14:11
whiteknight mls++
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: gist.github.com/1203368
whiteknight but, if the numbers look really good here, it is a data point to consider
mls (premature optimization: right)
whiteknight what does that patch do?
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.
mls (I saw the extra context in the profile output)
benabik: I don't think so. It could mean less GC runs, thus a speed improvement
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"
mls: Don't be fooled by "oh, invoke takes less time"
14:14 mtk joined
mls yes, the goal is to reduce the runs, not move them 14:15
cotto fewer GCables is fewer GCables
mls whiteknight: make test didn't show any error with the patch, but I'm no callcontext expert
so I like to hear what you think of the patch
14:16 JimmyZ_ joined 14:19 JimmyZ__ joined
benabik mls: What continuation are you killing? The return continuation? Wouldn't that have to be created eventually anyway? 14:21
14:22 JimmyZ joined
mls the contination created by invoke (as NEED_CONTINUATION was set) 14:22
14:23 JimmyZ___ joined
whiteknight mls: let me fire up a vm and try that patch 14:23
14:25 JimmyZ_ joined
benabik mls: In Sub.invoke(), you mean? 14:29
mls yes 14:31
14:32 JimmyZ_ joined
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:32
benabik could be wrong. 14:33
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.
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
when somebody asks for the continuation, it would get created from the stored data, so we stay compatible
returncc would use the continuation if present, otherwise it would not create the continuation but use the stored data 14:36
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
what exactly triggers the GC? 14:38
14:40 JimmyZ_ joined
mls ah, mem_used_last_collect > gc_threshold 14:41
tadzik without the patch: make spectest 1418.80s user 71.44s system 99% cpu 25:03.36 total 14:42
rakudo: say (1418.80 - 1407.13) / 1418.80
p6eval rakudo 4967c5: OUTPUTĀ«0.00822526078376092ā¤Ā»
benabik (1418.80 - 1407.13) / 1418.80
0.8%
Fun. 14:43
aloha 0.00822526078376082
0.008
tadzik aloha: you should switch from abacus to a calculator
benabik tadzik: No kidding.
tadzik mls: almost 1% win it seems :) 14:44
(in this specific case) 14:45
dukeleto ~~
mls not much. But it also improves the profiler output ;)
tadzik (: 14:46
benabik I like speed win and better output.
whiteknight benabik: commit and push it 14:48
benabik whiteknight: It ain't mine. :-D
tadzik: commit and push it
:-D
whiteknight whoever did it, push the damn thing
tadzik benabik: It ain't mine. :-D 14:49
but I can push it, free karma
benabik tadzik: mls doesn't have a bit yet. Sadface
tadzik that's wrong
Commit message?
mls get rid of superfluous context creation in Parrot_pcc_invoke_from_sig_object 14:52
something like that
whitknight: so no objections from your side?
whiteknight: so no objections from your side? 14:53
dalek rrot: bf43ce2 | tadzik++ | src/call/pcc.c:
Get rid of superfluous context creation in Parrot_pcc_invoke_from_sig_object. Patch courtesy of mls++
whiteknight mls: no objections 14:54
14:54 dmalcolm joined
whiteknight cotto_work: ping 14:55
14:59 Kulag joined
whiteknight dukeleto: ping 15:01
cotto_work ~~ 15:04
whiteknight: pong
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
whiteknight benabik: EITCANWAIT
cotto_work mls: I want to make sure he can sign a cla. Apparently he needs to talk to some people at $dayjob.
I know what you mean though.
benabik whiteknight: Lawyers disagree. :-/ 15:06
cotto_work he works for SUSE, so hopefully they're cool
whiteknight it makes no functional difference whether he commits to a fork and we pull, or whether he commits directly to our repo
dukeleto whiteknight: pong
whiteknight dukeleto: I was going to ask you the same thing I just asked cotto RE: mls getting a commit bit 15:07
15:07 alester joined
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
the biggest thing a CLA does is grant Parrot an explicit license to use the contributions
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
moritz (note that in .de, entanglement with employer isn't as bad as in the US) 15:11
whiteknight is mls in .de? 15:12
moritz yes
about 20km from my place :-)
whiteknight moritz: I may have to send you over to his house one day with a case of beer.
moritz whiteknight: :-)
or better yet, there'll be a German Perl Workshop in March 2012 at my place (Erlangen) 15:13
that should be a nice incentive for a visit, and could warrant a beer or two
dalek kudo/nom: a392725 | jonathan++ | src/Perl6/Actions.pm:
Toss unused variables and initializations.
 15:14
kudo/nom: 842c4f7 | jonathan++ | src/core/EXPORTHOW.pm:
Remove workarounds; replace a bunch of PIR ops with NQP ops.
cotto_work and there's yapc::eu 2012
mls beer? where? ;)
moritz cotto_work: right, also a mere 200km away 15:15
cotto_work moritz: in America that's not far. ;)
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
dalek rrot: 77e1274 | dukeleto++ | tools/dev/README (2 files):
Markdownify toos/dev/README
 15:17
rrot: 34e7377 | dukeleto++ | tools/dev/ (2 files):
[doc] Add useful information to tools/dev/README
rrot: 863ad6d | dukeleto++ | MANIFEST:
Update manifest
dukeleto mls: do you actually commit work while physically at $dayjob ? 15:20
whiteknight: i am inclined to say no commit bit unless there is a CLA. It is the prudent thing to do, though annoying.
mls yes.
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
benabik Sometimes I think the acronym is off by a letter. It's more a CYA.
dukeleto mls: github.com/parrot/parrot/blob/mast...rkflow.pod tells you everything you need to know about working in a fork
mls I already do that with the sub-profiler: github.com/mlschroe/parrot 15:22
dalek kudo/nom: 7360e33 | jonathan++ | src/Perl6/Grammar.pm:
Unify EXPORTHOW handling, avoid some code duplication, make nested settings work.
 15:23
kudo/nom: 7c001ff | jonathan++ | / (3 files):
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.
rrot: 8299931 | dukeleto++ | tools/dev/README.md:
[doc] Add some useful docs about dedeprecator.nqp
 15:25
dukeleto mls: yes, that works well for now
cotto_work mls: that said, I'm eager for you to get a commit bit 15:26
mls I must warn you: I'm currently spending too much time on parrot 15:27
dukeleto mls: aren't we all :)
whiteknight mls: it's a disease :)
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/` ...
mls like the opensuse build service (my main project actually)
which I'm currently neglecting a bit 15:29
(I just had too much fun implementing the profiler, I guess ;) ) 15:30
15:33 darbelo joined
cotto_work mls: it happens 15:33
probably not often enough 15:35
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.
dukeleto moritz: i have been trying to contact him. He seems to still exist on Twitter
JimmyZ bacek is active on facebook :)
tadzik (: 15:41
15:52 darbelo_ joined 16:06 JimmyZ_ joined
dalek sella: 856b944 | Whiteknight++ | s (4 files):
Add in a new Tokenizer.Iterator for String. Add a few other enhancements to make tokenizers and tokens easier to use
 16:11
sella: edaa0f5 | Whiteknight++ | src/template/ (2 files):
Use the new tokenizer iterator in the Template library for modest cleanups
16:16 ambs_ joined 16:27 darbelo joined
dalek kudo/nom: a2a5ab8 | jonathan++ | src/Perl6/Actions.pm:
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
tadzik Failed allocation of 7166182913849190824 bytes 17:00
Parrot VM: PANIC: Out of mem!
now, that I haven't seen before :)
benabik That's a lot of bytes.
tadzik b: say 7166182913849190824 / (1024*1024)
p6eval b 1b7dd1: OUTPUTĀ«6834204591607.28ā¤Ā»
tadzik ...how many>?
Sorry, coredump is not yet implemented for this platform. 17:01
...for linux?
Parrot crashes could be better :P
dalek kudo/nom: c8b7c99 | jonathan++ | src/Perl6/Metamodel/ (2 files):
Curried roles should be punnable and able to be passed around.
 17:03
17:10 JimmyZ_ joined
dalek nxed: 517d063 | NotFound++ | winxedst0.cpp:
constant propagation for operators << and >> in stage 0
 17:12
nxed: 20bcd02 | NotFound++ | winxedst1.winxed:
use << operator in the definition of some flas
 17:16
17:17 contingencyplan joined 17:25 darbelo_ joined 17:27 darbelo joined 17:42 darbelo joined 17:55 darbelo_ joined 17:58 darbelo joined 18:02 chromatic joined
dalek nxed: 3374e4f | NotFound++ | / (3 files):
new builtin __ASSERT__ in stage 0
 18:25
chromatic Hm, opsc reads its files as UTF-8 but they can probably be transcoded to ASCII or ISO-8859-1. 18:49
There's a 33% speedup waiting for that. 18:50
whiteknight improving opsc by 33% would be gorgeous 18:56
19:01 preflex_ joined 19:02 Coke joined
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
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:03
nine that seems to include all commits that have been on master. I would like to see the commits on the branch only 19:04
whiteknight oh, then use ... 19:07
instead if two ..
one of those does the right thing
nine aaah...huge difference
dalek kudo/nom: 591c694 | moritz++ | tools/build/Makefile.in:
whitespace fix in Makefile.in, GNU make really wants tab characters
 19:17
chromatic Hm, I was wrong. It's 35%.
nine is trying to find out what exactly the status of gsoc_threads is and where to start 19:18
19:18 p6eval joined
cotto_work nine: look for gsoc blog posts on parrot.org 19:20
dalek rrot: 58e1e20 | chromatic++ | lib/Parrot/Pmc2c/PMC.pm:
[Pmc2c] Replaced a string with a constant string.

This is a tiny bit of bookkeeping I noticed on the way to something better.		 19:25
rrot: a23acf4 | chromatic++ | compilers/opsc/src/ (2 files):
[opsc] Added fixed-width transcoding to opsc.

Where this is possible, it speeds up opsc on one benchmark by 35%, at the expense of a one-time transcoding cost. As our .ops files are primarily ASCII and only theoretically Latin-1, this is a huge improvement.
19:27 darbelo joined
dukeleto ~~ 19:30
cotto_work hio dukeleto
dalek nxed: e171a2f | NotFound++ | winxedst1.winxed:
implement __ASSERT__ in stage 1
 19:33
19:35 mj41 joined, benabik joined
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:35
dalek sella: d79fc7f | Whiteknight++ | src/harness/TapParser.winxed:
fix a case where a test without a name caused an index out of bounds
 19:36
esop: df19d0a | Whiteknight++ | / (3 files):
Cleanup the harness with new improvements to Rosella. Sort test files by name
whiteknight nine: I've considered a very similar thing in the past 19:37
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
nine: If we could do nothing but implement just that little feature, I would call it a big success 19:38
benabik AIO implemented as blocking IO on a thread has the virtue of simplicity. 19:40
dalek kudo/nom: c34ac6e | moritz++ | src/SAFE.setting:
forbid more functions in SAFE.setting
whiteknight benabik: the more we can have everything integrated into a single dispatch/scheduling framework, the better 19:41
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
dukeleto nine: did you find something to hack on? 19:43
benabik nine: If threading works, AIO as threaded IO is quick to implement.
cotto_work dukeleto: not enough
benabik Personally I'd almost prefer blocking IO as AIO with waiting. :-D 19:44
cotto_work but I got an early start
benabik Although I suppose realistically, we _want_ AIO and IO to be implemented on top of the system level versions of same.
nine: Really, as soon as you have threading you want some kind of event/notification system anyway. 19:45
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())
NotFound: Perhaps I am unfamiliar with terminology here, but doesn't AIO == non-blocking? 19:47
whiteknight benabik: depends who you talk to
benabik whiteknight: I'm apparently talking to NotFound. ;-)
19:47 jevin joined
NotFound benabik: AIO is usually: call some notification or termination function when you are ready. 19:47
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
whiteknight whiteknight.github.com/2009/05/01/a...arrot.html
benabik (Roughly)
NotFound benabik: non-blocking synchronous is just: if the task can't be done right now, return.
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
not everybody is very precise when throwing those terms around
benabik whiteknight: Fair enough.
NotFound benabik: well, the part that reads whenever can is the termination function, just isn't user provided. 19:50
In this field I prefer the windows terms. 19:51
The win32 api is very good in that things. 19:52
19:54 Coke joined
NotFound But yes, you can avoid the callback and check later the state of the object to see when the operation is completed. 19:54
In non-blocking synch, on the contrary, you must redo the operation later, if not completed at the first attempt. 19:56
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.
NotFound (or partially redo, if some bytes have been read/writen)
whiteknight nine: Right, that's where we need full OS threads at some point 19:58
the hybrid situation works the best, in my estimation
benabik Even if the interpreter can't be spread across multiple threads, we can spawn limited OS threads as workers.
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
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
performance will suck eggs on those systems, but the code will still work
NotFound We can probably fake some async IO just using non-blocking and timers.
dalek rrot: 7b8bf15 | chromatic++ | src/pmc/class.pmc:
[OO] Added object attribute storage initialization.

This presized cache avoids the need to allocate (and re-allocate) storage for object attributes on access. It's a small improvement until a unified object-and-storage strategy exists.
rrot: 35318ef | chromatic++ | src/gc/fixed_allocator.c:
[GC] Rearranged code in pool allocator.

This is a tiny simplification which should give a very modest performance improvement.
20:00 wagle joined
dalek rrot: ac4409f | chromatic++ | src/call/args.c:
[PCC] Set arg_flags on CallContext directly.

This avoids a vtable call and a STRING comparison in the common case, and should not harm subclassing at all. This ought to improve performance of external calls by a modest amount.		 20:00
chromatic When does IPFY update? 20:01
benabik gtg
whiteknight chromati: that's a good question
or chromatic
NotFound chromatic: 7b8bf15 Can't that array be fixed length? 20:03
dukeleto chromatic: it gets a post-receive hook from github 20:04
chromatic: but it takes roughly 30 mins to build on that machine, which is an old p4
chromatic NotFound, the only possible reason it might not be is to support morph, but I think you're right.
Just curious about these tuning results, as I expect ~6% improvement on OO/PCC heavy code. 20:05
whiteknight that's not bad
chromatic Yeah, that's decent tuning. 20:07
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:10
haven't figured that one out yet 20:11
NotFound chromatic: pass all test with Fixed 20:22
Now that I look at it, I've buil unoptimized and the test wallclock time is better than my lasts optimized builds. 20:24
No noticeable difference between Resizable and Fixed 20:34
20:34 darbelo joined
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 20:38
chromatic What's the message bot on here again? 21:04
cotto_work aloha msg chromatic this one
aloha cotto_work: OK. I'll deliver the message.
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 22:15 whiteknight joined
whiteknight good afternoon, #parrot 22:16
dalek kudo/nom: c9246f9 | jonathan++ | src/binder/container.c:
Fix bug in handling of Scalar type object.
kudo/nom: bf08c52 | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
Generics handling for Scalar.
kudo/nom: aa90c55 | jonathan++ | src/Perl6/Actions.pm:
Specialize generically typed lexically scoped scalars.
kudo/nom: 2c31255 | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
Need to specialize the default value if that's generic also.
 22:17
kudo/nom: db4495a | jonathan++ | NOMMAP.markdown:
Update nommap.
tadzik good afternoon whiteknight. I'm not a bot
Tene good afternoon whiteknight. I'm at least one bot. 22:24
dukeleto Tene: how goes it? Any luck finding your interop writings? 22:26
Tene dukeleto: I haven't had a chance to look yet. I should be able to late tonight. 22:27
22:32 wagle joined
chromatic whiteknight, are you getting rid of do_sub_pragmas? 22:34
dukeleto Tene: may the force be with you 22:42
chromatic Ha ha, how silly is this! 22:43
22:48 preflex_ joined 22:54 wagle joined 23:01 rfw joined
dalek p: 71c8f92 | chromatic++ | src/6model/reprs/ (6 files):
[6model] Added annotations to exception throwers.

This clears up several compiler warnings.		 23:06
p: 93a634d | chromatic++ | src/6model/reprs/P6opaque.c:
[6model] Made a private function static.

This cleans up a warning about the undeclared function.
p: 2922924 | chromatic++ | src/6model/reprs/P6opaque.c:
[6model] Fixed a constness conversion warning.
whiteknight chromatic: That's the plan. I have most of the pragmas untangled, but we're working on the rest of them 23:09
I suspect it will stay around in a simplified way for handling :immediate and :postcomp 23:10
chromatic Good. do_sub_pragmas is ugly.
cotto ~~ 23:15
23:48 cottoo joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!