Parrot 1.8.0 Zygodactyly released | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang
Set by moderator on 23 November 2009.
dukeleto 'ello 00:01
cotto_work hi allison
allison hi cotto
00:02 bacek joined
dukeleto pours bacek a beer 00:02
Tene Any requests for parrot hacking tonight. I think I'm inclined to move abc and squaak over to nqp-rx, if not. 00:13
cotto_work Make Parrot fast.
That shouldn't take very long.
Tene cp /usr/bin/yes /usr/bin/parrot 00:14
chromatic Tene, any of trac.parrot.org/parrot/wiki/ClassV...eOverrides will help.
Tene There was that pir vtable override thing C asked me to do...
Yeah, that.
purl Sure, that.
00:14 plobsing joined
Tene I think that's going to have to wait for a weekend, though. 00:15
chromatic None of the steps are particularly laborious in and of themselves.
One of the first is writing a small program to parse src/vtable.tbl and generate forwarding VTABLE functions. 00:16
Tene Hmm. Okay, I'll try to take a look sooner. 00:17
afk, going home.
bacek_at_work dukeleto, it's too early for beer... 00:18
japhb "too early for beer"? That must not be English, because if it is English, it clearly makes no sense. ;-) 00:39
dukeleto bacek_at_work: i will drink your beer then 00:44
cotto_work clock? 00:49
purl cotto_work: LAX: Mon 4:49pm PST / CHI: Mon 6:49pm CST / NYC: Mon 7:49pm EST / LON: Tue 12:49am GMT / BER: Tue 1:49am CET / IND: Tue 6:19am IST / TOK: Tue 9:49am JST / SYD: Tue 11:49am EST /
00:59 abqar joined 01:15 cognominal joined
plobsing hey, are there any tools for looking at frozen pmcs? 01:27
cotto_work You can read and dump them, but I don't think there are any existing non-trivial tools. 01:30
01:30 theory joined
cotto_work s/can/can write PIR to/ 01:30
plobsing would such tools be useful to anyone (aside from myself)? 01:31
cotto_work if you build it... 01:32
plobsing if I manage to build it.
cotto_work goes home 01:34
01:51 allison joined
japhb decides that figuring out where to insert the UUID code into the parrot make process requires too much brain right now, and goes to watch a Christopher Eccleston movie instead 01:53
Coke japhb: ... I went to high school with a Christopher Eccleston, I think. 01:58
Coke finally sets up ssh-agent. 02:02
yay, github is no longer incredibly painful.
02:19 JimmyZ joined 03:01 bacek joined 03:27 JimmyZ joined
theory seen dukeleto 03:32
purl dukeleto was last seen on #pdx.pm 8 minutes and 57 seconds ago, saying: just found a bug!
03:34 tetragon joined
dukeleto theory: yo 03:36
03:42 KatrinaTheLamia joined 04:20 Andy joined
cotto pmichaud, ping 04:24
04:37 xenoterracide joined 05:22 bacek joined
dukeleto what is this weeks focus for development? 05:57
06:28 particle1 joined
dalek TT #1341 created by plobsing++: [PATCH] hide magic numbers in src/pmc_freeze.c with macros 06:42
cotto I'm all for hiding magic numbers in nasty code. 06:43
plobsing this is just a small start. that code needs serious work. 06:44
cotto Fvery 06:45
s/F//
For future reference, a more descriptive filename than "diff" would be nice.
plobsing i suppose so 06:46
cotto not a big deal, of course 06:50
dalek rrot: r42832 | cotto++ | trunk/src/pmc_freeze.c:
[pmc] name some magic constants, patch courtesy of plobsing++
 06:57
TT #1341 closed by cotto++: [PATCH] hide magic numbers in src/pmc_freeze.c with macros 06:59
07:09 uniejo joined 07:12 theory joined
cotto arbitrary restrictions on passwords make me angry 07:36
07:38 bacek joined
cotto hi bacek 07:39
clock?
purl cotto: LAX: Mon 11:39pm PST / CHI: Tue 1:39am CST / NYC: Tue 2:39am EST / LON: Tue 7:39am GMT / BER: Tue 8:39am CET / IND: Tue 1:09pm IST / TOK: Tue 4:39pm JST / SYD: Tue 6:39pm EST /
dukeleto hola 07:44
cotto good night 07:46
dukeleto cotto: cheers! 07:47
does parrot have something like perl's -I ?
i guess my problem is that i am including .pir that is not installed somewhere
chromatic There should be a -I flag; isn't there? 07:53
dukeleto chromatic: look at that. there is. chromatic++ 07:54
chromatic: i have a TAP harness written in PIR cookin'
chromatic I saw. That'll be super handy. 07:56
dukeleto chromatic: i am benchmarking it now.
chromatic: at first glance, running the tapir test suite with itself, and then t/harness from parrot, it looks like tapir takes about 60-70% of the time 07:57
that should make some people happy
still not feature complete, but getting close
dealing with exit codes properly is the last big feature that needs to be there 07:58
is there any actually preferred format for the test summary? just emulate what Test::Harness does, by default? 07:59
chromatic Why is it faster?
dukeleto chromatic: it is written in PIR instead of Perl 5 ?
chromatic I wouldn't normally expect PIR to be notably faster than Perl 5.
dukeleto chromatic: it doesn't do nearly as much yet, and I need to benchmark it on the parrot test suite 08:00
chromatic: for simple things, PIR is noticeably faster.
chromatic Good to know. 08:01
08:01 allison joined
dukeleto chromatic: parsing TAP can be done with amazingly few tools 08:01
chromatic: and tapir is not optimized *at all* 08:02
chromatic True. T::H 3.x definitely has some overengineering.
dukeleto chromatic: i looked at the implementation. it has a reasonably inheritance hierarchy that must slow it down a bit 08:03
reasonable, even
chromatic Eric had a few rants about that.
dukeleto chromatic: also, i am not using PGE or nqp-rx to parse. Just ye old 'split' opcode 08:04
my biggest motivations are speed and lack of dependencies other than parrot core 08:05
chromatic: looks like tapir is just shy of twice as fast as parrot's t/harness for running the tapir test suite 08:09
chromatic: will try parts of the parrot test suite next 08:10
08:11 iblechbot joined
dukeleto chromatic: gist.github.com/246158 08:13
chromatic: i can only assume that tapir gets faster as the number of tests grows, just by how much memory has to be allocated for each test in Test::Harness 08:14
chromatic True. 08:15
$ cat ~/bin/calc_pct.pl 08:17
use Modern::Perl;
my ($before, $after) = map { tr/,//d; $_ } @ARGV;
my $diff = $before - $after;
say sprintf "%d (%.03f)", $diff, ( $diff / $before ) * 100;
Could be more useful than bc.
dukeleto chromatic: indeed
chromatic: from calc_pct.pl, 44% faster for 62 tests in 4 files 08:21
i think HLL's will really benefit from tapir as well 08:22
chromatic If that holds, we could get make coretest in 20 seconds.
Parallel make test in 32.
... provided you can run tests in parallel. 08:23
dukeleto chromatic: parrallelizing across subdirectories or individual files would be interesting. has any multi-threaded app been written in PIR? 08:24
chromatic A few. 08:26
I don't think you have to do threading though.
dukeleto chromatic: yes, threading is overkill
chromatic: which examples?
chromatic As long as you can popen an external process and not block on reading its output, you should be fine.
There are a few in t/SOMETHING/threads.t.
dukeleto chromatic: sweet 08:27
chromatic It's merely an event loop.
Launch N programs.
dukeleto a parallel tapir could be quite fast
chromatic Loop around select a few times.
Detect the ending of one program and launch another.
dukeleto chromatic: that sounds reasonable
moritz event loops - everybody should have written one! 08:28
dukeleto chromatic: is there an exception raised when a program ends?
chromatic Event loops are like DSLs in Ruby. You already have for(). You get to choose the symbol names.
I don't know much about IO in Parrot; I can't answer that.
dukeleto moritz: i did some perl/tk and perl/gtk coding back in the day. those are my memories about event loops. and a bit of POE
chromatic I don't even know if there's waitpid. 08:29
dukeleto chromatic: yes, we have waitpid
moritz dukeleto: that roughly matches my experience
08:29 fperrad joined
dukeleto chromatic: spawnw() opcode returns the status of the waitpid system call 08:30
chromatic: don't know if that is exactly the same
chromatic: parrot does not seem to have a waitpid opcode or anything
chromatic It's two things.
First, figure out when a program has ended. 08:31
Second, reap that program so it doesn't stick around as a zombie.
dukeleto chromatic: do the current t/foo/threads.t tests reap as well?
chromatic waitpid() for threads is join(), so yes. 08:33
dukeleto looks like parrot does not expand ~ in -I, or at least does not correctly on darwin. feature or bug? 08:35
chromatic Unimplemented; not necessarily either. 08:36
You can argue that your shell should or shouldn't.
dukeleto chromatic: or i can ignore the problem. i choose that. 08:37
just ran t/op/inf_nan.t on both harness' (105 tests, 1 file) and tapir is closer to 3x faster 08:38
wait a sec
60% faster, almost a 1/3 of the running time, is what I meant 08:39
this looks like it could be *quite* a speed up across the entire parrot test suite, even without -j 08:40
i am going to finish adding features before any more benchmarking. but it looks promising 08:41
08:43 fperrad_ joined
dalek tracwiki: v20 | jimmy++ | ArrayTasklist 08:50
tracwiki: change RT #56718</a> to TT <a class="new ticket" href="trac.parrot.org/parrot/ticket/1293" title="bug: Array PMC freeze/thaw/visit broken (new)">#1293</a>
purl dalek: that doesn't look right
dalek tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
08:53 JimmyZ joined
JimmyZ moritz: hello, there's a bug for irclog, see irclog.perlgeek.de/parrot/2009-12-01#i_1786528. 08:53
moritz JimmyZ: what's the bug? 08:55
purl the bug is probably www.cbttape.org/funny/bug3.jpg or img227.imageshack.us/img227/2596/featureiu1.jpg
moritz JimmyZ: dalek reported the HTML on the channel, it's not generated by the irc logger
JimmyZ :) 08:59
dukeleto The opcode 'die_p_kic' (die<2>) was not found 09:17
so sad :(
is there an easy way to lower/upper case strings in PIR? 09:25
09:26 pdcawley joined
dalek rrot: r42833 | fperrad++ | trunk (7 files):
[library] rename Configure.pir to Configure/genfile.pir (see TT #1279)
 09:26
moritz dukeleto: upcase $S0 09:27
dukeleto moritz: thanks! i hadn't seen that yet
moritz looked into rakudo's sources to figure it out :-) 09:28
dukeleto moritz: how long does rakudo take to run the spec test suite these days?
moritz dukeleto: 70 minutes on two cores :/ 09:29
dukeleto moritz: i might have something for you ;) 09:30
moritz *blink*
dukeleto moritz: i am working on a pure-PIR test harness, tapir. it is *fast* 09:31
moritz dukeleto: that's good. But it's not primarily the harness that's slow.
dukeleto moritz: but you have to deal with "fudging" in the spec test suite. that might make things complicated. but i could build fudging support into tapir
moritz dukeleto: no need, if you can give it a list of files 09:32
dukeleto moritz: i understand that. but you don't realize how slow Test::Harness is
moritz dukeleto: then the rakudo harness can call fudge, and call to tapir
dukeleto: one more thing... remember the smoke reports 09:33
dukeleto moritz: you mean submitting to smolder?
moritz right
it requires some kind of recording of the test results
dukeleto moritz: parrot needs a TAP::Harness::Archive anyway 09:34
moritz: tapir is mainly geared for parrot first, but could be useful to rakudo down the line 09:35
moritz: parrot and HLL's
moritz the spectest run in master executes 453 files... with a startup time of nearly 1s that's more than 7 minutes startup time 09:36
dukeleto moritz: it takes 5x longer to load Test::Harness than to load Tapir 09:37
but Test::Harness only gets loaded once per test run
it is mostly the overhead of internal Test::Harness data structures that makes it slow 09:38
it is very customizable and maintainable code, but some speed was sacrificed 09:39
09:40 gaz_ joined
chromatic Fixing freeze/thaw should speed up Rakudo's starting substantially though. 09:47
moritz aye 09:48
10:04 bacek joined 10:19 riffraff joined
mikehh All tests PASS (pre/post-config, smoke (#30310), fulltest) at r42833 - Ubuntu 9.10 i386 (gcc with --optimize) 10:21
t/pmc/complex.t - TODO passed: 467 - in smoke and all cores
10:22 JimmyZ_ joined
mikehh want to check that on amd64 befor I remove that TODO 10:22
bacek o hai 10:24
dukeleto o bai
10:25 riffraff joined
bacek mikehh, can you nopaste "prove -v t/pmc/complex.t"? 10:25
dukeleto invokes sleep
bacek I didn't expect any passed tests
dukeleto, good night
bacek cast "Sleep" to dukeleto 10:26
nopaste "mikehh" at 81.149.189.7 pasted "result of prove -v t/pmc/complex.t on Ubuntu 9.10 i386 (same with both g++/gcc with optimize)" (478 lines) at nopaste.snit.ch/18907 10:42
mikehh got to go out for a bit - bbl
10:57 bacek_ joined
bacek_ msg mikehh test 467 isn't passed. It's actually todoed. Check TT#1318 for explanations 10:58
purl Message for mikehh stored.
12:00 jsut joined 12:11 ruoso joined 12:14 bluescreen joined 12:25 bluescreen joined 12:28 bluescreen joined
dalek rrot: r42834 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] some refactors
 12:54
13:00 patspam joined 13:04 plobsing joined
dalek TT #1294 closed by doughera++: Build failure on OpenBSD 4.6 -- missing dependency? 13:18
13:28 nopaste joined
he Woohoo, have a patch for TT #1340 which makes "make smoke" pass again on my test host. 13:32
13:32 TonyC joined
Coke I am surprised at the number of non-developers on the list who have responded to my google wave invite request. 13:32
Coke hands out invites instead of interrogating them on their contributions. 13:33
... or not. 13:34
13:34 iblechbot joined
Coke the only post I can find from this guy is "un-subscribe" to the main list in '06. 13:34
moritz seems the un-subscribe was not successfull :-) 13:36
mikehh All tests PASS (pre/post-config, smoke (#30315), fulltest) at r42834 - Ubuntu 9.10 i386 (g++ with --optimize) 13:41
fperrad seen barney 13:43
purl barney was last seen on #parrot 13 days, 5 hours, 27 minutes and 2 seconds ago, saying: Austin: glad to help [Nov 18 08:14:52 2009]
13:45 payload joined
he BTW, patch has been attached to TT #1340 13:49
Coke grumbles; the gui ssh-agent for os x doesn't seem to work if you're not on console. 13:58
moritz Coke: the ssh agent works with environment variables 13:59
Coke: so the root process of all GUI applications has to start the ssh agent, and propagate the env variables to all child processes
so it might be a question of starting it with right hook 14:00
Coke moritz: ah. this is an old screen session that I was still remoted into. moment.
nope. 14:01
pmichaud good morning, #parrot 14:21
mikehh hollo 14:22
14:23 iblechbot joined 14:28 nopaste joined
pmichaud 19:28 <cotto_work> pmichaud, what's your estimate on how much Parrot's lack of a proper lvalue model slows down the code that nqp generates? 14:34
cotto: my estimate is that it's less than 2%.
cotto: the lack of an lvalue model makes for some really ugly code generation and lots of unnecessary operations, but in the profiling I've done it's never shown itself to be a significant source of slowdown 14:36
moritz so what *is* slow, apart from GC? 14:37
pmichaud PCC
moritz :( 14:38
dalek 9plus: 85fe1b6 | bernhard++ | Configure.pir:
Use Configure/genfile.pbc instead of Configure.pbc.
 14:39
14:40 patspam joined
dalek lambda: 4e0b954 | bernhard++ | Configure.pir:
Use Configure/genfile.pbc instead of Configure.pbc.
 14:43
Coke and hopefully lorito will ease some of the PCC work. 14:47
(I think)
dalek l: 3bf0eb4 | fperrad++ | (2 files):
add manifest_includes
rrot-linear-algebra: fff3a2e | (Markus Mayr)++ | src/pmc/numvector.pmc:
Add a vector PMC, mostly untested.
 14:48
Coke wonders if he can use ARE as an example to implement globbing. 14:50
Coke looks at the ARE code, and says "nope." =-) 14:51
pmichaud oh, I bet I can write a globber fairly quickly 14:53
particle isn't there a glob front end for pge?
dalek rtcl-nqp: 1dbaf7a | (Will Coleda)++ | src/PmTcl/commands/string.pm:
make [string compare]'s current special case explicit.
pmichaud yes, but we're not using pge any more.
dalek rtcl-nqp: c76b570 | (Will Coleda)++ | src/PmTcl/commands/main.pm:
Add [exit]
rtcl-nqp: 80a48c7 | (Will Coleda)++ | TODO:
Add to the pile.
rtcl-nqp: d37dec1 | (Will Coleda)++ | src/PmTcl/commands/string.pm:
implement [string last]
particle i know, but i'm sure it has a test suite 14:54
Coke pmichaud: as I'm going through [string] now, that'll help with [string match], anyway.
Coke encourages particle to implement something on partcl-nqp! 14:55
(It's almost all NQP)
dalek rkdown: e46bda4 | fperrad++ | (2 files):
add metadata
 14:56
Coke pmichaud: I was thinking that the old helper getIndex() should probably be rewritten as a method on both tcllist and tclstring.
pmichaud Coke: makes sense to me 14:57
Coke (right now you have to pass in the object you wish to index, so making it a method seems to make more sense.)
pmichaud okay, I have a serious "wtf?" moment.
Coke about tcl? =-)
pmichaud about Parrot
Coke oh, that I can't help with. =-)
pmichaud let me put together the full example.
will take a bit 14:58
did someone say that nopaste.snit.ch is down? 15:01
oh, it's up
(ISP fail here today)
nopaste "pmichaud" at 66.25.4.52 pasted "parrot/nqp huh?!?" (29 lines) at nopaste.snit.ch/18908 15:02
Coke I presume the wtf is that running the nqp takes twice as along as the compilation to PIR /plus/ running the PIR? 15:03
pmichaud right.
the whole is 2x greater than the sum of its its parts 15:04
Coke I can only assume the whole is loading some other part.
pmichaud I can't imagine what it would be.... unless compreg "PIR" is somehow that much slower.
Coke oh, it's slow. =-)
I don't know that it is /much/ slower, but it ain't fast. 15:05
pmichaud I can imagine "slow." I can't imagine "that slow"
Coke well, that's easy to test, anyway.
pmichaud it's not like the resulting .pir is that big
right, testing now.
omg 15:06
Coke as good a hypothesis as anything (and would explain why partcl was such a dog.)
pmichaud I wonder if the internal PIR compiler is slow on utf8-encoded strings.
moritz Coke: you speak if partcl in the past tense... have you abandoned it in favour of the nqp based thing? 15:07
Coke pmichaud: hurm. my previous incarnation of index parsing included a rule in the grammar to parse a few different cases. I should probably continue to use that.
moritz: presuming the nqp-based version can be brought up to where the old pir-based version was, yes.
so, jump on in!
pmichaud Coke: that works, although nqp should be getting native regexes rsn 15:08
i.e. -- ability to match against a regex that is in the source and not in the grammar
Coke pmichaud: oooh
ok, I'll hold off. plenty of other stuff to do. =-)
pmichaud I'll bump that up a notch, then.
I finally figured out how to deal with parrot not being able to distinguish regex subs from normal subs 15:09
Coke how?
pmichaud the regex library will have a class of objects that will wrap regex subs
since regex subs aren't invoked directly but always through an api, I can do the unwrapping then.
Coke we might need something similar for tcl procs, as we have to store metadata about them that parrot doesn't allow for. 15:10
pmichaud (at the nqp-level, at least.)
Coke (in partcl, I just subclassed .Sub for that.)
pmichaud Coke: how about properties?
Coke pmichaud: that works. I did the subclass so I could use attributes.
but as long as I can cram arbitrary properties on something, sure. 15:11
pmichaud Coke: ...and then how did you rebless the compiled subs into your subclass?
Coke pmichaud: moment.
github.com/partcl/partcl/blob/maste...c.pir#L217 15:12
the first line highlighted is invoking the pir compreg.
(all this metadata is needed for [info]) 15:13
pmichaud ah, you did an assign.
I like that approach... it might work out much better than what I was thinking.
Coke Good luck. =-)
not to keep changing topics, but any idea what's causing that lexical error message on t/cmd_for.t? 15:21
(it is happening after the 'command_line' invocation in :main) 15:22
(I'm assuming it's a leftover EH that was never popped) 15:23
15:30 bubaflub joined 15:32 lucian joined 15:33 Andy joined
dalek rtcl-nqp: 606f07c | (Will Coleda)++ | src/PmTcl.pir:
Document workaround due to parrot bug.
 15:34
rtcl-nqp: 304f7be | (Will Coleda)++ | (3 files):
Add [namespace] stub.
 15:39
pmichaud I'll look at cmd_for.t in a bit 15:42
Coke pmichaud++ 15:48
pmichaud I want to find that execution cost
dalek p-rx: 2665b51 | duff++ | src/NQP/Actions.pm:
[nqp] simplify statement modifier logic slightly
 15:49
rtcl-nqp: 4f7222d | (Will Coleda)++ | src/PmTcl/commands/namespace.pm:
Replace harcoded bad command name with actual bad command.
 15:51
rtcl-nqp: 30b236f | (Will Coleda)++ | (3 files):
add stub for [info]
15:55 Psyche^ joined
Coke pmichaud: any reason why the lex pad initialization in PmTcl.pir couldn't be moved into a .pm file's INIT block? 16:01
nopaste "pmichaud" at 66.25.4.52 pasted "updated timings for fib.nqp benchmark, with and without -G" (40 lines) at nopaste.snit.ch/18909 16:02
Coke (I'm trying to add some nqp-level initialization (setting some %GLOBALS), and it doesn't seem to be working.
nopaste "coke" at 72.228.52.192 pasted "this is invoked, but [puts $tcl_version] outputs empty string." (6 lines) at nopaste.snit.ch/18910 16:03
pmichaud Coke: --that's because %GLOBALS is later overwritten by 'main' 16:04
Coke figured. so i could put the global/main lexpad setup into that INIT block?
pmichaud you could initialize %GLBOALS in the same INIT block, yes.
Coke k. let me see if I can figure out that syntax. 16:05
dalek lambda: 95026a8 | bernhard++ | (7 files):
Use setup.pir instead of Configure.pir.
 16:07
lambda: 0724443 | bernhard++ | (2 files):
Parrot::Config wasn't used, so don't load it.
16:08 payload joined
Coke pmichaud: does NQP understand "new" ? 16:08
oh. whoops.
pmichaud it's newpad in this case :-)
Coke i was doing "new Foo", not "Foo.new" 16:09
(and then taking on the newpad, yes.)
pmichaud in this case I think it's TclLexPad.newpad
Coke not TclLexPad.new.newpad ? ok.
pmichaud right
note that the original has no "new"
Coke "null pmc access in find_method "newpad".. bah, probably hasn't created the lexpad yet. 16:10
nopaste "coke" at 72.228.52.192 pasted "ok, what's wrong with this naive version? =-)" (9 lines) at nopaste.snit.ch/18911 16:13
Coke I removed it from the INIT block so that the TclLexPad was created first. 16:14
but I'm not sure that's a faithful translation.
... (after doing a realclean, I'm not getting the error with INIT anymore. odd.) 16:20
nopaste "coke" at 72.228.52.192 pasted "this looks slightly better to me, but "set a 3" still dies with Null PMC access in get_pmc_keyed()" (12 lines) at nopaste.snit.ch/18912 16:21
Coke looking at the generated code, the line where I assign %GLOBALS doesn't seem to do what I think it should. 16:24
ok. even if I move that lexpad setup into a Q:PIR block in init.pm, I still get the null pmc error later using set. 16:31
... I think because of the lexicals. if I move that lexical definition elsewhere, it's not available to the commandline() invocation, is it? 16:33
guess I need to put this in as an explicit init() call after the lexical but before the commandline. 16:34
yay, fixed. 16:40
16:40 ascent joined
pmichaud correct -- if we move the lexical definition elsewhere, then called functions can't see it in their global scope 16:45
it can be done from the init block if you wish -- I'lll refactor it if so
Coke I figured the less PIR the better.
*figure
pmichaud I agree.
Coke so if you want to clean that up, by all means.
(pushed) 16:46
is there a way in NQP to refer to a namespace outside of your HLL? 16:47
pmichaud not outside of pir:: or Q:PIR yet 16:48
Coke (i'm using module _tcl { ... } in a few places but that's inside the tcl hll, which is one level too low.
pmichaud I need a syntax for it
dalek rtcl-nqp: 31d4a5d | (Will Coleda)++ | (4 files):
Add an NQP-based init section, set some globals used by [info]
Coke I was going to vote for having ::parrot magically refer to the top level parrot NS.
pmichaud it may end up being Foo::Bar:from<perl6>
so then the top level parrot NS would end up being GLOBAL:from<parrot> or something like that 16:49
just trying to remain p6-compatible, mainly
Coke ayup
as long as there's a way to do it. 16:50
dalek lscript: 705eba0 | fperrad++ | t/pmc/ (10 files):
chmod +x *.t
lscript: 4143db8 | fperrad++ | (2 files):
add manifest_includes & manifest_excludes
Coke pmichaud: is there a way to use pasm constants in NQP? 16:54
(ala config = interp[.IGLOBALS_CONFIG_HASH] 16:55
pmichaud Coke: not at present. Is there a way to look them up at runtime in PIR?
Coke I just do an .include of the file that defines them.
I can't iterate over them, no.
pmichaud right.... but NQP isn't so lucky there.
sounds like NQP might need a module or something for parsing the .pasm files 16:57
or for embedding .include into the source and then emitting the constant 16:58
probably means that PAST::Val needs a way of registering constants, though.
pmichaud starts writing his parrot-dev post about gc effects on runtime 16:59
Coke 3/17 17:00
purl 0.176470588235294
dalek rrot: r42835 | pmichaud++ | trunk/compilers/pct/src/PCT/HLLCompiler.pir:
[pct]: Add a simple --stagestats option to PCT::HLLCompiler.
 17:01
17:11 theory joined 17:19 theory_ joined
dalek a: 6ad653d | fperrad++ | (2 files):
add manifest_includes & manifest_excludes
 17:20
rrot: r42836 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distuils] add _clean_smoke
 17:34
17:36 nopaste joined
dalek zy-k: 233331d | bernhard++ | (9 files):
Use setup.pir for Lazy K with an installed parrot.
 17:43
17:48 brrant joined 17:55 mtk1 joined, mtk1 left, chromatic joined
Coke chromatic: hio 17:55
chromatic morning 17:58
cotto_work ni
hi 17:59
18:03 nopaste joined
cotto_work #ps in 26 18:04
18:07 barney joined
pmichaud cotto_work: looks like the cost of the extra fetch opcodes might be closer to 4% 18:16
I'm not sure how much of that can actually be achieved though. And find_lex is probably a lot more expensive than it needs to be. 18:17
cotto_work That's still pretty lightweight. I'm working on the profile of a long-running nqp process. It'll be interesting to see how that looks. 18:19
dalek rrot: r42837 | coke++ | trunk/src/ops/var.ops:
grammar updates
 18:20
Coke looks like the docs for find_lex lie; it's not basing the decision to throw an exception on the pmc. 18:21
(or rather, that's not the only time an error is thrown) 18:22
pmichaud cotto_work: it appears our big problem is gc (see my latest to parrot-dev) 18:23
cotto_work yup. I'm verifying atm. 18:24
pmichaud I was completely shocked by that result. I only stumbled across it while researching the answer to your "how much does it cost..." question :) 18:25
cotto_work That's a good reinforcement of chromatic's results.
pmichaud indeed, but I'm completely stunned that such a small source program could have that much impact. 18:26
moritz I don't understand the difference... is keeping around those objects from these trees so expensive, because every GC run has to consider them? 18:27
pmichaud moritz: yes, it appears so.
there's also the cost of the objects created by loading nqp.pbc, past.pbc, etc. 18:28
but I suspect the source tree will ultimately be the overriding factor
18:33 nopaste joined
Coke chromatic: how short lived? short enough that we can delete them ourselves? 18:34
(re: email)
pmichaud #ps in -6 ? 18:37
er, -7 ?
chromatic That depends on how complex our control flow is.
pmichaud how does one force a gc run ? 18:40
18:40 brrant joined
pmichaud (in PIR) 18:41
particle sweep 1; collect 1;
18:41 mikehh joined
pmichaud collect doesn't take an argument -- I'm guessing it's just "collect" 18:42
particle ah, yes. 18:43
'sweep' 1 runs mark and sweep, 'collect' compacts. 18:44
Coke thanks dukeleto for the obligatory "oh, and other HLLs!" mention. :P 18:46
dukeleto: pivotallabs.com/users/colin/blog/ar...s-x-10-5-6 18:51
wonder if that helps. :|
moderator Parrot 1.8.0 Zygodactyly released | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang 18:52
dukeleto Coke: i will take a look, thanks! 18:52
pmichaud nopaste.snit.ch/18913 # I don't think sweep 1/collect is doing a GC run... 18:53
chromatic collect doesn't, for some reason. 18:55
The 'run_gc' method on the Interpreter PMC does, though. 18:56
pmichaud so, $P0 = getinterp; $P0.'run_gc'() ? 18:58
pmichaud tries that
chromatic That's the one.
pmichaud still bizarre (nopaste soming) 18:59
particle how confusing.
pmichaud *coming
nopaste.snit.ch/18914 # still not sure a gc run is happening here 19:01
chromatic What would you expect to see if it were? 19:02
pmichaud a much larger amount of time
19:02 mikehh joined
pmichaud according to the times there, the gc run at the beginning accounts for only 0.014 sec 19:03
and that should be our most expensive gc run if we're cleaning up all of the PCC headers from copmilation
but if a gc run only requires 0.014 sec
chromatic Hm, it doesn't look like it calls finalize in the GC.
pmichaud then that means the 10-second difference we're seeing would be the result of (10/0.014) gc runs 19:04
Coke (I wonder if the problem is in interpreter exit)
pmichaud Coke: no, because the final time is output before interpreter exit
chromatic pmichaud, add to src/pmc/interpreter.pmc Parrot_gc_finalize(interp) on line 798.
Coke pmichaud: and does that match up with ./time ?
chromatic also, there's a question in #ps for you.
Coke er, "time ./parr..." 19:05
pmichaud Coke: it does
Coke k
19:05 iblechbot joined
pmichaud chromatic: no difference (nopaste coming) 19:07
19:08 ruoso joined
pmichaud nopaste.snit.ch/18915 # still still not sure a gc run is happening here 19:08
19:09 ingy joined
particle pmichaud: use printf! 19:10
chromatic I can't imagine any reason why it wouldn't, unless my typo is that interp should be PMC_interp(SELF) (which won't make a difference unless you're using kid interps).
pmichaud anyway, assuming that a gc run is taking place there, the upper-bound cost of a gc run would seem to be 0.014 seconds. (It's actually much less because we have the PCCMETHOD overhead in this version )
which means that the fibonacci code itself is requiring 700+ GC runs... plausible. 19:11
19:11 nopaste joined
pmichaud the point I'm trying to get to is to refute chromatic's last message that it's the PCC objects causing the slowdown, though. 19:11
PerlJam pmichaud: Have you tried plotting the time as a function of $N ? That might tell you something interesting. 19:12
chromatic If you want to refute my supposition, profile and see how many PMCs and STRINGs get created and where. 19:13
pmichaud the gc run at the beginning should be clearing out any PCC objects left over from the compilation process, leaving only the long-lived data structures
so the only remaining pcc objects would be those generated by running the code itself, which ought to be the same in both the .pir and .nqp versions
however, we still see that execution of the .nqp version requires ~20 seconds, while execution of the .pir takes <10 sec 19:14
chromatic We need to profile both versions then.
pmichaud I'm still very non-expert with the profiler at the moment, though. 19:15
chromatic Callgrind-wise, I mean.
pmichaud I'm a non-expert with that, too. :0| 19:16
anyway, I'll post these latest items to the mailing list and people can build from them. 19:17
chromatic Sure, I can profile them.
dukeleto that felt like a productive meeting 19:25
19:27 bacek joined
Util dukeleto: I would be interested in any success you have with kcachegrind on OS X 10.5 19:28
pmichaud oh, crap.
19:28 davidfetter joined
pmichaud Houston, I think we have a serious problem. 19:29
chromatic Houston *is* a serious problem.
pmichaud That also. 19:30
Let's assume we're calling a sub. The sub does its thing, and exits. When does the context for that sub's execution get freed? 19:31
chromatic When it's unreachable.
pmichaud when does it become unreachable? the sub still has a reference to it.
chromatic The Sub PMC or something else? 19:32
pmichaud the Sub PMC, iirc
chromatic That doesn't sound right.
pmichaud it would become unreachable the next time the Sub is invoked (when the sub gets a new context attached to it) 19:33
chromatic That *really* doesn't sound right. Recursion works.
pmichaud oh sure, that's no problem
it doesn't affect recursion
chromatic If it doesn't affect recursion, where's the problem?
pmichaud the problem is that every sub keeps its last context alive 19:34
via its *ctx attribute
and since that last context is alive, all of that context's callers are alive
and all of the outers are alive
(via their respective pointers as well)
chromatic If that chain gets marked. 19:35
<cue lingering horror>
pmichaud surely the sub gets marked, yes?
chromatic and the sub marks its context.
pmichaud Parrot_gc_mark_PMC_alive(interp, sub->ctx);
so, this would mean that all of the methods and subs that got called during compilation are holding pointers to their contexts 19:36
chromatic Looks that way.
pmichaud still, I'm not sure this completely accounts for it, unless some of those objects are Capture PMCs (referring to your earlier analysis of a couple of weeks ago)
dalek tracwiki: v116 | barney++ | Languages 19:37
tracwiki: Lazy K works on Parrot 1.8.0
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
chromatic It's not that the Capture PMC is particularly expensive to mark.
Merely that for that particular GC profile, it happened that kcachegrind's cycle detection picked a cycle starting with Capture's mark.
pmichaud okay.
chromatic If it happens to be a parent of a Continuation somewhere, it'll look expensive, inclusive-wise. 19:38
A different workload would fill up a GCable pool at a different point.
pmichaud anyway, our notion of "long-lived PMC" has to include these context PMCs that hang around after a sub has been invoked
(and all of the objects they reference)
s/has been invoked/has exited/ # more precise 19:39
chromatic We can't have Sub PMCs pointing to contexts, in other words.
pmichaud we have to, though, for lexicals.
what I think we need is a way for a Sub to release its ->ctx when its return continuation is invoked 19:40
or when it's otherwise marked as "exiting"
(which gets back to my earlier comments about needing improvement to Sub exit semantics) 19:41
chromatic When invoking a RetCont, for example.
pmichaud so yes, I'll agree that PCC structures are adding to the load, at least to the extent that they've become long-lived structures 19:44
(if a sub is invoked 1000 times, though, its only its last set of pcc structures that get preserved, so it's not the 1000 structures that are the load, unless something else is holding pointers to them) 19:45
chromatic Right.
pmichaud and the new nqp doesn't use coroutines, so there shouldn't be a lot of those lying about 19:46
chromatic I'm testing invalidation in RetCont.
pmichaud make sure that sub->ctx is cleared only if the RetCont is the current sub->ctx 19:47
(because of recursion and lexical capture)
chromatic Already caught that case. 19:48
pmichaud chromatic++
I need lunch here... I'll see about summarizing further later.
it's becoming a complex analysis :-( 19:49
19:52 xenoterracide joined
chromatic The expensive calls from Sub's mark() seem to be namespace_name and outer_sub. 19:52
19:57 zostay joined
bubaflub does parrot have a similar flag like -d on perl 20:02
i.e. parrot -d blah-blah.pir
to run it line by line
dukeleto bubaflub: -v tells you extra stuff 20:03
bubaflub: not quite what you want
bubaflub: you can use the parrot_debugger 20:04
bubaflub: beware, breakpoints probably don't work
bubaflub yikes
yeah
it exploded
hmmm
dukeleto bubaflub: use the "t" debugger command to trace one line 20:05
trace = execute and print source
bubaflub: nopaste?
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
bubaflub ah, yeah
let me poke at it a bit longer
20:06 cotto_work left
dukeleto bubaflub: have fun. the debugger can be helpful, but she is a harsh mistress 20:06
20:07 cotto_work joined 20:20 pdcawley joined
bacek Good morning 20:27
cotto_work hi bacek 20:29
bacek cotto_work, hio! 20:30
20:32 tewk joined 20:34 joeri joined
dukeleto pours bacek a scotch 20:36
ENOBACEKINPARROTSKETCH 20:37
cotto_work clock?
purl cotto_work: LAX: Tue 12:37pm PST / CHI: Tue 2:37pm CST / NYC: Tue 3:37pm EST / LON: Tue 8:37pm GMT / BER: Tue 9:37pm CET / IND: Wed 2:07am IST / TOK: Wed 5:37am JST / SYD: Wed 7:37am EST /
cotto_work He's a slacker like that, refusing to get up at 0530 for #ps.
bacek dukeleto, it's too early for scotch and parrotsketch :) 20:38
dukeleto bacek: what is the name of the branch with your callsig/context merge?
bacek: and is it feasible to get merged in before 1.9.0 ?
bacek dukeleto, context_unify 20:39
dukeleto, no, it's not ready. And I don't have much time for it...
dukeleto, and I choose wrong approach in this branch... 20:40
cotto_work now you know a way not to do it 20:41
chromatic What's the right approach?
purl the right approach is to utilize the GPU for things it's good at.
20:41 mikehh joined, bluescreen joined
bacek 1. build_sigobject should create new CallContext 20:42
2. Sub.invoke should get CallContext from CURRENT_CONTEXT
3. ... allocate registers in it
4. Set it as CURRENT_CONTEXT
It's about few days work. 20:43
(And I think it's better to start from scratch) 20:44
chromatic Did you create any new PMCs?
dukeleto bacek: i am all for you rm'ing context_unify and doing it right. we would really appreciate getting it in before 1.9.0 . are there any tests that I can help write?
bacek chromatic, I just merged Context and CallSignature 20:45
20:45 bubaflub left
Coke purl, forget the right approach 20:45
purl Coke: I forgot right approach
bacek dukeleto, there is enough tests afaiu
chromatic Is that CallContext? 20:46
bacek chromatic, yes
dukeleto i am interested to see how CallContext affects gc performance
bacek dukeleto, it will create 25% less PMCs 20:47
in other words - not much. Without generational GC we are doomed.
(about GC) irclog.perlgeek.de/parrot/2009-09-09#i_1486986 20:48
dalek rrot: r42838 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] modify the semantic of manifest_includes & manifest_excludes
 20:51
20:51 mikehh joined
dukeleto how long will it take to write a small POC optional generational GC ? 20:51
Tene dukeleto: whiteknight would be able to give you the best estimate there. 20:52
bacek dukeleto, I will say 2 weeks full time job. 20:53
Or we can try to borrow GC from other project. Like Apache Harmony
Coke (borrow+++++++++++++++++++++++++++++++++++++++++++++++++++)
20:53 darbelo joined
chromatic I don't think borrowing will be any faster. 20:53
Coke to implement or at runtime?
bacek chromatic, It will not. But it will help with proper encapsulation of GC in Parrot. 20:54
Coke and if the time comes from a tradeoff between making the API fit vs. implementing GC code, I say the time is better spent on the API matchup.
but, IANABCP 20:55
er, GCP!
dalek a: 88ca3b8 | fperrad++ | setup.pir:
compatible with r42838
tewk GC tend to be closely coupled to VM implementation details, for performance reasons. 20:56
borrowing raw code is hard, borrowing implementation tatics and ideas works very well. 20:57
dalek lscript: 460eba8 | fperrad++ | setup.pir:
compatible with r42838
chromatic I annotated the GC to see what gets destroyed when.
20:57 mikehh joined
dukeleto tewk++ # let's borrow tactics and API designs 20:57
chromatic Grr, Parrot dev bounces. 21:12
Coke ? 21:15
ah, there it is. moment. 21:16
Message body is too big: 45064 bytes with a limit of 40 KB
purl Message for body stored.
body messages 21:17
;)
Coke doubles the size limit for the list. 21:18
bacek sending "Enlarge your size" mail to Coke
21:19 mikehh joined
Coke gets a "cool beans" overview from someone on #tcl 21:19
most positive conversation I've had in there in six year.s =-) 21:20
Coke trolls for more contributors to partcl-nqp! 21:21
21:24 mikehh joined 21:26 nopaste joined
bacek ok, almost $dayjob time 21:29
chromatic, I'll merge CS and CSR tonight. It's couple of hours job.
chromatic Excellent, thank you. 21:30
21:33 brrant joined 21:38 nopaste joined 21:51 TonyC joined 21:58 nopaste joined 22:09 redbrain joined 22:19 lucian joined
cotto_work looks like there's an unexpectedly passing test in t/pmc/complex.t 22:40
dukeleto cotto_work: it is platform-specific, i think 22:45
cotto_work that's a distinct possibility 22:46
dalek rrot: r42839 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] partial revert of r42838. Restore the previous semantic.
 22:47
dukeleto cotto_work: there may be a TT for it 22:49
dalek lscript: 0795343 | fperrad++ | setup.pir:
restore previous semantic
 22:54
a: 31e3d8b | fperrad++ | setup.pir:
restore previous semantic
22:58 nopaste joined
dalek rrot: r42840 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[languages] fix shebang
 23:04
23:05 TonyC joined
cotto_work tries to figure out how chromatic got those results 23:15
chromatic cg ./parrot ext/nqp-rx/nqp-rx.pbc fib4.nqp 23:16
cg ./parrot fib4.pir
japhb His keyboard has a 'results' key, clearly 23:17
chromatic alias cg='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes'
cotto_work your alias for cg is just valgrind --tool=callgrind with some callgrind-specific options, right?
chromatic It also has time traveling, to answer questions before you ask.
cotto_work nice feature 23:18
purl nice feature is that you can get a SunPCI card to run Windows natively within the workstation itself. So it's virtually a Sun WS and a nice gaming PC
cotto_work For me nqp fib takes about 12.5x longer and 4.7x more instructions than the pir version on examples/benchmark/fib.pir, using n=26. It's puzzling that the results would be so different. 23:22
s/ on / in / 23:25
pmichaud chromatic: in your message, why fib(26) instead of fib(28) ?
also, why does only one timestamp appear before the output, instead of two? 23:26
chromatic To make callgrind faster, for the first question.
I removed the GC run for the second.
pmichaud okay.
I can try with $N=26 on my system, for comparison.
just a sec.
23:27 TonyC joined
pmichaud nopaste.snit.ch/18916 # fib.nqp benchmark for $N := 26, with times 23:29
chromatic 64-bit or 32? 23:30
pmichaud 64 bit
but I think I may be running unoptimized parrot
japhb pmichaud, you're using the fakecutable, and chromatic is using the PBC ... could that have any effect? 23:31
pmichaud japhb: it didn't have any measurable difference when I tried earlier
japhb pmichaud, OK, fair enough
cotto_work I'm running optimized.
pmichaud $ time ./parrot runtime/parrot/library/nqp-rx.pbc fib-5.nqp
1259710297.79801
fib(26) = 121393
1259710305.70347
real\t0m8.178s
.pbc doesn't seem to make a difference. 23:32
japhb I'd love to see how yours changes with an optimized parrot (though I'm surprised you aren't -- I thought you changed the --gen-parrot default to --optimize some weeks ago)
pmichaud japhb: I thought I did so also... but I can't find it now
japhb For rakudo only maybe?
pmichaud it's possible
and apparently only for rakudo master, as it's not that way in ng
oh, it's --optimize in ng 23:33
...and in nqp-rx, so apparently that's not it. 23:34
any way to check parrot_config for an optimized build?
japhb look for the reconfig var
pmichaud configure_args => '"--prefix=/home/pmichaud/nqp-rx/parrot_install" "--optimize"'
japhb yep, that's the one 23:35
pmichaud looks like "optimized" then.
japhb chromatic, you're running optimized too?
pmichaud so, 64-bit linux, running with Parrot --optimize
chromatic yes.
23:36 nopaste joined
chromatic The next question is what's different between the code run directly from NQP versus the PIR code saved to a file. 23:36
pmichaud they are almost certainly the same. 23:37
chromatic I can't believe there are any differences, but something's very different in these execution models.
pmichaud all that --target=pir does is interrupt the normal compilation sequence and output the PIR
if --target=pir isn't present, then the next stage (evalpmc) invokes imcc on the PIR source to get an Eval object
that is then returned from the 'compile' method, and then invoked (along with any arguments from the command line) 23:38
however... you might try this 23:39
in the .pir file, add the line
load_bytecode 'nqp-rx.pbc'
right at the top of main
then run it
chromatic There's no main; how about the first line of the file?
I mean, the first line of the first sub.
pmichaud first sub, yes
nopaste coming. 23:41
chromatic $ time ./parrot ext/nqp-rx/nqp-rx.pbc fib4.nqp
real 0m1.028s
$ time ./parrot fib4.pir
real 0m0.927s
nopaste "pmichaud" at 66.25.4.52 pasted "pir version of fib w/o and w/ load_bytecode" (17 lines) at nopaste.snit.ch/18917
pmichaud nopaste.snit.ch/18917 # timing with and without load_bytecode in the .pir file 23:42
fib-nqp-5.pir is the original pir
fib-nqp-5b.pir is the pir with the load_bytecode line added
clearly there's little difference in calling sequence as a result 23:43
japhb I'm really confused. How can loading the NQP-rx bytecode using the load_bytecode op take 10x as long as not only loading it but using it to do a compile? 23:46
pmichaud 10x? 23:47
purl somebody said 10x was see thx
japhb Didn't you show that --target=pir (which uses the NQP-rx bytecode to do the compile) was like .2 seconds, and yet the difference between the raw fib.pir and adding load_bytecode nqp-rx.pbc is 2.1 s? 23:49
pmichaud running nqp to do the compile+run took 8sec
23:49 TonyC joined
pmichaud oh, just compiling the source to pir takes .25 sec, yes. 23:49
all of the cost is in the code execution
japhb So somehow using NQP-rx to do a compile takes 1/10 of the time of loading it with load_bytecode.
pmichaud no 23:50
chromatic The PIR version continually runs the GC ten times as much.
pmichaud that's not what this is saying
using NQP-rx to copmile the code takes .25 seconds
that's pretty invariant
if we then run the compiled code from within nqp, it takes 8 seconds
if we save the copmiled code to PIR and run it, it takes 3.5 seconds
if we run the generated PIR, but add a load_bytecode 'nqp-rx.pbc' (which does nothing but load nqp-rx and its associated libraries), then the cost of running the generated PIR increases to 5.8 seconds 23:51
japhb Oh, I see ... you're saying not that the load_bytecode is expensive, but its *effect on the following code's performance* 23:52
pmichaud correct.
japhb gotcha. OK, that makes a lot more sense. I thought I was losing my grip there.
pmichaud we know that the load_bytecode isn't the expensive part, because the first timestamp is printed *after* the load_bytecode occurs.
japhb right 23:53
pmichaud it's also the case that although compiling a source file may result in a ton of PCC calls, simply loading NQP.pbc shouldn't result in nearly as many.
japhb I should hope not. 23:54
None, most preferably.
pmichaud well, there are some, because of :load subs in the various libraries
japhb fair enough 23:55
Let me say not "none" but "a very small number"
chromatic Hm, we reclaim 10x as many PMCs during GC in the NQP as we do in the PIR version. 23:56
pmichaud is that for the total execution cost (including compile)? That wouldn't surprise me. 23:57
chromatic I mean each GC run, even when it's clearly in the "executing the generated PIR" stage.
japhb o_O 23:58
pmichaud ...reclaim?
chromatic Recycle?
pmichaud reclaim meaning "collect"? 23:59
chromatic Yes.

Powered by Cro and the Raku® Programming Language.

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

Thank you!