|
Parrot 1.2.0 released | parrot.org/ | 305 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets Set by moderator on 22 May 2009. |
|||
| jonathan | bacek: Please can I suggest checking Rakudo builds against your changes too? It tends to exercise some bits taht Parrot's test suite doesn't always. | 00:00 | |
| bacek: Optimizations are nice, but of course risky. :-) | |||
| bacek | jonathan: of cause. | ||
| jonathan | bacek++ for working to make Parrot faster though :-) | 00:01 | |
| Infinoid | jonathan: I just did test rakudo, and of course it failed horribly... working on that now :) | ||
| purl, less multi? | |||
| purl | less multi is a rallying cry, like more cowbell | ||
| Infinoid | purl++ | ||
| cotto | darbelo, possibly. You should be aware that MULTIs are *much* slower than VTABLE functions. | 00:03 | |
| jonathan | cotto: The worst part is that they're slower even with a level of cache stuck in front of them... | 00:04 | |
| nopaste | "bacek" at 122.110.62.127 pasted "Flowless victory. Benchmarking after bumping numbers back." (12 lines) at nopaste.snit.ch/16646 | ||
| bacek | 561/111 | ||
| purl | 5.05405405405405 | ||
| bacek stealing chromatic's hat :) | |||
| cotto | VTABLEs are just a couple pointer derefs plus a function call, but MULTIs are considerably more complex. | 00:05 | |
| jonathan | bacek: Can you describe to me in like 2 sentences what you've done to achieve that? I haven't been following the patches too closely (you're too fast ;-)) | ||
| bacek | jonathan: kill MMD dispatch for VTABLE calls | ||
| jonathan | bacek: Is allison OK with this? | ||
| bacek | jonathan: She is author of TT#452 :) | 00:06 | |
| jonathan | bacek: Did you actually kill the option of having MMD for VTABLE calls, or just make a bunch of PMCs not need to be multi-dispatched? | ||
| bacek | latter. | ||
| We still use MMD when needed. | 00:07 | ||
| jonathan | bacek: OK, I just read the ticket. | ||
| OK, great. | |||
| bacek | But I think that we don't need MMD for VTABLEs... | ||
| jonathan | bacek++, and ++ to others working on that too. :-) | ||
| bacek | Infinoid: I've merged trunk into branch. dcommiting. have to run | 00:09 | |
| cotto | heh. drive-by merging | ||
| bacek | Infinoid: can you test rakudo against branch please? | ||
| Infinoid | will do | ||
| bacek | Infinoid: thanks | 00:10 | |
| jonathan -> bed, night all | |||
|
00:12
allison joined
|
|||
| Infinoid | msg bacek I'm getting the same errors building rakudo against the tt452 branch after you merged trunk changes into branch. | 00:15 | |
| purl | Message for bacek stored. | ||
| bacek | OH HAI. | 00:16 | |
| realclean required after merge. There is new "hll_new" op added | 00:17 | ||
| Infinoid | Did that, no change | 00:20 | |
| dalek | rrot: r39072 | bacek++ | branches/tt452_reduce_mmd (110 files): Merge branch 'master' into tt452_reduce_mmd_local \tsrc/pmc/complex.pmc \tsrc/pmc/scalar.pmc |
||
| Infinoid | it's barfing on lines like: $P0 = root_new ['parrot';'Perl6Scalar'], self | 00:23 | |
| the error is: error:imcc:syntax error, unexpected '[', expecting '(' ('[') | |||
| dalek | rrot: r39073 | chromatic++ | trunk/docs/book/ch06_nqp.pod: [book] Edited NQP chapter. It needs review and expansion. |
||
| bacek | Infinoid: did you make realclean in Rakudo as well? It works on my box... | 00:24 | |
| Infinoid | yes, I realcleaned and rebuilt both | ||
| bacek | strange... | ||
| purl | strange is but true | ||
| Infinoid | how are you doing this on your box? | ||
| Infinoid is configuring rakudo with: perl Configure.pl --parrot-config=../tt452_reduce_mmd/parrot_config | |||
| dalek | cnum-dynpmcs: r54 | darbelo++ | trunk/t/rounding_mode.t: Update tests for the DecContext -> DecNumContext rename. |
||
| bacek | Infinoid: similar... | 00:25 | |
| purl | similar are immensely useful | ||
| Infinoid | ok. | ||
| bacek | ok. | ||
| Infinoid checks to see if he has an installed parrot | |||
| bacek | Gotta go. See you. | ||
| Infinoid | ok, seeya | ||
| dalek | cnum-dynpmcs: r55 | darbelo++ | trunk/ (2 files): This should be the last DecContext -> DecNumContext renames. |
00:49 | |
|
01:24
eternaleye joined
01:28
cotto joined
01:59
Eevee joined
02:16
Coke joined
|
|||
| Coke | Whiteknight: ping. | 02:18 | |
| Whiteknight | Coke: pong | 02:19 | |
| Coke | is that branch baked for testing? =-) | ||
| Whiteknight | nope, not yet | 02:21 | |
| it's turning out to be more frustrating of a problem then I thought | |||
| Infinoid | is it a matter of figuring out how rakudo did it? :) | 02:25 | |
| Whiteknight | did rakudo do it? | 02:26 | |
| and what is "it" here? | 02:27 | ||
| Infinoid | undef assignment, or Ref avoidance, or whatever. | ||
| I don't know nearly as much about PMC stuff as you. I'm just offering to look for more needles | |||
| Whiteknight | I think we have the method figured out, it's just implementing it that's a pain | 02:28 | |
| but I'll get it | |||
| until then, I think I'll get some sleep. Goodnight | |||
| Infinoid | sleep well! | ||
|
02:36
janus joined
|
|||
| Coke | this is tcl's big blocker; I appreciate you looking at it. | 02:41 | |
| dalek | rrot: r39074 | jkeenan++ | trunk/src/pmc/filehandle.pmc: Silence one flaky c_indent coding standard failure. |
03:25 | |
| cotto | Is partcl down to one blocker? | 03:34 | |
| Coke++ for keeping with it | 03:35 | ||
|
04:22
mikehh joined
|
|||
| Infinoid | NotFound: I've just packed up my win32 box (I'm moving to another apartment) so I won't be able to work on win32 filehandle/pipe stuff this weekend | 04:30 | |
|
04:44
Theory joined
04:54
tetragon joined
05:01
cognominal joined
|
|||
| dalek | TT #698 closed by Infinoid++: [PATCH] Mac OS X build fix | 05:52 | |
|
06:18
flh joined
07:18
iblechbot joined
08:08
bsdz joined
08:33
flh joined
09:28
santhalus joined
10:17
cognominal joined
10:21
skids joined
10:23
flh joined
|
|||
| dalek | rrot: r39075 | chromatic++ | trunk/src/pmc/unmanagedstruct.pmc: [PMC] Removed a memory leak in UnManagedStruct PMC. |
10:31 | |
|
10:32
Whiteknight joined
10:35
NotFound joined
|
|||
| dalek | rrot: r39076 | chromatic++ | trunk/src/vtables.c: [vtables] Removed a memory leak of the default PMC's cloned VTABLE. This initialization branch merged. |
10:41 | |
| rrot: r39077 | chromatic++ | trunk/src/gc/alloc_register.c: [GC] Plugged a memory leak of the initial context allocated; its reference workaround and slightly ugly, but context reference counting is on the axe list. |
11:08 | ||
| rrot: r39078 | chromatic++ | trunk/src/pmc/parrotinterpreter.pmc: [PMC] Removed a memory leak of the ParrotInterpreter PMC's attributes. |
11:14 | ||
| Whiteknight | go chromatic go! | 11:16 | |
| dalek | rrot: r39079 | NotFound++ | trunk/src/io/win32.c: [pio] call Parrot_io_open_pipe_win32 from Parrot_io_open_win32 (just a first step towards TT #661 in win32) |
11:21 | |
| rrot: r39080 | chromatic++ | trunk/src/pmc/string.pmc: [PMC] Plugged a memory leak related to the constant STRING contained in a bytecode. Hopefully this doesn't make inheriting from the String PMC problematic -- if there are any problems with HLLs and bytecode, this commit is a likely culprit. Parrot now leaks no memory for "Hello, world!" written in PIR as well as PBC. |
|||
| jonathan | Nice! :-) | 11:22 | |
| Whiteknight | very nice indeed | 11:23 | |
| NotFound | Finally I installed strawberry perl to try to somw win32 work | ||
| jonathan | Now if only we could work out why Rakudo leaks ~80MB of memory in the 10,000 sub dispatches benchmark... | 11:27 | |
| dalek | rrot: r39081 | whiteknight++ | branches/tt_696 (7 files): [tt_696] Success...ish. The main scaffolding logic is here to make this operation work, and we no longer get the error that we were once getting. We do get another error about set_pmc not being implemented in the test class, which (a quick inspection shows) is true. |
11:28 | |
| rrot: r39082 | whiteknight++ | branches/tt_696/src (2 files): [tt_696] Rearrange some things. the flags field in pmc_reuse_by_class is no longer a shim. Move Parrot_oo_clone_object out of pmc_reuse_by_class, and into Parrot_Undef_set_pmc where it belongs. Refactor some stuff. The test case now works perfectly |
11:38 | ||
| Whiteknight | holycrap, make nqp_test is absolutely exploding in my branch | 11:39 | |
| actually, a lot of tests are failing | 11:43 | ||
| jonathan has a crack at whipping out a possible optimization | 11:56 | ||
|
12:06
Theory joined
|
|||
| jonathan | Wow. I did a fairly notable change to object guts and only failed one test. :-) | 12:22 | |
| Ah, and I've got a good idea why... | 12:23 | ||
|
12:23
bacek joined
|
|||
| nopaste | "jonathan" at 85.216.157.73 pasted "probable performance and memory usage improvement" (189 lines) at nopaste.snit.ch/16647 | 12:24 | |
| jonathan | If anyone wants to try / take a look at this patch, please do. | ||
| bacek | good evening | ||
| jonathan | Basically, at the moment when we allocate an Object PMC we also allocate an RPA for the storage. | 12:25 | |
| That means every object we instantiate = 2 PMCs. | |||
| In the patch I just use a C array instead, which for heavily OO code means that probably something towards half the number of PMCs will be hanging around. | 12:26 | ||
| It also means that we get to skip one vtable calls on every attribute get/set. | |||
| bacek: oh hai :-) | 12:27 | ||
| bacek | jonathan: hi :) | ||
| jonathan: I don't think that your patch will give much performance boost... | 12:30 | ||
| jonathan | bacek: Possibly not; I figured it's worth a try though. | 12:32 | |
| bacek: It's not going to make much difference for code not doing a lot of OO stuff. | 12:33 | ||
| bacek | indeed. And it's not so much improvement comparing to single MULTI method call... | 12:34 | |
| jonathan | bacek: The thing is, Rakudo does create an awful lot of Objects. | 12:35 | |
| Yes, I think your MULTI optimizations will make a more noticable difference than this. :-) | 12:36 | ||
| bacek | jonathan: let's improve GC! Something like "Generational Incremental Bloody-Fast GC" will help | ||
| jonathan: I've got some weird test failure in Rakudo on my branch... | |||
| jonathan | bacek: In the sanity tests or spectests? | 12:37 | |
| bacek | spectest | ||
| purl | hmmm... spectest is only helpful for people hacking on partcl at this point, i think. | ||
| bacek | bacek@icering:~/src/rakudo$ ./perl6 t/spec/S12-methods/parallel-dispatch.t | 12:38 | |
| 1..21 | |||
| ok 1 - object sanity test | |||
| Cannot assign to readonly variable. | |||
| in method Foo::doit (t/spec/S12-methods/parallel-dispatch.t:12) | |||
| called from Main (t/spec/S12-methods/parallel-dispatch.t:22) | |||
| bacek@icering:~/src/rakudo$ | |||
| This latest rakudo... | 12:40 | ||
|
12:40
rg1 joined,
ZuLuuuuuu joined
|
|||
| Whiteknight | Coke: ping | 12:44 | |
| purl msg Coke the tt_696 branch is ready for testing. Needs cleanup before merging to trunk, but it should do what you want | |||
| purl | Message for coke stored. | ||
| dalek | rrot: r39083 | whiteknight++ | branches/tt_696 (2 files): [tt_696] welcome to Whiteknight's school of programming hard knocks. Today we're learning about how using an uninitialized variable causes unpredictable behavior and test failures. All tests pass now |
12:45 | |
| bacek | Whiteknight++ # excellent commit messages :) | 12:46 | |
| Whiteknight | bacek: This is what happens when I program too early in the morning | 12:47 | |
| bacek | clock? | ||
| purl | bacek: LAX: Sat 5:47am PDT / CHI: Sat 7:47am CDT / NYC: Sat 8:47am EDT / LON: Sat 1:47pm BST / BER: Sat 2:47pm CEST / IND: Sat 6:17pm IST / TOK: Sat 9:47pm JST / SYD: Sat 10:47pm EST / | ||
| bacek | Whiteknight: look! It's late night already! | 12:48 | |
| Whiteknight | bacek, where do you live? | 12:52 | |
| bacek | Whiteknight: Sydney | ||
| Whiteknight | yeah, I'm at EDT here | ||
| bacek waves from future | 12:53 | ||
| Infinoid | good morning from PDT :) | ||
| bacek | Infinoid: 6 _AM_??? | 12:55 | |
| bacek can't believe that such time exists | 12:56 | ||
| Infinoid | heh | 12:57 | |
| Whiteknight | My wife's wonderful dog had me awake at 6am | 13:03 | |
| I was thrilled about that | |||
| </sarcasm> | |||
| dalek | rrot: r39084 | whiteknight++ | branches/tt_696/src (3 files): [tt_696] now passes all codingstd tests, at least the ones that weren't failing before I branched |
13:06 | |
|
13:23
ilbot2 joined
|
|||
| moderator | Parrot 1.2.0 released | parrot.org/ | 305 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets | ||
| bacek | Infinoid: did you manage to build rakudo against tt452 branch? | 13:25 | |
| Infinoid | I just retried now, and it seems I didn't get the merge update before | 13:27 | |
| (funny, I thought I had, but svn doesn't lie) | |||
| it is working now, and I'm doing some benchmarks | |||
| rakudo on trunk: make 160.14s user 4.97s system 85% cpu 3:13.65 total | 13:28 | ||
| rakudo on tt452: make 137.51s user 5.25s system 89% cpu 2:39.53 total | |||
| rakudo on trunk: make test 59.66s user 3.89s system 86% cpu 1:13.23 total | |||
| rakudo on tt452: make test 51.49s user 3.54s system 94% cpu 58.263 total | |||
| (that's trunk at the point of the merge, it doesn't contain changes from the last 10 hours) | |||
| bacek | looks good :) | 13:29 | |
| jonathan | I'll take that! ;-) | ||
|
13:30
santhalus joined
|
|||
| bacek | something like 20% of speed up | 13:30 | |
| If no-one complain I'll merge it into trunk tomorrow night. | 13:31 | ||
| jonathan | Provided it handles make spectest on Rakudo, I'm happy. :-) | 13:32 | |
| Infinoid tests that | |||
| bacek | Better to ask for ex... Oh wait :) | ||
| It's failing on spectest. | 13:33 | ||
| Infinoid | trunk fails spectest for me too (or at least it always has) | ||
|
13:33
kid51 joined,
Theory joined
|
|||
| bacek | Infinoid: Complex.log10? | 13:34 | |
| Infinoid | I dunno, I'm testing tt452 first because I already had that configured | ||
| bacek | Ok. I launched spectest on trunk | ||
| Infinoid | I'll post my results when I've done them both, but it will take a while | ||
| bacek | 2 hours at least... | 13:35 | |
| We have to speed-up parrot little bit. Something like 10-fold | |||
| Infinoid imagines a parrot with a spoiler and an afterburner | 13:36 | ||
| turbo V8 parrot | 13:37 | ||
| feathers flying everywhere | |||
| (but the GC cleans them up) | |||
| bacek | GC isn't a big problem now. PCC is... | 13:38 | |
| Whiteknight | yeah, PCC is at the top of the priority list | 13:44 | |
| dalek | rrot: r39086 | NotFound++ | trunk (2 files): [pio] Implement pipe read for win32, TT #661 |
||
| NotFound | Hey, I still remember how to program win32 | 13:46 | |
| bacek | Wow! :) | 13:47 | |
| Heh. Looks like rakudo's spectest failing in tt452 branch because it produces correct results now... | 13:54 | ||
| NotFound | Strawberry perl is great, I didn't expect that setting a parrot development environment was so easy :) | 13:58 | |
| Infinoid | indeed, strawberry perl rocks | ||
| I tend to add gdb from msys to it, but it's got a lot of the pieces there by default and they Just Work | 13:59 | ||
| NotFound | Installing msys takes much more time... at least last time I've do it | ||
| Infinoid | yes... fortunately gdb is in a separate tarball and you can unpack it onto strawberry directly | 14:00 | |
| for judging the merits of strawberry perl, my reference point is my past experience with cygwin... which probably isn't a fair comparison | 14:01 | ||
| weekend_Coke | Infinoid: I've made no effort to build against a build dir, just an installed dir. Like you'd theoretically find "in the wild." | 14:03 | |
| msg Whiteknight thanks, will test later. | |||
| purl | Message for whiteknight stored. | ||
| Infinoid | ok. I can't wait until all the HLLs can deal with installed and local parrots equally well :) | 14:04 | |
| Whiteknight | weekend_Coke: I'm actually about to merge into trunk, so you can test it there | 14:05 | |
| weekend_Coke | ok. see you later. | 14:06 | |
| nopaste | "Infinoid" at 75.31.91.96 pasted "rakudo spectest failures on tt452 (on my linux/x86-64 box)" (13 lines) at nopaste.snit.ch/16648 | 14:07 | |
| bacek | Infinoid: same on my box. Looks like it was false positive passed tests. (At lease for S32/log) | 14:08 | |
| Infinoid testing trunk now | 14:09 | ||
| bacek | Infinoid: it passing on trunk | ||
| Infinoid | ok | 14:10 | |
| this will take another half an hour to complete... back later | |||