Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-08-27

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

All times shown according to UTC.

Time Nick Message
05:56 raiph joined #moarvm
06:02 domidumont joined #moarvm
06:04 timotimo so, i'm not getting any rest right now, apparently
06:04 timotimo this idea has been sloshing around in my head:
06:06 timotimo we have this huge frame that does nothing but 1) getcode of some frame, 2) push the result into an array, 3) repeat
06:06 timotimo i wonder if we can't turn that into a "data-driven" loop instead
06:07 domidumont joined #moarvm
06:08 timotimo also, we have another frame that does a phase of getcode, capturelex, repeat; afterwards it does getcode, takeclosure, repeat
06:09 timotimo that could perhaps also partially become a loop, though it seems like it wants to keep all those things in local variables, which makes writing a loop a bit harder
06:10 timotimo another thought i had was perhaps we want to have a "dummy" array that gets deserialized immediately on startup that just contains a big bunch of objects that will get deserialized lazily during regular start-up anyway
06:20 timotimo the first 6700 instructions in the frame called by the "<load>" frame are getcode + capturelex pairs
07:18 konobi joined #moarvm
07:24 krunen joined #moarvm
07:55 edehont joined #moarvm
08:06 timotimo i'd even go so far as to implement a "capturemanylex" op that takes a list of frame indices :P
08:31 timotimo there's a juicy amount of wval ops that have 0 as their first argument in the core setting; about 13k, actually
08:31 timotimo so given each of those takes 2 bytes for wval's first argument, we'd be at about 26 kbytes saved if we had a wval_narrow
08:32 timotimo given the whole thing is 11 megs big, that's not actually noticable, though
08:36 timotimo let's calculate what's with the getcode + capturelex thing, though:
08:38 timotimo m: my $opcount = 6692 div 2; say $opcount * 6 + $opcount * 4, " bytes"
08:38 camelia rakudo-moar 6a8278: OUTPUT«33460 bytes␤»
08:38 timotimo ugh, that'? also next to nothing
08:38 timotimo that's*
08:38 timotimo except that's 33 kBytes the validator won't have to nom its way through
09:25 kjs_ joined #moarvm
10:00 Ven joined #moarvm
11:10 dalek MoarVM: 426b89c | timotimo++ | src/6model/reprs/P6opaque.c:
11:10 dalek MoarVM: don't segfault when serializing an uncomposed p6opaque.
11:10 dalek MoarVM:
11:10 dalek MoarVM: Fixes coverity CID 135427
11:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/426b89ca1a
11:10 timotimo poor dalek :(
11:10 timotimo thanks to [ptc] for letting me into the coverity project
11:10 timotimo and thanks to coverity for a good service
11:11 dalek joined #moarvm
11:12 timotimo "tainted data flows to untainted sink"
11:12 timotimo the way it reckons that is this:
11:12 timotimo we have a filename in our args, which is tainted
11:12 timotimo it goes through decoding via utf8_c8
11:13 timotimo that might want to create a synthetic grapheme for some invalid bytes
11:13 timotimo which accesses directly into the (clearly high-value and top secret) hex_chars array!
11:14 timotimo "unchecked return value" "calling uv_mutex_init without checking return value (as is done elsewhere 23 out of 25 times"
11:14 timotimo that's pretty cool
11:21 timotimo 247    /* Allocate extra gen2 aggregate space if needed. */
11:21 timotimo 248    if (tc->num_gen2roots == tc->alloc_gen2roots) {
11:21 timotimo 249        tc->alloc_gen2roots *= 2;
11:21 timotimo
11:21 timotimo CID 54957 (#1 of 1): Sizeof not portable (SIZEOF_MISMATCH)
11:21 timotimo suspicious_sizeof: Passing argument tc->gen2roots of type MVMCollectable ** and argument 8UL /* sizeof (MVMCollectable **) */ * tc->alloc_gen2roots to function MVM_realloc is suspicious. In this case, sizeof (MVMCollectable **) is equal to sizeof (MVMCollectable *), but this is not a portable assumption.
11:21 timotimo Did you intend to use sizeof (MVMCollectable *) instead of sizeof (MVMCollectable **)?
11:21 timotimo 250        tc->gen2roots = MVM_realloc(tc->gen2roots,
11:21 timotimo 251            sizeof(MVMCollectable **) * tc->alloc_gen2roots);
11:31 dalek MoarVM: c4b689b | timotimo++ | src/6model/reprs/MVMHash.c:
11:31 dalek MoarVM: use HASH_FIND_CACHE instead of HASH_FIND in MVMHash
11:31 dalek MoarVM:
11:31 dalek MoarVM: hopefully improves access speed when keys are used multiple
11:31 dalek MoarVM: times in hashes. a quick measurement of rakudo startup suggests
11:31 dalek MoarVM: that is the case for a big portion of binds at least.
11:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c4b689bdea
11:31 dalek MoarVM: df0bd8c | timotimo++ | src/profiler/heapsnapshot.c:
11:31 dalek MoarVM: fixes accidentally a code before more var declarations
11:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/df0bd8cd59
11:32 travis-ci joined #moarvm
11:32 travis-ci MoarVM build failed. Timo Paulssen 'Mark intention of fallthrough in inline args-kicker.
11:32 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/155560758 https://github.com/MoarVM/MoarVM/compare/edd58392e19d...f47426a2f0e0
11:32 travis-ci left #moarvm
11:34 timotimo took you long enough!
11:34 timotimo how the honk does it compile on OSX with gcc?
11:34 timotimo the answer is:
11:35 timotimo you're dumb. that's not gcc.
11:45 dalek MoarVM: 13fdd83 | timotimo++ | .travis.yml:
11:45 dalek MoarVM: travis doesn't actually have gcc on osx.
11:45 dalek MoarVM:
11:45 dalek MoarVM: we were getting a clang the entire time! *gasp*
11:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/13fdd83c3d
11:51 timotimo it kind of looks like travis is building 2 at a time, so maybe our builds will become a tiny bit faster now?
11:53 timotimo now it's running 4 at the same time
11:53 timotimo i wonder if it'll do 8 at the same time when those 4 have finished?
12:03 Ven joined #moarvm
12:14 travis-ci joined #moarvm
12:14 travis-ci MoarVM build passed. Timo Paulssen 'travis doesn't actually have gcc on osx.
12:14 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/155564685 https://github.com/MoarVM/MoarVM/compare/df0bd8cd5947...13fdd83c3db2
12:14 travis-ci left #moarvm
12:17 JimmyZ ./perl6-m -e 'class A { method b() { 1 }; method a() { my $time = now; for ^5000000 { self.b()} ;  say now - $time; } }; A.new.a' # outputs 2.2
12:18 JimmyZ ./perl6-m -e 'class A { method b() {  }; method a() { my $time = now; for ^5000000 { self.b()} ;  say now - $time; } }; A.new.a' # outputs  7.1
12:20 JimmyZ bare block about 3x slower, for FYI
12:22 JimmyZ ./perl6-m -e 'class A { method b() { return 1 }; method a() { my $time = now; for ^5000000 { self.b()} ;  say now - $time; } }; A.new.a' # outputs 3.3
12:23 jnthn wat, an empty block is slower? o.O :) Can't wait to see the code-gen on this one :P
12:24 jnthn Except I can 'cus my lunch is ready :)
12:24 JimmyZ haha :)
12:24 jnthn But at a guess: we emit a late-bound lexical lookup for Nil, which is not only slow in and of itself, but also prevents inlining, which is where the big difference comes from.
12:25 jnthn We should prolly produce a QAST::WVal instead.
12:25 jnthn anyways, nomming :) &
12:32 JimmyZ change 'method b' to 'sub b' , outputs 0.97
12:33 JimmyZ and sub b {} empty block is 0.97 too
12:35 JimmyZ so , method call is about 2x slower than sub call
16:03 domidumont joined #moarvm
16:21 domidumont joined #moarvm
16:46 Ven joined #moarvm
19:32 domidumont joined #moarvm
19:50 dalek MoarVM: 718339d | timotimo++ | src/profiler/heapsnapshot.c:
19:50 dalek MoarVM: heapsnapshot: Also free annotation when leaving function early
19:50 dalek MoarVM:
19:50 dalek MoarVM: Finally fixes Coverity CID 135433
19:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/718339d15c
19:54 Ven joined #moarvm
20:39 Ven joined #moarvm
20:50 Ven joined #moarvm
21:22 jnthn coverity++ timotimo++
21:50 vendethiel joined #moarvm
22:15 timotimo just a few very cheap things unlikely to ever be noticable
22:15 timotimo any thoughts on my ridiculous ideas for startup speedup?
22:16 timotimo we also have a bunch of things that have sink called on them from the mainline i expect
22:16 timotimo not sure if thwt's worth anything
22:17 timotimo also i should resurrext that logging that shows exactly what is being demanded from the sc
22:18 timotimo maybe zheres some "thats dumb" stuff where we demand atuff be deserialized just to go ignored for most use cases
22:19 vendethiel timotimo: you ran a static analyzer on moarvm?
22:20 timotimo yes, ptc owns a coverity thingie for moar
22:20 timotimo we could make an official one, too
22:22 timotimo go find it, sign in with github, request to be added to the project
22:22 timotimo help triage defects
22:22 timotimo we dont have terribl many
22:26 arnsholt clang-static found a pile of stuff as well, not sure how many of them were real things though
22:26 timotimo i should have made precise measurements for having the hash stuff with the cache vs without
22:29 timotimo i caused some explosions when i tried to make extract key dependent on whether there is a cached hash code already
22:31 timotimo its probably not so expensive for most cases during startup, like most strings are likely not ropesy
22:32 timotimo there's no way i'll find 50% start up time improvement with this ... texhnique
22:34 timotimo and a 2x factor would sure be nice
22:50 timotimo without that 2x factor, fuzzing rakudo with p6 code in strings is going to be 100% unhelpful
23:03 Ven joined #moarvm

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