|
Parrot 5.4.0 "Austin Parrot" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 1 June 2013. |
|||
|
03:21
preflex_ joined
04:26
Psyche^ joined
05:02
zby_home joined
06:11
denisboyun_ joined
08:10
bouncy joined
08:24
sivoais joined
10:52
denisboyun_ joined
11:12
sri joined
11:16
denisboyun_ joined
11:45
denisboyun_ joined
12:56
rurban joined
13:26
woosley joined
14:01
darbelo joined
14:33
kid51 joined
14:37
rurban joined
14:40
denisboyun_ joined
14:50
woosley1 joined
15:00
rurban joined
15:14
TonyC joined,
denisboyun_ joined
15:19
sivoais joined
15:48
woosley1 left
15:52
benabik joined
15:54
benabik joined
|
|||
| benabik | ~~ | 15:57 | |
|
16:06
rurban joined
16:25
zby_home joined
16:26
woosley joined
16:28
pjcj joined
16:29
zby_home joined
16:30
PerlJam joined
16:53
sivoais joined
16:56
kid51 joined,
rurban joined
17:02
rurban joined
17:14
rurban1 joined,
rurban1 left
17:34
PacoAir joined
18:19
denisboyun_ joined
18:40
contingencyplan joined
18:46
darbelo joined
|
|||
| dalek | kudo/nom: 6495a5c | jonathan++ | README: Add some basic JVM build instructions. |
18:48 | |
| kudo/nom: 2975f0b | pmichaud++ | README: Add another note to README. |
19:17 | ||
|
19:25
kid51 joined
|
|||
| benabik | I was tracking down an assertion failure building NQP and it went away while I was bisecting. Grump. | 19:34 | |
|
19:51
denisboyun joined
20:07
timo_ joined
|
|||
| timo_ | good day parroters | 20:07 | |
| 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:08 | ||
| 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 | ||
| (this is rakudo's CORE.setting.pbc) | |||
| same for nqp's core setting | 20:10 | ||
| benabik | Arg, for a working disassembler. | 20:12 | |
| timo_: And idea what those null bytes are from? | 20:13 | ||
| timo_ | no. | ||
|
20:14
darbelo joined
|
|||
| timo_ | probably lots of "let's have a 32 bit integer and store numbers between 0 and 1024 in them!" | 20:14 | |
| 64 bit integers, actually! | |||
| benabik | Wow, PACT has severely bitrotted. :-( | 20:16 | |
| 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:26 | ||
| timo_ | oh, that would be sweet! | 20:29 | |
| wouldn't it also improve startup speed a bit? | |||
| (well, maybe not on an SSD like i have) | |||
| benabik | Trading drive for CPU... Maybe? | ||
| timo_ | i'm currently investigating deploying rakudo no parrot to heroku and install/lib is like 40 megabytes big | 20:30 | |
|
20:30
alester joined
|
|||
| benabik | So we have GzipHandle, and a function that reads a PBC file from a handle. | 20:39 | |
| 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. | ||
| But, yeah. | |||
| timo_ | great, LHF ;) | ||
| 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:41 | |
| 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
|
|||
| 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 | |
| but it turned down to 1.7M, from 17M | |||
| that's a very good result, IMO. | |||
| benabik | And gunzip is generally much faster than gzip. | ||
| timo_ | indeed it is | 20:44 | |
| let me give you the timing | |||
| 0.12user 0.01system 0:00.14elapsed 99%CPU (0avgtext+0avgdata 1496maxresident)k | |||
| 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. | ||
| 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:47 | |
| timo_ | :( | 20:48 | |
| Coke | well, it would be a lot of work for me, anyway. | ||
| timo_ | if it's just a few minutes of work, it could be tried at least | 20:49 | |
| 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 | |
| Although I wonder if that's caused by line number annotations. :-/ | |||
| timo_ | oh, that's a good point. that may very well be the case | 20:51 | |
| however | |||
| when looking at the hexdump, it's literally hundreds of screenfuls of one column data, three columns zeros | |||
| 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 | ||
| 004b800: 0800 0100 0000 0000 e1ff ffff ffff ffff ................ | |||
| 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. | ||
| benabik | Right. | 20:55 | |
| Sadly, I can't get any of my disassemblers to parse the setting.pbcs :-( | |||
| pbc_{dump,disassemble} are literally doing nothing while PACT's disasm.winxed is segfaulting while loading the bytecode. | 20:56 | ||
|
21:10
perlite joined
|
|||
| 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 | |
|
21:15
kid51 joined
|
|||
| 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:17 | |
| timo_ | hm. | 21:18 | |
| 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. | ||
| 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? | ||
| benabik | I wonder if having the entire thing be pointer aligned is actually useful anymore. | ||
| Right. | |||
| timo_ | and those "piles of capital letter As" is serialised objects from the perl6 World? | 21:23 | |
| benabik | nqp_deserialize_sc "BQAAAEAAAACAAAAUAAAA | ||
| Lots of A and / | 21:24 | ||
| timo_ | yeah, deserialize. | ||
| 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
|
|||
| benabik | Hm. I think GzipHandle is missing something for the new io system. :-/ | 22:12 | |
| timo_ | that's a bummer :( | ||
| benabik | nvm, it just doesn't implement the method Iw as trying to use. | 22:14 | |
| 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:17 | ||
| dalek | rrot/benabik/pbc_gz: 81b3324 | benabik++ | frontend/parrot2/prt0. (2 files): Teach prt0 about .pbc.gz files Now you can do things like `parrot test.pbc.gz` and have it work. Won't help for the NQP/Rakudo setting files I was considering at first because it doesn't affect loading library files. Oops. |
22:21 | |
| timo_ | is that even more additional work? | ||
| benabik | Yeah, and pretty much all C level. :-/ | ||
| timo_ | aaw :( | 22:22 | |
|
22:28
sri left
|
|||
| benabik | I can see what all to do, although it involves integrating gzip much deeper into Parrot than I had hoped. | 22:31 | |
| timo_ | just dlopen it when you need it! :P | 22:32 | |
| 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 | |||
| darbelo | After my absence, I'm starting to think that we should stop writing C in parrot. | 22:34 | |
| 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 | |
| darbelo: stop writing C in parrot meaning? | |||
| 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. | ||
| PackfileViews and prt0 and the like. | 22:37 | ||
| darbelo | Yeah, that is the kind of thing I'm talking about. | ||
| Only more of it :) | |||
| benabik | Yeah. | 22:39 | |
| In this particular case, I'd need to alter the way opcodes work, and we can't currently write those in-VM. | |||
| 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:40 | |
|
22:42
rurban1 joined
|
|||
| benabik | My list of "how would I change parrot given my current knowledge" ends up looking extremely similar to MoarVM. :-/ | 22:42 | |
| darbelo | I suppose I'll sort it out when I finish the time machine... | 22:43 | |
| masak .oO( will have been *being* sorting it out... ) :P | 22:49 | ||
|
23:35
rurban joined
23:41
benabik joined
23:50
myhrlin_ joined
|
|||