|
01:15
colomon joined
01:27
vendethiel joined
01:47
ilbot3 joined
02:35
FROGGS joined
04:04
FROGGS_ joined
07:42
vendethiel joined
|
|||
| dalek | arVM: 5b63ded | nicholas++ | src/6model/ (2 files): Bump minimum serialization format version. Now that we've rebootstrapped, we no longer need the code to read older serialization versions. Mostly a lot of removal of if statements with ...->root.version checks, and re-indenting because of the blocks this eliminates. |
08:30 | |
| jnthn | Well, that's one off the review list :) | ||
|
08:59
vendethiel joined
09:14
vendethiel- joined
|
|||
| timotimo | yay | 11:52 | |
| nwc10 | jnthn++ | 13:17 | |
| jnthn: I was experimenting with inlining some more (small static) functions and the numbers were noise | |||
| so I went digging | |||
| turns out that at -O2 *gcc* has already inlined them, because (the Internet says) it will at -O2, if $heuristics and the code size does not increase | 13:18 | ||
| (-O3 gets aggresive and inlines even if code size encreases) | |||
| there's more to the world than gcc, but I wasn't sure if it's worth the complexity of churning the codebase, as I assume that at least some other compilers will consider it | 13:19 | ||
|
15:06
zakharyas joined
|
|||
| nwc10 | jnthn: do you want the bad news or the good news? :-) | 15:35 | |
| OK, the bad news is 3 more commits to review. | 15:44 | ||
| timotimo | i'd like the good news now, please | 15:45 | |
| nwc10 | (the others you hadn't yet had time for got rebased onto master) | ||
| timotimo | oh, i think the time on this device is quite off | ||
| nwc10 | so when is the "now" of which you speak? :-) | ||
| timotimo | well, i looked at your message and then at my clock | 15:46 | |
| they were 6 minutes apar | |||
| apart | |||
| nwc10 | aha | ||
| timotimo | so i thought you were waiting for someone to ask you to go on | ||
| nwc10 | on "my" machine CORE.setting.moarvm is 11503882 bytes. | ||
| timotimo | if we optimize our stuff much further, it'll end up fitting on a floppy disk | 15:47 | |
| nwc10 | I was going to suggest that this was doubtful | 15:48 | |
| but xz can compress CORE.setting.moarvm to 1.2M | |||
| timotimo | then you remembered there's microfilm? ;) | ||
| neato | 15:49 | ||
| i believe we have lots and lots and lots and lots of zeroes in there | |||
| nwc10 | I know where some are. I have a plan to reduce them. | ||
| timotimo | i'd wager we have about 50% zero bytes | ||
| nwc10 | please write JITs, because I'm not good at that :-) | ||
| we can probably measure the count and therefore proportion of zero bytes | 15:50 | ||
| timotimo | on my machine the core setting moarvm file is 4216599 bytes perhaps? | ||
| m: say 11503882 / 4216599 | |||
| camelia | rakudo-moar 0b2092: OUTPUTĀ«2.72823714ā¤Ā» | ||
| timotimo | so ... you made it more than 2x as big? | 15:51 | |
| haha | |||
| the moarvm file starts with something like | |||
| BA BA BA BA BAA BA BA BAA BA BA BAAA | |||
| 00e8010: 0700 0800 0800 0800 0800 0800 0800 0800 ................ | 15:53 | ||
| 00e8020: 0400 0800 0800 0800 0800 0800 0800 0800 ................ | |||
| well, why not! | |||
| %) | |||
| i think we might get a bit of a size decrease if we change the way our cuids look | 15:54 | ||
| all we need for them is to be unique and perhaps even recognizable as a cuid | 15:55 | ||
| but "cuid_4131_1428658493.36412" is rather wasteful, IMO | |||
| scrolling through the xxd of the core setting moarvm file there's pages and pages and pages and pages of cuids | 15:56 | ||
| i wonder where the multiple copies of 01234567890ABCDEFG......XYZabcdefgh.......xyza... come from ... no, actually i know where they come from | 15:59 | ||
| that must be our magic for SEQUENCE | |||
| that'd be why it has a 0 at the end *and* beginning | |||
| as well as the a after the z | |||
| jnthn | We might consider doing a bump to -O3 if all looks good with it. | 16:11 | |
| nwc10 | jnthn: the 3 commits on my nqp master might be much easier to review | 16:13 | |
| they also act as tests for the other stuff | |||
| jnthn | I sometimes wonder if we can do better than memcpy | 16:16 | |
| (for reading stuff) | |||
| nwc10 | I'm not sure. I think one would need to look at the assembler generated by >3 compilers on >2 architectures | 16:17 | |
| to see how good they are at figuring out what is "constant" and putting something decent inline | |||
| IIRC looking at the Linux headers, gcc provides enough __builtin_backdoor_foo to permit at least some things to be replaced with "oh, I know that it's 4 bytes" and a suitable bit of inline code | 16:18 | ||
| dalek | arVM: 003f918 | nicholas++ | src/6model/serialization.c: Deserialization code for a new varint serialization format. Firstly, just add the new deserialisation code, to verify that we can still read v13 format correctly. b544b27 | nicholas++ | src/core/validation.c: In validation.c, inline get_info() and read_op() These are called frequently, and inlining them reduces startup CPU usage by about 0.4% |
16:20 | |
| jnthn | That was 4 more :) | 16:21 | |
|
16:21
dalek joined
|
|||
| jnthn | (3 for new varint format, 1 for toss vtable thing) | 16:21 | |
| TimToady | nqp-j is build fail, possibly with a deserialization issue (something in nqp assuming moar-only?) | 16:22 | |
| jnthn | Hm, none of the stuff I've been merging is in NQP, oly Moar... | ||
| TimToady | I dint say it was yer falt | 16:23 | |
| nwc10 | just that he gets to fix it :-) | ||
| TimToady | that were implicated, aye | 16:24 | |
| jnthn | the only JVM things that changed recently were about the '0' thing | ||
| nwc10 | oh | 16:25 | |
| TimToady | see recent #perl6 | ||
| jnthn | nwc10: Where lives your NQP repo? | 16:35 | |
| arVM: 72a9fff | nicholas++ | src/6model/6model.h: Re-order struct MVMCollectable to slightly reduce L1 cache misses. For "Hello World" cachegrind measures the D1 miss rate as dropping from 2.584% to 2.580% (but the LL cache misses increase slightly). |
|||
| jnthn | I'll look at the rest, and nqp-j, either after dinner or tomorrow morning (got all day for Perl 6 things tomorrow) | 16:39 | |
| And enjoyed the nice-enough-to-eat-outside weather sufficiently much the last couple of days I won't mind hiding from the day star to hack :) | 16:40 | ||
| nwc10 | jnthn: gitlab.com/nwc10/nqp.git (if you'd not figured that out) | 16:44 | |
| jnthn | I was doing lazy rather than figuring | 16:45 | |
| Anyway, fetched it. But...rly dinner & | 16:50 | ||
|
17:06
colomon joined,
dalek joined
|
|||
| timotimo | 227834 ā that's how many bytes are cuid_* strings in CORE.setting.moarvm | 21:00 | |
| a quarter meg | |||
| not terribly much, and it can't be reduced down to 0 | 21:02 | ||
| but maybe it'd be interesting to have a little look | |||
| i think i ought to have a look at the devirt reprops branch again | 21:03 | ||
|
21:11
vendethiel joined
|
|||
| timotimo | i may be able to fix it today | 21:37 | |
| oh hooray, back to segfault instead of backtrace | 21:38 | ||
| there were quite a few problems with the code | 21:49 | ||
| i'm going through an nqp build now | |||
| it may work this time | |||
| turned out that both pop and push were looking at the wrong operand for "known type" | |||
| you won't get much type information out of an integer register | 21:50 | ||
| All tests successful. | 21:58 | ||
| ohmygosh | |||
| does that mean i should merge? | |||
| dalek | arVM/jit_devirtualize_reprops_3: d69f832 | timotimo++ | / (85 files): Merge branch 'master' into jit_devirtualize_reprops_3 Conflicts: src/jit/graph.c |
22:15 | |
| arVM/jit_devirtualize_reprops_3: 6409021 | timotimo++ | src/jit/graph.c: sort out the last problems with reprop devirt gets us a fully clean spec test run |
|||
| vendethiel | timotimo++! | 22:19 | |
| timotimo | Files=969, Tests=37293, 867 wallclock secs ( 4.89 usr 1.07 sys + 678.24 cusr 71.08 csys = 755.28 CPU) | 22:34 | |
| Files=969, Tests=37293, 864 wallclock secs ( 4.92 usr 1.02 sys + 675.36 cusr 71.29 csys = 752.59 CPU) | |||
| hardly measurable improvement | 22:35 | ||
| but at least it works | |||
| i wonder if i may/should merge it into master | |||
| throughout the whole rakudo build, i get this at the very top of all devirt outputs: | 22:44 | ||
| 18201 devirt: emitted a push_i via jgb_consume_reprop | |||
| reducing the length of cuids significantly seems like a challenge; they're supposed to be unique across all time | 23:25 | ||