Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-04-11

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

All times shown according to UTC.

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

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