Camelia, the Perl 6 bug

IRC log for #parrot, 2011-05-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 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.
00:00 plobsing but as far as core goes, yes, it is the only provided mechanism
00:00 NotFound Look at die_from_exception, line 118
00:01 plobsing the auto::frames config step and the --buildframes config parameter have been nops for nearly 2 years
00:02 whiteknight NotFound: We get past that point
00:02 whiteknight die_from_exception calls Parrot_x_jump_out, which has no jump buff
00:02 whiteknight then it calls exit()
00:04 NotFound What do you mean? That now we fail silently by design?
00:05 cotto_work It's not necessarily a good design.
00:08 NotFound Even abort is better. At least it can provide a backtraceable core.
00:09 atrodo is now known as atrodo_
00:10 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 atrodo_ left #parrot
00:11 atrodo joined #parrot
00:13 dalek parrot: 7a315db | Whiteknight++ | src/ (2 files):
00:13 dalek parrot: 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 dalek parrot: review: https://github.com/parrot/parrot/commit/7a315db937
00:13 dalek parrot: 69ee128 | Whiteknight++ | / (2 files):
00:13 dalek parrot: if we don't have an interp, print out an error message. If we do, try to print backtrace information (unlikely)
00:13 dalek parrot: review: https://github.com/parrot/parrot/commit/69ee128140
00:13 dalek parrot: ae39eec | Whiteknight++ | / (20 files):
00:13 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
00:13 dalek parrot: review: https://github.com/parrot/parrot/commit/ae39eecc1d
00:13 whiteknight plobsing: just pushed something. It's not perfect, but at least you get a message that initialization failed
00:15 whiteknight at least the failures aren't silent now
00:15 ttbot Parrot 69ee1281 i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/1329
00:16 plobsing whiteknight: you committed the testcase along with the fix
00:16 whiteknight lolfail
00:16 plobsing that's usually commendable, but not so much in this case
00:16 whiteknight ...no i didn't
00:17 whiteknight ...
00:17 whiteknight ...
00:17 dalek parrot: f5c6248 | Whiteknight++ | src/nci/extra_thunks.c:
00:17 dalek parrot: remove fail
00:17 dalek parrot: review: https://github.com/parrot/parrot/commit/f5c6248314
00:17 ttbot Parrot ae39eecc i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/1338
00:17 whiteknight ...see?
00:17 plobsing your mind tricks won't work on me, jedi
00:17 atrodo so whiteknight, is the slowness in method calls are because of method lookup?
00:18 whiteknight atrodo: far from it. method lookup is pretty quick. It's a vtable call and typically hash lookup
00:18 whiteknight atrodo: PCC invocation is the biggest portion of it
00:18 whiteknight fill_params is a beast usually, although those benchmarks I posted had no arguments
00:18 atrodo whiteknight> oh.  I assumed PCC was faster than the lookup
00:19 whiteknight well, no explicit arguments
00:19 whiteknight no PCC is a hog
00:19 NotFound whiteknight: backtrace information after a longjmp will not be very useful.
00:19 cotto_work whiteknight: have you considered adding a favicon to your site?
00:20 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
00:20 whiteknight atrodo: I haven't valgrinded that benchmark. I don't know where the waste is
00:20 atrodo whiteknight: but that's your suspicion?
00:21 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.
00:21 whiteknight plobsing: yes, that's true. I still don't think find_method vtable is going to be a big portion of that benchmark
00:22 whiteknight I'll give it a spin
00:22 cotto_work whiteknight: the rage guy?
00:22 plobsing whiteknight: I'm not suggesting it does. I'm suggesting you prove it doesn't.
00:23 atrodo whiteknight: do you have something readily handy that I can valgrind?  Will the code on your blog do the trick?
00:23 Caelum left #parrot
00:23 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:26 ttbot Parrot f5c62483 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/1368
00:26 cotto_work whiteknight: you could use inf gc to avoid seeing its cost
00:27 whiteknight https://gist.github.com/965672
00:29 whiteknight find_method takes up about 11% of that benchmark
00:29 whiteknight atrodo: so find_method can be improved, but it's not the worst offender
00:30 cotto_work dukeleto: ping
00:30 whiteknight I'm going to run it again with a non-method sub call
00:30 whiteknight 3.171735s
00:31 whiteknight so that's cheaper still. about 25% less than a method call with dynamic method lookup
00:31 atrodo aloha, winxed?
00:31 aloha atrodo: winxed is http://code.google.com/p/winxed/ or http://winxed.org/
00:31 whiteknight atrodo: plumage install winxed
00:32 atrodo aloha, plumage?
00:32 aloha atrodo: plumage is a package manager for Parrot or https://github.com/parrot/plumage
00:32 atrodo whiteknight: does it pull via svn?
00:32 whiteknight atrodo: git
00:32 dalek parrot: 0eef3cd | NotFound++ | src/embed/api.c:
00:32 dalek parrot: fix C90 compliance
00:32 dalek parrot: review: https://github.com/parrot/parrot/commit/0eef3cdeab
00:32 whiteknight er, plumage will use svn to get winxed
00:33 atrodo whiteknight: yea, that's tricky when svn isn't installed
00:33 NotFound plumage use whatever the package says in its metadata.
00:33 whiteknight ah
00:40 * atrodo is not working on isparrotfastyet like planned
00:42 cotto_work slacker
00:42 * cotto_work always works on everything exactly when planned
00:42 atrodo i know, seriously
00:42 cotto_work to the microsecond
00:44 whiteknight I don't think that method calls with static dispatch should cost significantly more than function calls, but they do
00:44 whiteknight well, not significantly
00:47 atrodo how up to date is the PDD on PCC?
00:48 Coke left #parrot
00:48 KaeseEs atrodo: the mozilla version measured themselves against chrome and safari, what's isparrotfastyet going to use for the, erm, target?
00:48 Coke joined #parrot
00:49 atrodo KaeseEs: That's a downfall, we don't really have anything to compare against except our historical self
00:51 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
00:52 atrodo 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 https://gist.github.com/965672
00:52 KaeseEs ah.
00:53 whiteknight atrodo: I don't know where the PCC PDD stands
00:54 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:55 Coke left #parrot
00:55 Coke joined #parrot
00:56 atrodo whiteknight: You left the s at the end of the % different
00:56 whiteknight atrodo: think of it like a nice bonus
00:56 atrodo hurray!  bonus!
00:57 atrodo whiteknight: https://gist.github.com/965709 so right in line with yours
00:58 whiteknight atrodo: your timings are significantly better than mind
00:58 whiteknight I'm using an unoptimized Parrot
00:59 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
01:01 whiteknight plobsing: yeah, that's what I figured. It has a cost, but it's not the lions share
01:01 whiteknight 10% about
01:01 whiteknight PIC could help reduce that, but we have bigger fish to fry
01:02 plobsing 10%? did you look at atrodo's numbers?
01:02 whiteknight no, I don't look at anybody's numbers but my own
01:02 whiteknight ...on my system it's 10%
01:03 Coke left #parrot
01:03 Coke joined #parrot
01:03 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
01:03 plobsing which I would attribute to noise more than anything else
01:04 atrodo whiteknight: blame it on it being on a VM
01:05 whiteknight either way, vtable override is horrible
01:05 whiteknight let's all agree on that
01:06 atrodo agreed
01:08 whiteknight I firmly believe that static dispatch methods should not be noticably slower than regular function calls
01:08 whiteknight and I believe that all invocations should be noticably faster
01:10 Caelum joined #parrot
01:12 atrodo there's really no reason for dispatch to be that widely varied
01:13 woosley joined #parrot
01:18 * atrodo needs to figure out callgrind
01:18 whiteknight > callgrind --just-do-it winxed test.winxed
01:18 whiteknight I wish more programs had the --just-do-it option
01:19 atrodo ubuntu didn't install "callgrind"
01:20 plobsing atrodo: callgrind is one of the tools available to run from valgrind
01:20 atrodo plobsing: Aye, i got that, finally
01:21 plobsing I run it via "alias cg='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes'"
01:23 atrodo plobsing: thanks, that should help me figure out what i want and what i'm seeing
01:26 atrodo https://gist.github.com/965709 dunno what that means yet
01:28 plobsing atrodo: that means your using an unoptimized parrot and your performance is dominated by a sanity-checking register-access function
01:30 plobsing atrodo: you may want to run callgrind_annotate with --inclusive=yes
01:30 plobsing but only after you run an optimized build. benchmarking debug builds is pretty meaningless
01:38 whiteknight left #parrot
01:46 plobsing atrodo: I have some ideas related to benchmarking I'd like to run by you
01:50 rurban_ joined #parrot
01:52 rurban left #parrot
01:52 rurban_ is now known as rurban
02:23 dalek tracwiki: v1 | plobsing++ | ParrotDeprecationsFor3.6
02:23 dalek tracwiki: add deprecation notes for TT #1931</a>
02:23 dalek tracwiki: http://trac.parrot.org/parrot/wiki/ParrotDe​precationsFor3.6?version=1&amp;action=diff
02:23 dalek tracwiki: v32 | plobsing++ | ParrotDeprecations
02:23 dalek tracwiki: add deprecation notice for TT #1931</a>
02:23 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Parro​tDeprecations?version=32&amp;action=diff
02:25 atrodo plobsing: sorry, got pulled away.  what are you thinking?
02:27 Andy joined #parrot
02:30 plobsing a problem with benchmarking is that it is almost always special purpose and only relevant to a single machine
02:31 plobsing 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 plobsing I was thinking a machine emulator such as bochs would be suitable for such a task
02:31 plobsing the end result might be that we could have community contributions to something like ipfy, but with much better scope and detail
02:32 sorear plobsing: we already have a machine emulator that counts instructions
02:32 sorear chromatic uses it often
02:32 plobsing sorear: valgrind is inaccurate when it comes to wallclock time
02:32 plobsing I'd like something a little closer
02:33 dukeleto plobsing: i think a benchmark tests which calibrates itself once on a machine, and then tests relative performance changes against that
02:33 dukeleto plobsing: I definitely have benchmarking planned for Jitterbug
02:34 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?
02:34 atrodo plobsing: Ya, i'd like to see something like that happen sometime
02:34 arnsholt_ Assuming the times are normally distributed, run a suitable n number of runs, and normalise to zero mean one variance score
02:35 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
02:35 dukeleto atrodo: possibly. there sure is some overlap
02:35 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
02:36 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
02:37 plobsing basically the rule is that benchmarks are only comparable over a homogenous set of machines
02:37 atrodo plobsing: https://gist.github.com/965709 Does that look beter?
02:39 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:40 dukeleto atrodo: is the source of ipfy somewhere public?
02:40 atrodo dukeleto: https://github.com/atrodo/itfy although it doesn't reflect my upcoming refactoring yet
02:41 dukeleto atrodo: catalyst?
02:41 atrodo dukeleto: Correct
02:41 dukeleto atrodo: cool
02:44 hudnix left #parrot
02:46 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:47 atrodo plobsing: I'm seriously considering it
02:47 atrodo I think my problem is I want it to look like NYTProf
02:48 mtk left #parrot
02:49 dalek parrot: 9254cf3 | plobsing++ | api.yaml:
02:49 dalek parrot: add deprecation notice for TT #1931 not ported over from DEPRECATED.pod
02:49 dalek parrot: review: https://github.com/parrot/parrot/commit/9254cf31e4
02:49 dalek parrot: d5f1750 | plobsing++ | api.yaml:
02:49 dalek parrot: mark TT #1931 deprecation as complete
02:49 dalek parrot: review: https://github.com/parrot/parrot/commit/d5f1750c66
02:51 preflex left #parrot
02:52 plobsing atrodo: kcachegrind does provide a source view
02:54 dalek TT #1931 closed by plobsing++: [DEPRECATED] advanced NCI parameter types
02:54 dalek TT #1931: http://trac.parrot.org/parrot/ticket/1931
02:55 preflex joined #parrot
02:55 mtk joined #parrot
02:57 Andy left #parrot
03:10 bubaflub left #parrot
03:14 Andy joined #parrot
03:27 cotto ~~
03:30 dalek parrot: e3492bf | plobsing++ | config/gen/makefiles/root.in:
03:30 dalek parrot: NCI/call_toolkit_init.pbc no longer exists
03:30 dalek parrot: review: https://github.com/parrot/parrot/commit/e3492bfcf7
03:35 benabik joined #parrot
03:44 plobsing seen japhb
03:44 aloha Sorry, I haven't seen japhb.
03:44 jjore left #parrot
03:45 soh_cah_toa left #parrot
04:16 jjore joined #parrot
04:40 ShaneC joined #parrot
05:15 Andy left #parrot
05:23 birdwindupbird joined #parrot
06:06 cottoo joined #parrot
06:06 cotto left #parrot
06:07 cottoo is now known as cotto
06:07 cotto my kernel oops, let me show you it
06:33 dalek parrot: 6032439 | mikehh++ | MANIFEST:
06:33 dalek parrot: re-generate MANIFEST
06:33 dalek parrot: review: https://github.com/parrot/parrot/commit/6032439fe3
06:34 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:36 UltraDM joined #parrot
07:06 bacek ~~
07:09 bacek 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.
07:10 bacek msg Same for GCable 17M vs 13M.
07:10 aloha OK. I'll deliver the message.
07:10 bacek msg pmichaud Same for GCable 17M vs 13M.
07:10 aloha OK. I'll deliver the message.
07:17 preflex left #parrot
07:19 bacek msg pmichaud s/04/bleed/
07:19 aloha OK. I'll deliver the message.
07:20 preflex joined #parrot
07:22 bacek aloha, (191599 - 160450) / 191599 * 100
07:22 aloha bacek: 16.2573917400404
07:24 mj41 joined #parrot
07:26 dalek parrot: 3b374ae | bacek++ | src/call/args.c:
07:26 dalek parrot: [pcc] Reduce GC pressure in handling named args.
07:26 dalek parrot:
07:26 dalek parrot: Instead of creating new RSA with arg names iterate over hash directly.
07:26 dalek parrot: It gives some performance boost. 16.25% in instructions fetch according
07:26 dalek parrot: to valgrind on building rakudo's core.pm.
07:26 dalek parrot: review: https://github.com/parrot/parrot/commit/3b374ae6ed
07:34 bacek aloha, 151/43*100
07:34 aloha bacek: 351.162790697674
07:34 bacek aloha, 151/43*
07:34 bacek aloha, 151/43
07:34 aloha bacek: 3.51162790697674
07:34 bacek 43/151*100
07:34 aloha 28.476821192053
07:35 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 #parrot
07:54 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.
07:55 bacek Something like 15% I hope
07:55 tadzik well, that's expected
07:55 tadzik oh nice
08:00 bacek But it's on my box. And I can't trust my benchmarks anymore.
08:00 tadzik I can check that
08:00 bacek Just because it's quite different from pmichaud++ benchmarks.
08:00 bacek tadzik, iwbn
08:07 baest joined #parrot
08:11 benabik left #parrot
08:15 mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_3_0-199-g3b374ae
08:15 mikehh Kubuntu 11.04 amd64 (g++)
08:15 tadzik I think I'll need a make clean before rebuilding
08:21 tadzik bacek: almost no changes in building core.pm
08:22 nopaste "tadzik" at 192.168.1.3 pasted "Latest patch timings for bacek++" (30 lines) at http://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
08:24 bacek tadzik, are you running on 64 bits?
08:26 tadzik bacek: yes
08:27 bacek tadzik, gms behave quite... interestingly on 64 bits.
08:28 bacek I have no idea why
08:34 dalek parrot/compiletime-git-describe: 51e393d | cotto++ | / (2 files):
08:34 dalek parrot/compiletime-git-describe: add code to generate Parrot version macros as a separate PIR include
08:34 dalek parrot/compiletime-git-describe: review: https://github.com/parrot/parrot/commit/51e393d8c9
08:34 dalek parrot/compiletime-git-describe: c2143de | cotto++ | / (6 files):
08:34 dalek parrot/compiletime-git-describe: nuke auto::sha1 et al, make config_lib,pir rely on gen_version.pl's generated include
08:34 dalek parrot/compiletime-git-describe: review: https://github.com/parrot/parrot/commit/c2143de525
08:39 Khisanth left #parrot
08:48 Khisanth joined #parrot
08:53 dalek parrot/compiletime-git-describe: f0fcd38 | cotto++ | tools/build/gen_version.pl:
08:53 dalek parrot/compiletime-git-describe: force sha1 and git-describe to be recalculated when running gen_version
08:53 dalek parrot/compiletime-git-describe: review: https://github.com/parrot/parrot/commit/f0fcd38e93
09:06 mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_3_0-199-g3b374ae
09:06 mikehh Kubuntu 11.04 amd64 (g++ --optimize)
09:11 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.
09:11 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.
09:11 aloha OK. I'll deliver the message.
09:49 rurban_ joined #parrot
09:52 rurban left #parrot
09:52 rurban_ is now known as rurban
09:59 woosley left #parrot
10:07 frodwith left #parrot
10:08 frodwith joined #parrot
10:17 ShaneC left #parrot
10:24 ShaneC joined #parrot
10:36 mtk left #parrot
10:42 mtk joined #parrot
11:01 Psyche^ joined #parrot
11:07 Patterner left #parrot
11:07 Psyche^ is now known as Patterner
11:07 redicaps joined #parrot
11:15 redicaps left #parrot
11:21 mikehh left #parrot
11:41 woosley joined #parrot
11:44 spinclad left #parrot
12:03 hudnix joined #parrot
12:19 whiteknight joined #parrot
12:20 whiteknight Good morning, #parrot
12:36 bluescreen joined #parrot
12:37 whiteknight left #parrot
12:37 whiteknight joined #parrot
12:38 whiteknight left #parrot
12:38 whiteknight joined #parrot
12:38 Coke_ bacek++
13:06 bluescreen left #parrot
13:11 bubaflub joined #parrot
13:18 benabik joined #parrot
13:21 bluescreen joined #parrot
13:44 benabik ~~
13:46 bubaflub ~
13:47 plobsing left #parrot
13:47 plobsing joined #parrot
14:21 luben_at_work joined #parrot
14:27 woosley left #parrot
14:35 redicaps joined #parrot
14:36 UltraDM left #parrot
14:56 luben_at_work left #parrot
15:19 pmichaud good morning, #parrot
15:19 benabik o/ pmichaud
15:21 Coke_ \o
15:24 plobsing --- -..-.
15:27 benabik plobsing: I couldn't for the life of me remember what -..-. is.  That's a rarity.
15:29 tadzik http://www.wolframalpha.com/input/?i=---+-..-. :)
15:29 plobsing ---... -.--.-
15:29 whiteknight nobody calls me an ox!
15:30 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 #parrot
15:31 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
15:31 whiteknight actually, american morse code and ITU
15:31 * Coke_ needs to get his bot in here. :P
15:31 benabik tadzik: Oh.  D'oh.
15:32 tadzik --- .... .-.-.-     -.. .----. --- .... .-.-.-
15:32 tadzik :)
15:32 benabik whiteknight: I think US hams use the ITU standard, although I could be wrong.
15:33 whiteknight I've never been a ham. I don't know
15:34 whiteknight 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.
15:35 benabik Radio + sound card = me using morse code.
15:38 dukeleto ~~
16:15 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).  http://gist.github.com/966698
16:15 aloha OK. I'll deliver the message.
16:21 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.
16:21 pmichaud I think "run after every commit" is misleading.
16:21 pmichaud my experience this past week is that benchmarking releases is far more useful
16:22 dukeleto tadzik: i could make jitterbug run rakbench on every github push
16:22 dukeleto pmichaud: and less work, too :)
16:22 pmichaud this is especially true given that "rakudo" really has two commit streams -- rakudo and parrot
16:22 tadzik dukeleto: yeah, I like how jitterbug shows the buildtime :)
16:22 pmichaud also, rakbench makes some very large log files
16:23 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..
16:23 pmichaud 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
16:24 atrodo pmichaud> I missed the link to rakbench, do you have it handy?
16:24 pmichaud http://github.com/pmichaud/rakbench
16:24 atrodo pmichaud> thanks
16:24 pmichaud also, rakbench runs can take a long time, depending on what's being benched.
16:25 redicaps left #parrot
16:25 pmichaud for example, running the full suite (without spectests) took 2 hours on my super-fast new desktop
16:29 tadzik 'oh
16:33 bluescreen left #parrot
16:45 mikehh joined #parrot
16:45 bluescreen joined #parrot
17:00 birdwindupbird left #parrot
17:00 pmichaud although, with the way that rakbench handles its log files it could potentially cache the results of previous runs
17:01 pmichaud I think that gets a little suspect, though, because it makes it more likely other factors could come into play in the measurements
17:08 cotto_work ~~
17:08 dukeleto cotto_work: greetings
17:11 cotto_work hi dukeleto
17:12 cotto_work 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:13 cotto_work *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?
17:15 cotto_work I'm working on https://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:16 cotto_work Part of that is to make sure there aren't any stale cached values lying around.
17:17 jsut joined #parrot
17:17 jsut_ left #parrot
17:26 benabik left #parrot
17:35 cotto_work dukeleto: in that context, do you see any reason to continue caching git_describe and sha1?
17:36 cotto_work either that, or make them smart enough to know when to invalidate the cached data
17:36 mj41 left #parrot
17:38 benabik joined #parrot
17:40 dukeleto cotto_work: reading the tt now
17:41 dukeleto cotto_work: we have a lot of configure-time tests for the git_describe stuff
17:42 dukeleto cotto_work: those tests expect to know about the current sha1 before build time
17:42 dukeleto cotto_work: so we need to decide how we want stuff to work
17:43 dukeleto cotto_work: what happens if something wants to know the current git_describe output for parrot.git, before parrot has been built?
17:43 dukeleto cotto_work: such as configure-time tests
17:43 cotto_work dukeleto: I'm not changing Parrot::Git::Describe and SHA1, just deleting the auto:: stuff.
17:43 dukeleto cotto_work: i am +1 to emulating what Rakudo does
17:43 dukeleto cotto_work: feel free to nuke the caching stuff
17:44 cotto_work deal
17:45 cotto_work dukeleto: why was it cached in the first place?  Is it really slow on some platforms?
17:47 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 dukeleto cotto_work: but the operation could take a few seconds
17:47 dukeleto cotto_work: on slow HD's with bad I/O
17:47 dukeleto cotto_work: so caching it is useful for some situations still
17:48 lucian joined #parrot
17:50 rurban_ joined #parrot
17:51 lucian_ joined #parrot
17:51 lucian left #parrot
17:52 rurban left #parrot
17:52 rurban_ is now known as rurban
17:57 pmichaud ....why would the operation be slow for git describe?
17:57 pmichaud iirc, svn could be slow because it wanted to talk to the svn server
17:57 pmichaud although maybe not for rev numbers
17:58 pmichaud anyway, I'd say eliminate the cache and see if anyone complains
18:04 mj41 joined #parrot
18:05 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 :)
18:05 sorear it needs to find the nearest tag and count commits to it
18:05 dukeleto it is O(N), where N is the number of commits since the last tag
18:05 dukeleto but in practice, since we create a tag every month, N is never very large
18:05 sorear could take as much as 15-30 seconds with a cold cache on an unpacked niecza repo with N=100
18:06 sorear if you git gc often, it's not nearly so bad
18:06 sorear also, if you use git rev-parse HEAD instead, that's instant
18:06 sorear O(1)
18:06 dukeleto sorear: to get a commit SHA1, yes.
18:06 dukeleto sorear: but we want a git describe string
18:07 dukeleto so we definitely don't need to cache the current SHA1
18:07 dukeleto but caching our git-describe string would be nice, but perhaps it is not worth the trouble
18:09 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.
18:12 Coke_ a smarter cache would be nice. the current behavior has been an issue since the git cutover.
18:12 Coke_ a minor one, to be sure.
18:22 dalek parrot/compiletime-git-describe: 5a96a78 | cotto++ | / (9 files):
18:22 dalek parrot/compiletime-git-describe: remove Git::Describe and SHA1 caching, update tests, manifix
18:22 dalek parrot/compiletime-git-describe: review: https://github.com/parrot/parrot/commit/5a96a78fc3
18:22 dalek parrot/compiletime-git-describe: c7030af | cotto++ | config/gen/makefiles/root.in:
18:22 dalek parrot/compiletime-git-describe: fix config.fpmc depenency on parrot_version.pir
18:22 dalek parrot/compiletime-git-describe: review: https://github.com/parrot/parrot/commit/c7030aff26
18:39 cotto_work Coke_: done fsvo "smarter".
18:45 mj41 left #parrot
19:06 soh_cah_toa joined #parrot
19:28 ShaneC left #parrot
19:33 soh_cah_toa whiteknight: hey
19:33 whiteknight soh_cah_toa, hello
19:34 soh_cah_toa whiteknight: i came across the book "parrot developer's guide" on amazon and noticed you were one of authors
19:34 soh_cah_toa whiteknight: how up to date is that book?
19:35 soh_cah_toa 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
19:35 whiteknight all the text of it is in the repo
19:35 whiteknight in /docs/book
19:36 soh_cah_toa i thought so
19:42 ShaneC joined #parrot
19:45 ShaneC left #parrot
19:51 whiteknight I don't feel like we are ready to try writing a new book or updated version yet
19:51 whiteknight not enough about Parrot usage has changed since that last book was written, and we haven't seen enough general improvements
19:52 whiteknight after some object model improvements, and maybe some PCC changes, we might be readyu
19:52 whiteknight if we have a nice debugger to talk about, that would be hot too :)
19:52 benabik PCC?
19:52 whiteknight Parrot Calling Conventions
19:52 benabik aloha: PCC?
19:52 aloha benabik: PCC is a hog
19:52 whiteknight that's the dynamic dispatch and parameter passing mechanism
19:52 whiteknight aloha PCC is Parrot Calling Conventions
19:53 aloha whiteknight: ... but PCC is a hog ...
19:53 whiteknight damnit bot!
19:53 benabik aloha: PCC is also Parrot Calling Conventions
19:53 aloha benabik: Okay.
19:53 benabik aloha: PCC?
19:53 aloha benabik: PCC is a hog or Parrot Calling Conventions
19:53 * benabik has to go to class.
19:53 whiteknight aloha needs to do more what I mean, and less what I say
19:53 benabik aloha: No, PCC is Parrot Calling Conventions
19:53 aloha benabik: Okay.
19:53 * benabik read aloha's help a couple times.  :-D
19:53 benabik But I should really run, not walk, to class.
19:53 benabik left #parrot
19:54 TiMBuS left #parrot
20:00 ambs joined #parrot
20:07 ambs_ joined #parrot
20:07 ambs left #parrot
20:07 ambs_ is now known as ambs
20:09 whiteknight left #parrot
20:09 whiteknight joined #parrot
20:20 ambs_ joined #parrot
20:20 ambs left #parrot
20:20 ambs_ is now known as ambs
20:21 Coke left #parrot
20:21 Coke joined #parrot
20:25 whiteknight left #parrot
20:31 pmichaud Parrot's bug reporting system appears to be very hostile to anyone that actually wants to report a bug:  see the saga at http://irclog.perlgeek.de/​perl6/2011-05-11#i_3718015
20:32 pmichaud be sure to read through at least http://irclog.perlgeek.de/​perl6/2011-05-11#i_3718235
20:32 TiMBuS joined #parrot
20:35 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:36 Coke left #parrot
20:37 Coke joined #parrot
20:37 NotFound dukeleto: ping
20:37 pmichaud not just parrotbug, but the entire reporting system (at least as it exists now)
20:38 pmichaud even once we decided not to use parrotbug, colomon couldn't submit the ticket
20:39 cotto_work pmichaud: he can now.  We had to disable allowing registered users to submit tickets due to excessive spam.
20:40 moritz cotto_work: did you read the discussion?
20:41 cotto_work moritz: I updated his permissions.
20:41 moritz cotto_work: aka "no"?
20:42 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:43 moritz ok
20:43 dalek TT #2107 created by colomon++: "Failed to load libpcre" during build
20:43 dalek TT #2107: http://trac.parrot.org/parrot/ticket/2107
20:44 tadzik did my account broke too?
20:44 cotto_work tadzik: can you log in?
20:44 tadzik Invalid username or password
20:45 tadzik I'll reset it maybe
20:45 cotto_work tadzik: see privmsg
20:48 dukeleto NotFound: pong
20:49 dukeleto pmichaud: yes, i want to fix those hostilities
20:49 dukeleto i vote for making parrotbug actually send an email to a parrot-bugs mailing list
20:49 moritz tadzik: mine won't let me in either
20:49 NotFound dukeleto: What should I do to access the gcc compiler farm? Just to fill the form and mention your name?
20:50 pmichaud msg bacek fwiw, here's the latest rakudo-bleed timings (fixed some of the sin regression): http://gist.github.com/967313
20:50 aloha OK. I'll deliver the message.
20:50 dukeleto NotFound: yeah, just say that you are helping with Parrot Virtual Machine and mention my gcc username, which is "leto"
20:50 NotFound dukeleto: 206. leto on the wiki page?
20:50 dukeleto we could also make parrotbug open up a Trac Ticket
20:50 dukeleto NotFound: yeps
20:51 NotFound Ok, I'll fill the form today and see what I can do with that beast.
20:51 cotto_work NotFound: great!
20:52 Coke_ (make parrotbug open a ticket) which it will, if you email it to the correct addres.
20:52 Coke_ (as email2trac has been installed for sometime.)
20:52 pmichaud what's the addr?
20:52 pmichaud can it go into docs/submissions.pod ?  That's what we were looking for in the first place.  :-/
20:52 Coke_ it's either tickets or parrot-tickets
20:52 Coke_ IIRC.
20:53 Coke_ 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
20:53 Coke_ Not my call.
20:54 Coke_ 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.
20:54 Coke_ (and canonical... in what sense? In that it would match rakudo?)
20:54 Coke_ anyway, it's there, it's just not advertised.
20:54 ambs_ joined #parrot
20:55 ambs_ left #parrot
20:55 Coke_ email to tickets@parrot.org will create a new ticket.
20:56 ambs left #parrot
20:56 Coke_ see #2108.
20:56 Coke_ (in that it created that ticket, not that that ticket says anything helpful)
20:56 Coke_ Enjoy.
20:57 pmichaud "canonical" in the sense that it's also the name of the tool Parrot provides to report bugs.  :-)
20:57 ambs joined #parrot
20:58 tadzik g'night #parrot
20:58 dalek TT #2108 created by coke++: We need a way to automatically create tickets...
20:58 dalek TT #2108: http://trac.parrot.org/parrot/ticket/2108
20:58 dalek TT #2108 closed by coke++: We need a way to automatically create tickets...
20:58 dalek TT #2108: http://trac.parrot.org/parrot/ticket/2108
20:58 dalek TT #2108 reopened by coke++: We need a way to automatically create tickets...
20:59 dalek TT #2108: http://trac.parrot.org/parrot/ticket/2108
21:00 Coke_ changed 2108 into our "please doc this and also make it really work" ticket.
21:01 dalek parrot: 9ba6ab1 | pmichaud++ | docs/submissions.pod:
21:01 dalek parrot: [docs]  Update submissions.pod with ticket@parrot.org address.
21:01 dalek parrot: review: https://github.com/parrot/parrot/commit/9ba6ab196c
21:04 bluescreen_ joined #parrot
21:06 particle left #parrot
21:07 jsut_ joined #parrot
21:08 particle joined #parrot
21:12 jsut left #parrot
21:21 bluescreen__ joined #parrot
21:22 spinclad joined #parrot
21:25 mj41 joined #parrot
21:30 ambs left #parrot
21:33 spinclad left #parrot
21:34 mj41 Coke_: Hi. You can try start your taptinder client again.
21:39 theory left #parrot
21:40 bluescreen left #parrot
21:40 bluescreen__ left #parrot
21:40 bluescreen_ left #parrot
21:43 bacek good morning, humans
21:43 bacek pmichaud, ping
21:44 bacek msg pmichaud I'm using valgrind --tool=callgrind for getting numbers.
21:44 aloha OK. I'll deliver the message.
21:54 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.
22:14 dalek parrot: 3dbd5d8 | bacek++ | src/pmc/capture.pmc:
22:14 dalek parrot: Mark Capture.list and .hash with :manual_wb pragma.
22:14 dalek parrot:
22:14 dalek parrot: This prevents auto-triggering of WB and should speedup at least PCT's
22:14 dalek parrot: POST and PIR stages.
22:14 dalek parrot: review: https://github.com/parrot/parrot/commit/3dbd5d865b
22:29 mj41 left #parrot
22:29 cotto left #parrot
22:33 whiteknight joined #parrot
22:34 kid51 joined #parrot
22:44 athomason joined #parrot
22:47 whiteknight left #parrot
22:47 whiteknight joined #parrot
22:50 athomason left #parrot
22:53 athomason joined #parrot
22:56 whiteknight left #parrot
22:56 whiteknight joined #parrot
22:57 whiteknight left #parrot
22:57 whiteknight joined #parrot
22:59 alh joined #parrot
23:00 whiteknight good afternoon, #parrot
23:01 sorear Has OSUOSL told us *what* is going on yet?
23:01 whiteknight with trac? no
23:01 sorear Or just "Y'all have to change your passwords and we're under NDA as to why"?
23:02 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..."
23:03 whiteknight KaeseEs: what classes do you have finals for?
23:04 KaeseEs comp arch, algorithms, comp org
23:04 whiteknight oh, that's not so bad
23:05 KaeseEs yeah it's reasonable but it's my nature to be filled with dread regardless :v
23:05 janus left #parrot
23:07 * whiteknight is slowly trying to add a new color theme, and it's a lot of trial-and-error
23:08 whiteknight the themeing capabilities are ...rough
23:15 theory joined #parrot
23:17 kid51 is now known as kid51_at_dinner
23:21 hercynium left #parrot
23:26 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?
23:27 NotFound Just by using :call_sig
23:28 whiteknight no, that still goes through fill_params
23:28 whiteknight it creates a CallContext, and stores a second CallContext inside it, I think
23:28 janus joined #parrot
23:28 whiteknight I have to look
23:28 NotFound Yes, but it will test the ability to hand encode and decode params fast.
23:29 NotFound Also, I think :call_sig bypasses most of fill_params
23:30 whiteknight :call_sig is kind of a hack right now. We might be able to make it faster
23:30 bacek_at_work ~~
23:30 NotFound Yes, but for proof of concept tests may be enough.
23:30 bacek_at_work our PCC suck big time.
23:30 whiteknight we also could hand-craft some PASM to make faster calls. But we would still need to add a 3-argument invokecc
23:31 whiteknight bacek_at_work: yes, we already know that :)
23:31 bacek_at_work We allocating intermediate storage just to pass args
23:31 whiteknight bacek_at_work: did you see my blog? I want to kill all that
23:31 whiteknight I want to kill fill_params, signatures, and loops
23:31 bacek_at_work whiteknight, I did.
23:32 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
23:32 bacek_at_work shared
23:32 whiteknight we can stop using fill_params for PIR->PIR calls
23:32 bacek_at_work whiteknight, your approach will not buy us anything.
23:33 bacek_at_work you just move same logic to PIR
23:33 bacek_at_work Until after we'll kill PCC_CELLs in CallContext we can't get any performance boost.
23:34 whiteknight bacek_at_work: either way, I think it's much cleaner and better for users
23:34 whiteknight and our current system has thread-safety issues too
23:34 bacek_at_work may be.
23:35 bacek_at_work afk
23:35 whiteknight I wonder how we would get rid of PCC_CELL
23:36 whiteknight what's the most expensive, allocating/managing them, or accessing data in them?
23:37 whiteknight 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 #parrot
23:42 whiteknight It stores the context in interp
23:44 NotFound Now, that threads are still supposed to have its own interpreters. That must change.
23:45 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?
23:45 whiteknight we can pass the CallContext to invokecc
23:45 whiteknight KaeseEs: this is something else
23:45 rurban_ joined #parrot
23:48 plobsing whiteknight: invokecc is short for invoke-with-current-continuation. by definition it *needs* to take a continuation
23:48 rurban left #parrot
23:48 rurban_ is now known as rurban
23:50 plobsing and we already have an op to do that: "invoke"
23:51 NotFound I'm starting to think that the big issue is VTABLE_invoke
23:52 NotFound Its *next argument is not nearly enough for its tasks.
23:53 whiteknight plobsing: the continuation is not what I want to pass to invokecc, the CallContext is
23:53 whiteknight invokecc only takes the sub to invoke, not the CallContext
23:53 whiteknight invoke takes the sub and the return continuation, still no CallContext
23:54 plobsing what's the difference? callcontext is a big part of the environment that needs to be captured to create a continuation.
23:55 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
23:55 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
23:56 whiteknight 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
23:56 bacek_at_work which responsible for about 15% of GC pressure
23:57 whiteknight bacek_at_work: that code is spread out in NCI.invoke and others too. It's a mess
23:57 whiteknight 15% of gc pressure for making return continuations? That's horrible
23:58 bacek_at_work we are creating too many GCable on each PCC call.
23:58 bacek_at_work NCI.invoke doesn't create Continuation btw
23:59 whiteknight bacek_at_work: you're right. I was getting that confused with the tailcall code
23:59 whiteknight it's the tailcall code that's spread out all over and is a mess

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

Parrot | source cross referenced