Camelia, the Perl 6 bug

IRC log for #parrot, 2013-06-04

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
03:21 preflex_ joined #parrot
04:26 Psyche^ joined #parrot
05:02 zby_home joined #parrot
06:11 denisboyun_ joined #parrot
08:10 bouncy joined #parrot
08:24 sivoais joined #parrot
10:52 denisboyun_ joined #parrot
11:12 sri joined #parrot
11:16 denisboyun_ joined #parrot
11:45 denisboyun_ joined #parrot
12:56 rurban joined #parrot
13:26 woosley joined #parrot
14:01 darbelo joined #parrot
14:33 kid51 joined #parrot
14:37 rurban joined #parrot
14:40 denisboyun_ joined #parrot
14:50 woosley1 joined #parrot
15:00 rurban joined #parrot
15:14 TonyC joined #parrot
15:14 denisboyun_ joined #parrot
15:19 sivoais joined #parrot
15:48 woosley1 left #parrot
15:52 benabik joined #parrot
15:54 benabik joined #parrot
15:57 benabik ~~
16:06 rurban joined #parrot
16:25 zby_home joined #parrot
16:26 woosley joined #parrot
16:28 pjcj joined #parrot
16:29 zby_home joined #parrot
16:30 PerlJam joined #parrot
16:53 sivoais joined #parrot
16:56 kid51 joined #parrot
16:56 rurban joined #parrot
17:02 rurban joined #parrot
17:14 rurban1 joined #parrot
17:14 rurban1 left #parrot
17:34 PacoAir joined #parrot
18:19 denisboyun_ joined #parrot
18:40 contingencyplan joined #parrot
18:46 darbelo joined #parrot
18:48 dalek rakudo/nom: 6495a5c | jonathan++ | README:
18:48 dalek rakudo/nom: Add some basic JVM build instructions.
18:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6495a5cb04
19:17 dalek rakudo/nom: 2975f0b | pmichaud++ | README:
19:17 dalek rakudo/nom: Add another note to README.
19:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2975f0b9f9
19:25 kid51 joined #parrot
19:34 benabik I was tracking down an assertion failure building NQP and it went away while I was bisecting.  Grump.
19:51 denisboyun joined #parrot
20:07 timo_ joined #parrot
20:07 timo_ good day parroters
20:08 timo_ i just had a quick look into the install/ folder and it seems the .pbc files could seriously benefit from a bit of compression
20:09 timo_ just the simplest of compressions could probably cut it down to 1/4th of its size, since it's mostly nullbytes, like this: 0003340: 0200 0000 0000 0000 b403 0000 0000 0000  ................
20:09 timo_ (this is rakudo's CORE.setting.pbc)
20:10 timo_ same for nqp's core setting
20:12 benabik Arg, for a working disassembler.
20:13 benabik timo_: And idea what those null bytes are from?
20:13 timo_ no.
20:14 darbelo joined #parrot
20:14 timo_ probably lots of "let's have a 32 bit integer and store numbers between 0 and 1024 in them!"
20:14 timo_ 64 bit integers, actually!
20:16 benabik Wow, PACT has severely bitrotted.  :-(
20:26 benabik We appear to have most of the infrastructure to connect to gzip for a GZipHandle PMC...  I wonder how hard it would be to wire up .pbc.gz
20:29 timo_ oh, that would be sweet!
20:29 timo_ wouldn't it also improve startup speed a bit?
20:29 timo_ (well, maybe not on an SSD like i have)
20:29 benabik Trading drive for CPU...  Maybe?
20:30 timo_ i'm currently investigating deploying rakudo no parrot to heroku and install/lib is like 40 megabytes big
20:30 alester joined #parrot
20:39 benabik So we have GzipHandle, and a function that reads a PBC file from a handle.
20:40 timo_ are you saying all that's needed is "is there a .pbc.gz? if so, create a GZipHandle"?
20:40 benabik Also need to expose the "read PBC from handle" to Parrot-land from C-land.
20:40 benabik But, yeah.
20:40 timo_ great, LHF ;)
20:41 benabik 1) expose src/packfile/api.c:read_pbc_file_packfile_handle via src/pmc/packfileview.pmc.  2) Call new packfileview method from prt0.winxed with a GzipHandle.
20:42 Coke what if there's a .pbc and a .pbc.gz ?
20:42 benabik We would probably want to prefer the .pbc, since we use mmap when available.
20:42 denisboyun_ joined #parrot
20:43 timo_ gzip -9 CORE.setting.pbc  7.25s user 0.02s system 99% cpu 7.293 total - i wonder if it's worth it.
20:43 timo_ but it turned down to 1.7M, from 17M
20:43 timo_ that's a very good result, IMO.
20:43 benabik And gunzip is generally much faster than gzip.
20:44 timo_ indeed it is
20:44 timo_ let me give you the timing
20:44 timo_ 0.12user 0.01system 0:00.14elapsed 99%CPU (0avgtext+0avgdata 1496maxresident)k
20:45 benabik I don't think the compression is a good idea in the general case, since I'm pretty sure mmapping the .pbc is better.
20:45 timo_ hmm, perhaps.
20:47 Coke I would recommend looking at the bytecode PDD and see if any savings can be had that way... but that's a lot of work.
20:48 timo_ :(
20:48 Coke well, it would be a lot of work for me, anyway.
20:49 timo_ if it's just a few minutes of work, it could be tried at least
20:50 benabik Adding a .pbc.gz handler is probably wiser than trying to redesign the PBC format.  :-D  Especially given that I have a suspicion it's caused by the setting files having large numbers of small integer constants.
20:50 benabik Although I wonder if that's caused by line number annotations.  :-/
20:51 timo_ oh, that's a good point. that may very well be the case
20:51 timo_ however
20:51 timo_ when looking at the hexdump, it's literally hundreds of screenfuls of one column data, three columns zeros
20:52 timo_ when grepping -v '0000 0000 0000', there's a *huge* gap here: 0000190: 725f 414e 4e00 0000 a21f 2000 0000 0000  r_ANN..... .....
20:52 timo_ 004b800: 0800 0100 0000 0000 e1ff ffff ffff ffff  ................
20:54 benabik Ah, good.  Annotations store integer keys in the annotation.
20:54 Coke I'd say finding out what that section is might help diagnose if it's a code generation issue or a true bytecode format issue.
20:55 benabik Right.
20:55 benabik Sadly, I can't get any of my disassemblers to parse the setting.pbcs  :-(
20:56 benabik pbc_{dump,disassemble} are literally doing nothing while PACT's disasm.winxed is segfaulting while loading the bytecode.
21:10 perlite joined #parrot
21:15 timo_ what's the use of mmapping that format if its data isn't readily usable, like i suppose those huge blocks of mostly the capital letter A
21:15 kid51 joined #parrot
21:17 benabik Letting the OS handle reading those pages on demand instead of spending a ton of time dealing with it ourselves.  Also I think it's mmapped read-only so the OS will feel free to page it out without bothering with swap.
21:18 timo_ hm.
21:20 timo_ i wonder why the pbc format doesn't turn the "printable characters only" data into actually usable binary data after it's read from i suppose .pir files
21:20 benabik Oh, blah.  I think the "piles of null" is the bytecode section.
21:22 benabik They're all small integers because they're indexes into the opmap.
21:22 timo_ but they are 64 bit integers, because i have a 64 bit machine?
21:22 benabik I wonder if having the entire thing be pointer aligned is actually useful anymore.
21:22 benabik Right.
21:23 timo_ and those "piles of capital letter As" is serialised objects from the perl6 World?
21:23 benabik nqp_deserialize_sc "BQAAAEAAAACAAAAUAAAA
21:24 benabik Lots of A and /
21:24 timo_ yeah, deserialize.
21:27 benabik Rakudo's CORE.setting has a ~5.8 MB serialization blob.
21:27 timo_ in a very, very unfortunate format, it seems to my untrained eyes
21:41 rurban joined #parrot
22:12 benabik Hm.  I think GzipHandle is missing something for the new io system.  :-/
22:12 timo_ that's a bummer :(
22:14 benabik nvm, it just doesn't implement the method Iw as trying to use.
22:17 benabik Well, I got prt0 to read .pbc.gz files.  But then I realized that won't help at all for the setting files.  Would need to alter the library loading routines instead.
22:21 dalek parrot/benabik/pbc_gz: 81b3324 | benabik++ | frontend/parrot2/prt0. (2 files):
22:21 dalek parrot/benabik/pbc_gz: Teach prt0 about .pbc.gz files
22:21 dalek parrot/benabik/pbc_gz:
22:21 dalek parrot/benabik/pbc_gz: Now you can do things like `parrot test.pbc.gz` and have it work.
22:21 dalek parrot/benabik/pbc_gz: Won't help for the NQP/Rakudo setting files I was considering at first
22:21 dalek parrot/benabik/pbc_gz: because it doesn't affect loading library files.  Oops.
22:21 dalek parrot/benabik/pbc_gz: review: https://github.com/parrot/parrot/commit/81b3324bed
22:21 timo_ is that even more additional work?
22:21 benabik Yeah, and pretty much all C level.  :-/
22:22 timo_ aaw :(
22:28 sri left #parrot
22:31 benabik I can see what all to do, although it involves integrating gzip much deeper into Parrot than I had hoped.
22:32 timo_ just dlopen it when you need it! :P
22:32 timo_ as I said, I was just curious if it would help somewhat, but if it's too much work for such a little curiosity, just drop it
22:34 darbelo After my absence, I'm starting to think that we should stop writing C in parrot.
22:35 benabik I can see where to do it, but I'm not fluent enough with zlib or the internals to just quickly knock out something that would work.
22:35 benabik darbelo: stop writing C in parrot meaning?
22:36 darbelo Stop adding C code to parrot, move the functionality upwards in the stack.
22:36 benabik Whiteknight did a lot of work in that direction.
22:37 benabik PackfileViews and prt0 and the like.
22:37 darbelo Yeah, that is the kind of thing I'm talking about.
22:37 darbelo Only more of it :)
22:39 benabik Yeah.
22:39 benabik In this particular case, I'd need to alter the way opcodes work, and we can't currently write those in-VM.
22:40 darbelo If I could apply my current knowledge to the issues I faced when I wrote the decNumber code, there wouldn't be any C there.
22:42 rurban1 joined #parrot
22:42 benabik My list of "how would I change parrot given my current knowledge" ends up looking extremely similar to MoarVM.  :-/
22:43 darbelo I suppose I'll sort it out when I finish the time machine...
22:49 * masak .oO( will have been *being* sorting it out... ) :P
23:35 rurban joined #parrot
23:41 benabik joined #parrot
23:50 myhrlin_ joined #parrot

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

Parrot | source cross referenced