Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | trac accounts are wonky; talk to cotto, coke or whiteknight if you have trouble
Set by moderator on 10 May 2011.
NotFound Funnily enough, the comment about doing it is still here. 00:00
plobsing cotto_work: no, it is pluggable. I had a libjit-based framebuilder which worked as a plugin, but it is likely broken in the most recent round of NCI refactors.
but as far as core goes, yes, it is the only provided mechanism
NotFound Look at die_from_exception, line 118
plobsing the auto::frames config step and the --buildframes config parameter have been nops for nearly 2 years 00:01
whiteknight NotFound: We get past that point 00:02
die_from_exception calls Parrot_x_jump_out, which has no jump buff
then it calls exit()
NotFound What do you mean? That now we fail silently by design? 00:04
cotto_work It's not necessarily a good design. 00:05
NotFound Even abort is better. At least it can provide a backtraceable core. 00:08
00:09 atrodo is now known as atrodo_
NotFound Anyway, all that doesn't apply to the pbc loading issue, I seriously hope no one will attempt to load a pbc before initializing the interpreter. 00:10
00:10 atrodo_ left 00:11 atrodo joined
dalek rrot: 7a315db | Whiteknight++ | src/ (2 files):
set an api jump buffer in Parrot_api_make_interpreter, so we can try to catch exceptions thrown during interp initialization. Segfaults when we try to report the error, but we get some details out
 00:13
rrot: 69ee128 | Whiteknight++ | / (2 files):
if we don't have an interp, print out an error message. If we do, try to print backtrace information (unlikely)
rrot: ae39eec | Whiteknight++ | / (20 files):
Merge branch 'master' of github.com:parrot/parrot
whiteknight plobsing: just pushed something. It's not perfect, but at least you get a message that initialization failed
at least the failures aren't silent now 00:15
ttbot Parrot 69ee1281 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/1329
plobsing whiteknight: you committed the testcase along with the fix 00:16
whiteknight lolfail
plobsing that's usually commendable, but not so much in this case
whiteknight ...no i didn't
... 00:17
dalek rrot: f5c6248 | Whiteknight++ | src/nci/extra_thunks.c:
remove fail
ttbot Parrot ae39eecc i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/1338
whiteknight ...see?
plobsing your mind tricks won't work on me, jedi
atrodo so whiteknight, is the slowness in method calls are because of method lookup?
whiteknight atrodo: far from it. method lookup is pretty quick. It's a vtable call and typically hash lookup 00:18
atrodo: PCC invocation is the biggest portion of it
fill_params is a beast usually, although those benchmarks I posted had no arguments
atrodo whiteknight> oh. I assumed PCC was faster than the lookup
whiteknight well, no explicit arguments 00:19
no PCC is a hog
NotFound whiteknight: backtrace information after a longjmp will not be very useful.
cotto_work whiteknight: have you considered adding a favicon to your site?
atrodo whiteknight> so it's fill_params that's the biggest time sink? 00:20
whiteknight cotto_work: I want to, but I can't find a picture of me giving the middle finger to a snippet of source code that scales down to 16x16
atrodo: I haven't valgrinded that benchmark. I don't know where the waste is
atrodo whiteknight: but that's your suspicion?
whiteknight atrodo: at that scale, with no arguments, I really don't know 00:21
plobsing whiteknight: we have an isolated 'find_method' op. you could lookup the method $x times and see how long that takes.
whiteknight plobsing: yes, that's true. I still don't think find_method vtable is going to be a big portion of that benchmark
I'll give it a spin 00:22
cotto_work whiteknight: the rage guy?
plobsing whiteknight: I'm not suggesting it does. I'm suggesting you prove it doesn't.
atrodo whiteknight: do you have something readily handy that I can valgrind? Will the code on your blog do the trick? 00:23
00:23 Caelum left
whiteknight atrodo: yeah, that's what I'm going to do. Cut out the test cases you don't want to see and grind it 00:23
ttbot Parrot f5c62483 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/1368 00:26
cotto_work whiteknight: you could use inf gc to avoid seeing its cost
whiteknight gist.github.com/965672 00:27
find_method takes up about 11% of that benchmark 00:29
atrodo: so find_method can be improved, but it's not the worst offender
cotto_work dukeleto: ping 00:30
whiteknight I'm going to run it again with a non-method sub call
3.171735s
so that's cheaper still. about 25% less than a method call with dynamic method lookup 00:31
atrodo aloha, winxed?
aloha atrodo: winxed is code.google.com/p/winxed/ or winxed.org/
whiteknight atrodo: plumage install winxed
atrodo aloha, plumage? 00:32
aloha atrodo: plumage is a package manager for Parrot or github.com/parrot/plumage
atrodo whiteknight: does it pull via svn?
whiteknight atrodo: git
dalek rrot: 0eef3cd | NotFound++ | src/embed/api.c:
fix C90 compliance
whiteknight er, plumage will use svn to get winxed
atrodo whiteknight: yea, that's tricky when svn isn't installed 00:33
NotFound plumage use whatever the package says in its metadata.
whiteknight ah
atrodo is not working on isparrotfastyet like planned 00:40
cotto_work slacker 00:42
cotto_work always works on everything exactly when planned
atrodo i know, seriously
cotto_work to the microsecond
whiteknight I don't think that method calls with static dispatch should cost significantly more than function calls, but they do 00:44
well, not significantly
atrodo how up to date is the PDD on PCC? 00:47
00:48 Coke left
KaeseEs atrodo: the mozilla version measured themselves against chrome and safari, what's isparrotfastyet going to use for the, erm, target? 00:48
00:48 Coke joined
atrodo KaeseEs: That's a downfall, we don't really have anything to compare against except our historical self 00:49
KaeseEs atrodo: i guess the first thing that comes to mind are some other VMs on the alioth shootout (despite its flaws) 00:51
atrodo KaeseEs: I considered that, but it never seemed like a useful test since it's not running the exact same source code like the mozilla version
KaeseEs: I'll probably invest in doing something like that at some point, but i have some refactors to do before that 00:52
whiteknight gist.github.com/965672
KaeseEs ah.
whiteknight atrodo: I don't know where the PCC PDD stands 00:53
atrodo last time i read anything about the internals of PCC it confused me with all of it's numbers in some registers and this order and that. I gave up 00:54
00:55 Coke left, Coke joined
atrodo whiteknight: You left the s at the end of the % different 00:56
whiteknight atrodo: think of it like a nice bonus
atrodo hurray! bonus!
whiteknight: gist.github.com/965709 so right in line with yours 00:57
whiteknight atrodo: your timings are significantly better than mind 00:58
I'm using an unoptimized Parrot
plobsing looks like find_method costs less than the noise in that test 00:59
atrodo whiteknight: heh, that'll teach me not to look at the percentages
whiteknight plobsing: yeah, that's what I figured. It has a cost, but it's not the lions share 01:01
10% about
PIC could help reduce that, but we have bigger fish to fry
plobsing 10%? did you look at atrodo's numbers? 01:02
whiteknight no, I don't look at anybody's numbers but my own
...on my system it's 10%
01:03 Coke left, Coke joined
plobsing in the numbers atrodo posted, dynamic method call was marginally faster than static 01:03
whiteknight damnit atrodo. Your inconvenient data is making me look stupid
plobsing which I would attribute to noise more than anything else
atrodo whiteknight: blame it on it being on a VM 01:04
whiteknight either way, vtable override is horrible 01:05
let's all agree on that
atrodo agreed 01:06
whiteknight I firmly believe that static dispatch methods should not be noticably slower than regular function calls 01:08
and I believe that all invocations should be noticably faster
01:10 Caelum joined
atrodo there's really no reason for dispatch to be that widely varied 01:12
01:13 woosley joined
atrodo needs to figure out callgrind 01:18
whiteknight > callgrind --just-do-it winxed test.winxed
I wish more programs had the --just-do-it option
atrodo ubuntu didn't install "callgrind" 01:19
plobsing atrodo: callgrind is one of the tools available to run from valgrind 01:20
atrodo plobsing: Aye, i got that, finally
plobsing I run it via "alias cg='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes'" 01:21
atrodo plobsing: thanks, that should help me figure out what i want and what i'm seeing 01:23
gist.github.com/965709 dunno what that means yet 01:26
plobsing atrodo: that means your using an unoptimized parrot and your performance is dominated by a sanity-checking register-access function 01:28
atrodo: you may want to run callgrind_annotate with --inclusive=yes 01:30
but only after you run an optimized build. benchmarking debug builds is pretty meaningless
01:38 whiteknight left
plobsing atrodo: I have some ideas related to benchmarking I'd like to run by you 01:46
01:50 rurban_ joined 01:52 rurban left, rurban_ is now known as rurban
dalek tracwiki: v1 | plobsing++ | ParrotDeprecationsFor3.6 02:23
tracwiki: add deprecation notes for TT #1931</a>
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
tracwiki: v32 | plobsing++ | ParrotDeprecations
tracwiki: add deprecation notice for TT #1931</a>
tracwiki: trac.parrot.org/parrot/wiki/ParrotD...ction=diff
atrodo plobsing: sorry, got pulled away. what are you thinking? 02:25
02:27 Andy joined
plobsing a problem with benchmarking is that it is almost always special purpose and only relevant to a single machine 02:30
if we had a mechanism to abstract away the machine, we could setup benchmarks that anyone in the community could run on any machine and have these be comparable to each other 02:31
I was thinking a machine emulator such as bochs would be suitable for such a task
the end result might be that we could have community contributions to something like ipfy, but with much better scope and detail
sorear plobsing: we already have a machine emulator that counts instructions 02:32
chromatic uses it often
plobsing sorear: valgrind is inaccurate when it comes to wallclock time
I'd like something a little closer
dukeleto plobsing: i think a benchmark tests which calibrates itself once on a machine, and then tests relative performance changes against that 02:33
plobsing: I definitely have benchmarking planned for Jitterbug
plobsing sorear: in fact, in the recent 3.0->3.1 regression investigation, I valgrinded a simple benchmark which exhibited the regression wrt wallclock, but valgrind showed the opposite 02:34
arnsholt_ plobsing: One option for making comparable benchmarks would be normalising the scores, no?
atrodo plobsing: Ya, i'd like to see something like that happen sometime
arnsholt_ Assuming the times are normally distributed, run a suitable n number of runs, and normalise to zero mean one variance score
plobsing arnsholt_: no. different machines have different responses to changes. normalization will not fix that 02:35
atrodo dukeleto: I wondered earlier if ipfy and jitterbug could be combined
dukeleto atrodo: possibly. there sure is some overlap
plobsing take the recent 3.0->3.1 regression investigation as an example, bigmem machines saw regression, where average to small memory machines saw equillibrium or improvement
atrodo dukeleto: Too bad I haven't had enough time to work on ipfy, let alone look real closely at jitterbug 02:36
arnsholt_ Good point
plobsing basically the rule is that benchmarks are only comparable over a homogenous set of machines 02:37
atrodo plobsing: gist.github.com/965709 Does that look beter?
plobsing atrodo: yep, that is a more meaningful view you can see that Parrot_callmethodcc_p_sc dominates, but that fill_params only accounts for half of that 02:39
dukeleto atrodo: is the source of ipfy somewhere public? 02:40
atrodo dukeleto: github.com/atrodo/itfy although it doesn't reflect my upcoming refactoring yet
dukeleto atrodo: catalyst? 02:41
atrodo dukeleto: Correct
dukeleto atrodo: cool
02:44 hudnix left
plobsing atrodo: you might also want to look into kcachegrind. many people find it helps them understand the callgrind output better than the text reports. 02:46
atrodo plobsing: I'm seriously considering it 02:47
I think my problem is I want it to look like NYTProf
02:48 mtk left
dalek rrot: 9254cf3 | plobsing++ | api.yaml:
add deprecation notice for TT #1931 not ported over from DEPRECATED.pod
 02:49
rrot: d5f1750 | plobsing++ | api.yaml:
mark TT #1931 deprecation as complete
02:51 preflex left
plobsing atrodo: kcachegrind does provide a source view 02:52
dalek TT #1931 closed by plobsing++: [DEPRECATED] advanced NCI parameter types 02:54
TT #1931: trac.parrot.org/parrot/ticket/1931
02:55 preflex joined, mtk joined 02:57 Andy left 03:10 bubaflub left 03:14 Andy joined
cotto ~~ 03:27
dalek rrot: e3492bf | plobsing++ | config/gen/makefiles/root.in:
NCI/call_toolkit_init.pbc no longer exists
 03:30
03:35 benabik joined
plobsing seen japhb 03:44
aloha Sorry, I haven't seen japhb.
03:44 jjore left 03:45 soh_cah_toa left 04:16 jjore joined 04:40 ShaneC joined 05:15 Andy left 05:23 birdwindupbird joined 06:06 cottoo joined, cotto left 06:07 cottoo is now known as cotto
cotto my kernel oops, let me show you it 06:07
dalek rrot: 6032439 | mikehh++ | MANIFEST:
re-generate MANIFEST
 06:33
mikehh plobsing: still get: gen::makefiles - Generate makefiles and other build files...value for '@cc_build_call_frames@' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Compiler.pm line 572, <$in> line 95. 06:34
06:36 UltraDM joined
bacek ~~ 07:06
msg pmichaud "sin.t" is "regression" in rakudo. 2011.04 is doing much more work. E.g. Parrot_binding_bind_llsig 324_431 vs 253_792 calls on 04 vs 01. 07:09
aloha OK. I'll deliver the message.
bacek msg Same for GCable 17M vs 13M. 07:10
aloha OK. I'll deliver the message.
bacek msg pmichaud Same for GCable 17M vs 13M.
aloha OK. I'll deliver the message.
07:17 preflex left
bacek msg pmichaud s/04/bleed/ 07:19
aloha OK. I'll deliver the message.
07:20 preflex joined
bacek aloha, (191599 - 160450) / 191599 * 100 07:22
aloha bacek: 16.2573917400404
07:24 mj41 joined
dalek rrot: 3b374ae | bacek++ | src/call/args.c:
[pcc] Reduce GC pressure in handling named args.

Instead of creating new RSA with arg names iterate over hash directly. It gives some performance boost. 16.25% in instructions fetch according to valgrind on building rakudo's core.pm.		 07:26
bacek aloha, 151/43*100 07:34
aloha bacek: 351.162790697674
bacek aloha, 151/43*
aloha, 151/43
aloha bacek: 3.51162790697674
bacek 43/151*100
aloha 28.476821192053
bacek msg whiteknight I misread stats. "GC" is accountable for 28% in core.pm. Including allocations. 12% was "collect" part only. 07:35
aloha OK. I'll deliver the message.
07:35 SHODAN left
tadzik bacek: this 16.25% in instructions fetch in instruction fetch, how does it impact overall performance? 07:54
bacek tadzik, less than 16.25% for sure.
Something like 15% I hope 07:55
tadzik well, that's expected
oh nice
bacek But it's on my box. And I can't trust my benchmarks anymore. 08:00
tadzik I can check that
bacek Just because it's quite different from pmichaud++ benchmarks.
tadzik, iwbn
08:07 baest joined 08:11 benabik left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_3_0-199-g3b374ae 08:15
Kubuntu 11.04 amd64 (g++)
tadzik I think I'll need a make clean before rebuilding
bacek: almost no changes in building core.pm 08:21
nopaste "tadzik" at 192.168.1.3 pasted "Latest patch timings for bacek++" (30 lines) at nopaste.snit.ch/44654 08:22
bacek tadzik, hmm. My expectations for 15% were quite high. I've got abut 5% improvements overall on my box
tadzik, are you running on 64 bits? 08:24
tadzik bacek: yes 08:26
bacek tadzik, gms behave quite... interestingly on 64 bits. 08:27
I have no idea why 08:28
dalek rrot/compiletime-git-describe: 51e393d | cotto++ | / (2 files):
add code to generate Parrot version macros as a separate PIR include
 08:34
rrot/compiletime-git-describe: c2143de | cotto++ | / (6 files):
nuke auto::sha1 et al, make config_lib,pir rely on gen_version.pl's generated include
08:39 Khisanth left 08:48 Khisanth joined
dalek rrot/compiletime-git-describe: f0fcd38 | cotto++ | tools/build/gen_version.pl:
force sha1 and git-describe to be recalculated when running gen_version
 08:53
mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_3_0-199-g3b374ae 09:06
Kubuntu 11.04 amd64 (g++ --optimize)
cotto msg dukeleto I'd appreciate your eye on the compiletime-git-describe branch, especially the bits that deal with Parrot::SHA1 et al and cache invalidation 09:11
aloha OK. I'll deliver the message.
cotto msg dukeleto I'm not entirely sure if continuing to cache those values is a good strategy, but I'll leave that to your judgment.
aloha OK. I'll deliver the message.
09:49 rurban_ joined 09:52 rurban left, rurban_ is now known as rurban 09:59 woosley left 10:07 frodwith left 10:08 frodwith joined 10:17 ShaneC left 10:24 ShaneC joined 10:36 mtk left 10:42 mtk joined 11:01 Psyche^ joined 11:07 Patterner left, Psyche^ is now known as Patterner, redicaps joined 11:15 redicaps left 11:21 mikehh left 11:41 woosley joined 11:44 spinclad left 12:03 hudnix joined 12:19 whiteknight joined
whiteknight Good morning, #parrot 12:20
12:36 bluescreen joined 12:37 whiteknight left, whiteknight joined 12:38 whiteknight left, whiteknight joined
Coke_ bacek++ 12:38
13:06 bluescreen left 13:11 bubaflub joined 13:18 benabik joined 13:21 bluescreen joined
benabik ~~ 13:44
bubaflub ~ 13:46
13:47 plobsing left, plobsing joined 14:21 luben_at_work joined 14:27 woosley left 14:35 redicaps joined 14:36 UltraDM left 14:56 luben_at_work left
pmichaud good morning, #parrot 15:19
benabik o/ pmichaud
Coke_ \\o 15:21
plobsing --- -..-. 15:24
benabik plobsing: I couldn't for the life of me remember what -..-. is. That's a rarity. 15:27
tadzik www.wolframalpha.com/input/?i=---+-..-. :) 15:29
plobsing ---... -.--.-
whiteknight nobody calls me an ox!
benabik tadzik: 1) Well, yes, I do have the internets. 2) -..-. /= -..- 15:30
tadzik 1) I suppose so, and 2) I know that
15:31 hercynium joined
whiteknight There's a difference between US and "International" versions of morse code 15:31
tadzik I suppose your IRC clients broke the link as much as mine
whiteknight actually, american morse code and ITU
Coke_ needs to get his bot in here. :P
benabik tadzik: Oh. D'oh.
tadzik --- .... .-.-.- -.. .----. --- .... .-.-.- 15:32
:)
benabik whiteknight: I think US hams use the ITU standard, although I could be wrong.
whiteknight I've never been a ham. I don't know 15:33
I also never learned morse code or ITU 15:34
benabik I never quite learned morse either, at least never well enough for the tests. Thankfully they don't torture people with that anymore.
Radio + sound card = me using morse code. 15:35
dukeleto ~~ 15:38
pmichaud msg bacek good catch on the recent sin.t regression -- regression was in code that handles rational numbers. Now fixed in rakudo ef6e8f4 (14% faster than previous rakudo-bleed). gist.github.com/966698 16:15
aloha OK. I'll deliver the message.
tadzik pmichaud: will it be possible to launch rakbench as a service which will run the tests after every commit and maybe notify the commiter if something interesting happened? 16:21
pmichaud tadzik: not likely.
I think "run after every commit" is misleading.
my experience this past week is that benchmarking releases is far more useful
dukeleto tadzik: i could make jitterbug run rakbench on every github push 16:22
pmichaud: and less work, too :)
pmichaud this is especially true given that "rakudo" really has two commit streams -- rakudo and parrot
tadzik dukeleto: yeah, I like how jitterbug shows the buildtime :)
pmichaud also, rakbench makes some very large log files
dukeleto tadzik: rakudo tests on jitterbug are still broken because I have not had time to look into what is messed up in the environment 16:23
pmichaud granted, we could cycle those somehow..
anyway, I'm not opposed to someone setting up a rakbench service, but I want to make sure rakbench stays more focused on being a useful forensic/development tool than being a monitoring service
atrodo pmichaud> I missed the link to rakbench, do you have it handy? 16:24
pmichaud github.com/pmichaud/rakbench
atrodo pmichaud> thanks
pmichaud also, rakbench runs can take a long time, depending on what's being benched.
16:25 redicaps left
pmichaud for example, running the full suite (without spectests) took 2 hours on my super-fast new desktop 16:25
tadzik 'oh 16:29
16:33 bluescreen left 16:45 mikehh joined, bluescreen joined 17:00 birdwindupbird left
pmichaud although, with the way that rakbench handles its log files it could potentially cache the results of previous runs 17:00
I think that gets a little suspect, though, because it makes it more likely other factors could come into play in the measurements 17:01
cotto_work ~~ 17:08
dukeleto cotto_work: greetings
cotto_work hi dukeleto 17:11
dukeleto: tell me about Parrot::Git::Describe and Parrot:SHA1's caching. Is there a reason to continue to do it if we want to make sure that the data it returns are never out of date? 17:12
*they return 17:13
dukeleto cotto_work: i guess i haven't been following closely. What is the problem with the way things work now?
cotto_work I'm working on trac.parrot.org/parrot/ticket/2106 , the goal of which is to make sure that what parrot_config sha1 and parrot_cofnig git_descibe always reflect the git commit that parrot was built with. 17:15
Part of that is to make sure there aren't any stale cached values lying around. 17:16
17:17 jsut joined, jsut_ left 17:26 benabik left
cotto_work dukeleto: in that context, do you see any reason to continue caching git_describe and sha1? 17:35
either that, or make them smart enough to know when to invalidate the cached data 17:36
17:36 mj41 left 17:38 benabik joined
dukeleto cotto_work: reading the tt now 17:40
cotto_work: we have a lot of configure-time tests for the git_describe stuff 17:41
cotto_work: those tests expect to know about the current sha1 before build time 17:42
cotto_work: so we need to decide how we want stuff to work
cotto_work: what happens if something wants to know the current git_describe output for parrot.git, before parrot has been built? 17:43
cotto_work: such as configure-time tests
cotto_work dukeleto: I'm not changing Parrot::Git::Describe and SHA1, just deleting the auto:: stuff.
dukeleto cotto_work: i am +1 to emulating what Rakudo does
cotto_work: feel free to nuke the caching stuff
cotto_work deal 17:44
dukeleto: why was it cached in the first place? Is it really slow on some platforms? 17:45
dukeleto cotto_work: svn revs were cached in the olden days, and that feature was migrated when I converted us to Git. But now that you ask, it is kind of dumb, since Git is so fast. 17:47
cotto_work: but the operation could take a few seconds
cotto_work: on slow HD's with bad I/O
cotto_work: so caching it is useful for some situations still
17:48 lucian joined 17:50 rurban_ joined 17:51 lucian_ joined, lucian left 17:52 rurban left, rurban_ is now known as rurban
pmichaud ....why would the operation be slow for git describe? 17:57
iirc, svn could be slow because it wanted to talk to the svn server
although maybe not for rev numbers
anyway, I'd say eliminate the cache and see if anyone complains 17:58
18:04 mj41 joined
sorear git describe can be slow because it's an O(N) operation in the worst case 18:05
dukeleto pmichaud: "slow" in the git world, not "slow" in the svn world :)
sorear it needs to find the nearest tag and count commits to it
dukeleto it is O(N), where N is the number of commits since the last tag
but in practice, since we create a tag every month, N is never very large
sorear could take as much as 15-30 seconds with a cold cache on an unpacked niecza repo with N=100
if you git gc often, it's not nearly so bad 18:06
also, if you use git rev-parse HEAD instead, that's instant
O(1)
dukeleto sorear: to get a commit SHA1, yes.
sorear: but we want a git describe string
so we definitely don't need to cache the current SHA1 18:07
but caching our git-describe string would be nice, but perhaps it is not worth the trouble
pmichaud msg bacek how did you determine the number of calls to Parrot_binding_bind_llsig? I'd like to be able to use that for my own tests 18:09
aloha OK. I'll deliver the message.
Coke_ a smarter cache would be nice. the current behavior has been an issue since the git cutover. 18:12
a minor one, to be sure.
dalek rrot/compiletime-git-describe: 5a96a78 | cotto++ | / (9 files):
remove Git::Describe and SHA1 caching, update tests, manifix
 18:22
rrot/compiletime-git-describe: c7030af | cotto++ | config/gen/makefiles/root.in:
fix config.fpmc depenency on parrot_version.pir
cotto_work Coke_: done fsvo "smarter". 18:39
18:45 mj41 left 19:06 soh_cah_toa joined 19:28 ShaneC left
soh_cah_toa whiteknight: hey 19:33
whiteknight soh_cah_toa, hello
soh_cah_toa whiteknight: i came across the book "parrot developer's guide" on amazon and noticed you were one of authors 19:34
whiteknight: how up to date is that book?
whiteknight: i mean, is it worth getting or is docs.parrot.org just as good or better? 19:35
whiteknight not up to date. Not worth getting
all the text of it is in the repo
in /docs/book
soh_cah_toa i thought so 19:36
19:42 ShaneC joined 19:45 ShaneC left
whiteknight I don't feel like we are ready to try writing a new book or updated version yet 19:51
not enough about Parrot usage has changed since that last book was written, and we haven't seen enough general improvements
after some object model improvements, and maybe some PCC changes, we might be readyu 19:52
if we have a nice debugger to talk about, that would be hot too :)
benabik PCC?
whiteknight Parrot Calling Conventions
benabik aloha: PCC?
aloha benabik: PCC is a hog
whiteknight that's the dynamic dispatch and parameter passing mechanism
aloha PCC is Parrot Calling Conventions
aloha whiteknight: ... but PCC is a hog ... 19:53
whiteknight damnit bot!
benabik aloha: PCC is also Parrot Calling Conventions
aloha benabik: Okay.
benabik aloha: PCC?
aloha benabik: PCC is a hog or Parrot Calling Conventions
benabik has to go to class.
whiteknight aloha needs to do more what I mean, and less what I say
benabik aloha: No, PCC is Parrot Calling Conventions
aloha benabik: Okay.
benabik read aloha's help a couple times. :-D
But I should really run, not walk, to class.
19:53 benabik left 19:54 TiMBuS left 20:00 ambs joined 20:07 ambs_ joined, ambs left, ambs_ is now known as ambs 20:09 whiteknight left, whiteknight joined 20:20 ambs_ joined, ambs left, ambs_ is now known as ambs 20:21 Coke left, Coke joined 20:25 whiteknight left
pmichaud Parrot's bug reporting system appears to be very hostile to anyone that actually wants to report a bug: see the saga at irclog.perlgeek.de/perl6/2011-05-11#i_3718015 20:31
be sure to read through at least irclog.perlgeek.de/perl6/2011-05-11#i_3718235 20:32
20:32 TiMBuS joined
cotto_work pmichaud: trac accounts got fubar'd due to some issues with the VM *.parrot.org runs on. Still, we need to either make parrotbug useful, delete it or hide it better. 20:35
20:36 Coke left 20:37 Coke joined
NotFound dukeleto: ping 20:37
pmichaud not just parrotbug, but the entire reporting system (at least as it exists now)
even once we decided not to use parrotbug, colomon couldn't submit the ticket 20:38
cotto_work pmichaud: he can now. We had to disable allowing registered users to submit tickets due to excessive spam. 20:39
moritz cotto_work: did you read the discussion? 20:40
cotto_work moritz: I updated his permissions. 20:41
moritz cotto_work: aka "no"?
cotto_work moritz: I saw that once he logged in, he got the message that he didn't have the necessary bit to create a ticket. The other problems are also legitimiate, but that looked like the most immediate one and the easiest to fix. 20:42
moritz ok 20:43
dalek TT #2107 created by colomon++: "Failed to load libpcre" during build
TT #2107: trac.parrot.org/parrot/ticket/2107
tadzik did my account broke too? 20:44
cotto_work tadzik: can you log in?
tadzik Invalid username or password
I'll reset it maybe 20:45
cotto_work tadzik: see privmsg
dukeleto NotFound: pong 20:48
pmichaud: yes, i want to fix those hostilities 20:49
i vote for making parrotbug actually send an email to a parrot-bugs mailing list
moritz tadzik: mine won't let me in either
NotFound dukeleto: What should I do to access the gcc compiler farm? Just to fill the form and mention your name?
pmichaud msg bacek fwiw, here's the latest rakudo-bleed timings (fixed some of the sin regression): gist.github.com/967313 20:50
aloha OK. I'll deliver the message.
dukeleto NotFound: yeah, just say that you are helping with Parrot Virtual Machine and mention my gcc username, which is "leto"
NotFound dukeleto: 206. leto on the wiki page?
dukeleto we could also make parrotbug open up a Trac Ticket
NotFound: yeps
NotFound Ok, I'll fill the form today and see what I can do with that beast. 20:51
cotto_work NotFound: great!
Coke_ (make parrotbug open a ticket) which it will, if you email it to the correct addres. 20:52
(as email2trac has been installed for sometime.)
pmichaud what's the addr?
can it go into docs/submissions.pod ? That's what we were looking for in the first place. :-/
Coke_ it's either tickets or parrot-tickets
IIRC.
one is for Talking to trac, one is for people to sub to so they can see ticket updates. 20:53
pmichaud can there be a parrotbug@... email addr? that would be more canonical
Coke_ Not my call.
I don't care what it is, if it's advertised. 20:54
pmichaud Mine either. But submission via email is what we wanted but couldn't find.
Coke_ (and canonical... in what sense? In that it would match rakudo?)
anyway, it's there, it's just not advertised.
20:54 ambs_ joined 20:55 ambs_ left
Coke_ email to tickets@parrot.org will create a new ticket. 20:55
20:56 ambs left
Coke_ see #2108. 20:56
(in that it created that ticket, not that that ticket says anything helpful)
Enjoy.
pmichaud "canonical" in the sense that it's also the name of the tool Parrot provides to report bugs. :-) 20:57
20:57 ambs joined
tadzik g'night #parrot 20:58
dalek TT #2108 created by coke++: We need a way to automatically create tickets...
TT #2108: trac.parrot.org/parrot/ticket/2108
TT #2108 closed by coke++: We need a way to automatically create tickets...
TT #2108: trac.parrot.org/parrot/ticket/2108
TT #2108 reopened by coke++: We need a way to automatically create tickets...
TT #2108: trac.parrot.org/parrot/ticket/2108 20:59
Coke_ changed 2108 into our "please doc this and also make it really work" ticket. 21:00
dalek rrot: 9ba6ab1 | pmichaud++ | docs/submissions.pod:
[docs] Update submissions.pod with ticket@parrot.org address.
 21:01
21:04 bluescreen_ joined 21:06 particle left 21:07 jsut_ joined 21:08 particle joined 21:12 jsut left 21:21 bluescreen__ joined 21:22 spinclad joined 21:25 mj41 joined 21:30 ambs left 21:33 spinclad left
mj41 Coke_: Hi. You can try start your taptinder client again. 21:34
21:39 theory left 21:40 bluescreen left, bluescreen__ left, bluescreen_ left
bacek good morning, humans 21:43
pmichaud, ping
msg pmichaud I'm using valgrind --tool=callgrind for getting numbers. 21:44
aloha OK. I'll deliver the message.
bacek msg pmichaud I suspect I can't make rakudo faster anymore on your box by tuning GC. Looks like with 8G of memory GC isn't triggered often enough. (Apart from rx.t test which actually creates a lot of GCable) 21:54
aloha OK. I'll deliver the message.
dalek rrot: 3dbd5d8 | bacek++ | src/pmc/capture.pmc:
Mark Capture.list and .hash with :manual_wb pragma.

This prevents auto-triggering of WB and should speedup at least PCT's POST and PIR stages.		 22:14
22:29 mj41 left, cotto left 22:33 whiteknight joined 22:34 kid51 joined 22:44 athomason joined 22:47 whiteknight left, whiteknight joined 22:50 athomason left 22:53 athomason joined 22:56 whiteknight left, whiteknight joined 22:57 whiteknight left, whiteknight joined 22:59 alh joined
whiteknight good afternoon, #parrot 23:00
sorear Has OSUOSL told us *what* is going on yet? 23:01
whiteknight with trac? no
sorear Or just "Y'all have to change your passwords and we're under NDA as to why"?
whiteknight smolder ate up all available disk space, and I guess that must have screwed up trac somehow 23:02
KaeseEs not such a good afternoon. finals loom :( "sing in me muse, and through me tell the story of that engineering student skilled in all ways of bullshitting, the hacker, harried for semesters, until he plunder the proud heights of data structures and algorithms..."
whiteknight KaeseEs: what classes do you have finals for? 23:03
KaeseEs comp arch, algorithms, comp org 23:04
whiteknight oh, that's not so bad
KaeseEs yeah it's reasonable but it's my nature to be filled with dread regardless :v 23:05
23:05 janus left
whiteknight is slowly trying to add a new color theme, and it's a lot of trial-and-error 23:07
the themeing capabilities are ...rough 23:08
23:15 theory joined 23:17 kid51 is now known as kid51_at_dinner 23:21 hercynium left
NotFound whiteknight: I've read your post and I think we can do some proof of concept tests right now. 23:26
whiteknight how? hand-crafted PASM?
NotFound Just by using :call_sig 23:27
whiteknight no, that still goes through fill_params 23:28
it creates a CallContext, and stores a second CallContext inside it, I think
23:28 janus joined
whiteknight I have to look 23:28
NotFound Yes, but it will test the ability to hand encode and decode params fast.
Also, I think :call_sig bypasses most of fill_params 23:29
whiteknight :call_sig is kind of a hack right now. We might be able to make it faster 23:30
bacek_at_work ~~
NotFound Yes, but for proof of concept tests may be enough.
bacek_at_work our PCC suck big time.
whiteknight we also could hand-craft some PASM to make faster calls. But we would still need to add a 3-argument invokecc
bacek_at_work: yes, we already know that :) 23:31
bacek_at_work We allocating intermediate storage just to pass args
whiteknight bacek_at_work: did you see my blog? I want to kill all that
I want to kill fill_params, signatures, and loops
bacek_at_work whiteknight, I did.
whiteknight bacek_at_work: do you think that's a good strategy, or can we do better? 23:32
bacek_at_work You can't kill fill_params. Just because it's shaded between C and OPs
shared
whiteknight we can stop using fill_params for PIR->PIR calls
bacek_at_work whiteknight, your approach will not buy us anything.
you just move same logic to PIR 23:33
Until after we'll kill PCC_CELLs in CallContext we can't get any performance boost.
whiteknight bacek_at_work: either way, I think it's much cleaner and better for users 23:34
and our current system has thread-safety issues too
bacek_at_work may be.
afk 23:35
whiteknight I wonder how we would get rid of PCC_CELL
what's the most expensive, allocating/managing them, or accessing data in them? 23:36
I can't do any valgrinding tonight, unfortunately 23:37
NotFound I don't understad the threading issue. Another thread should use another context.
23:38 pjcj left
whiteknight It stores the context in interp 23:42
NotFound Now, that threads are still supposed to have its own interpreters. That must change. 23:44
whiteknight regardless, we shouldn't store temporary data in the interp between ops 23:45
KaeseEs was this prompted by the thread::tbb discussion on the list or is it its own thing btw?
whiteknight we can pass the CallContext to invokecc
KaeseEs: this is something else
23:45 rurban_ joined
plobsing whiteknight: invokecc is short for invoke-with-current-continuation. by definition it *needs* to take a continuation 23:48
23:48 rurban left, rurban_ is now known as rurban
plobsing and we already have an op to do that: "invoke" 23:50
NotFound I'm starting to think that the big issue is VTABLE_invoke 23:51
Its *next argument is not nearly enough for its tasks. 23:52
whiteknight plobsing: the continuation is not what I want to pass to invokecc, the CallContext is 23:53
invokecc only takes the sub to invoke, not the CallContext
invoke takes the sub and the return continuation, still no CallContext
plobsing what's the difference? callcontext is a big part of the environment that needs to be captured to create a continuation. 23:54
whiteknight the CallContext where the continuation is created, not the one that is going to form the execution environment for the called sub 23:55
plobsing ah
whiteknight and either way, there's still no reason why we should be storing the CallContext in the interp, at least not before we actually make the call
admittedly it hasn't been problematic so far to do it this way, but I don't think it's a good thing 23:56
bacek_at_work no, Continuation created in Sub.invoke
which responsible for about 15% of GC pressure
whiteknight bacek_at_work: that code is spread out in NCI.invoke and others too. It's a mess 23:57
15% of gc pressure for making return continuations? That's horrible
bacek_at_work we are creating too many GCable on each PCC call. 23:58
NCI.invoke doesn't create Continuation btw
whiteknight bacek_at_work: you're right. I was getting that confused with the tailcall code 23:59
it's the tailcall code that's spread out all over and is a mess

Powered by Cro and the Raku® Programming Language.

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

Thank you!