05:56 raiph joined 06:02 domidumont joined
timotimo so, i'm not getting any rest right now, apparently 06:04
this idea has been sloshing around in my head:
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
i wonder if we can't turn that into a "data-driven" loop instead
06:07 domidumont joined
timotimo also, we have another frame that does a phase of getcode, capturelex, repeat; afterwards it does getcode, takeclosure, repeat 06:08
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:09
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:10
the first 6700 instructions in the frame called by the "<load>" frame are getcode + capturelex pairs 06:20
07:18 konobi joined 07:24 krunen joined 07:55 edehont joined
timotimo i'd even go so far as to implement a "capturemanylex" op that takes a list of frame indices :P 08:06
there's a juicy amount of wval ops that have 0 as their first argument in the core setting; about 13k, actually 08:31
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
given the whole thing is 11 megs big, that's not actually noticable, though 08:32
let's calculate what's with the getcode + capturelex thing, though: 08:36
m: my $opcount = 6692 div 2; say $opcount * 6 + $opcount * 4, " bytes" 08:38
camelia rakudo-moar 6a8278: OUTPUTĀ«33460 bytesā¤Ā»
timotimo ugh, that'? also next to nothing
that's*
except that's 33 kBytes the validator won't have to nom its way through
09:25 kjs_ joined 10:00 Ven joined
dalek arVM: 426b89c | timotimo++ | src/6model/reprs/P6opaque.c:
don't segfault when serializing an uncomposed p6opaque.

Fixes coverity CID 135427		 11:10
timotimo poor dalek :(
thanks to [ptc] for letting me into the coverity project
and thanks to coverity for a good service
11:11 dalek joined
timotimo "tainted data flows to untainted sink" 11:12
the way it reckons that is this:
we have a filename in our args, which is tainted
it goes through decoding via utf8_c8
that might want to create a synthetic grapheme for some invalid bytes 11:13
which accesses directly into the (clearly high-value and top secret) hex_chars array!
"unchecked return value" "calling uv_mutex_init without checking return value (as is done elsewhere 23 out of 25 times" 11:14
that's pretty cool
247 /* Allocate extra gen2 aggregate space if needed. */ 11:21
248 if (tc->num_gen2roots == tc->alloc_gen2roots) {
249 tc->alloc_gen2roots *= 2;
CID 54957 (#1 of 1): Sizeof not portable (SIZEOF_MISMATCH)
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.
Did you intend to use sizeof (MVMCollectable *) instead of sizeof (MVMCollectable **)?
250 tc->gen2roots = MVM_realloc(tc->gen2roots,
251 sizeof(MVMCollectable **) * tc->alloc_gen2roots);
dalek arVM: c4b689b | timotimo++ | src/6model/reprs/MVMHash.c:
use HASH_FIND_CACHE instead of HASH_FIND in MVMHash

hopefully improves access speed when keys are used multiple times in hashes. a quick measurement of rakudo startup suggests that is the case for a big portion of binds at least.		 11:31
arVM: df0bd8c | timotimo++ | src/profiler/heapsnapshot.c:
fixes accidentally a code before more var declarations
11:32 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'Mark intention of fallthrough in inline args-kicker. 11:32
travis-ci.org/MoarVM/MoarVM/builds/155560758 github.com/MoarVM/MoarVM/compare/e...7426a2f0e0
11:32 travis-ci left
timotimo took you long enough! 11:34
how the honk does it compile on OSX with gcc?
the answer is:
you're dumb. that's not gcc. 11:35
dalek arVM: 13fdd83 | timotimo++ | .travis.yml:
travis doesn't actually have gcc on osx.

we were getting a clang the entire time! *gasp*		 11:45
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:51
now it's running 4 at the same time 11:53
i wonder if it'll do 8 at the same time when those 4 have finished?
12:03 Ven joined 12:14 travis-ci joined
travis-ci MoarVM build passed. Timo Paulssen 'travis doesn't actually have gcc on osx. 12:14
travis-ci.org/MoarVM/MoarVM/builds/155564685 github.com/MoarVM/MoarVM/compare/d...fdd83c3db2
12:14 travis-ci left
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:17
./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:18
bare block about 3x slower, for FYI 12:20
./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:22
jnthn wat, an empty block is slower? o.O :) Can't wait to see the code-gen on this one :P 12:23
Except I can 'cus my lunch is ready :) 12:24
JimmyZ haha :)
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.
We should prolly produce a QAST::WVal instead. 12:25
anyways, nomming :) &
JimmyZ change 'method b' to 'sub b' , outputs 0.97 12:32
and sub b {} empty block is 0.97 too 12:33
so , method call is about 2x slower than sub call 12:35
16:03 domidumont joined 16:21 domidumont joined 16:46 Ven joined 19:32 domidumont joined
dalek arVM: 718339d | timotimo++ | src/profiler/heapsnapshot.c:
heapsnapshot: Also free annotation when leaving function early

Finally fixes Coverity CID 135433		 19:50
19:54 Ven joined 20:39 Ven joined 20:50 Ven joined
jnthn coverity++ timotimo++ 21:22
21:50 vendethiel joined
timotimo just a few very cheap things unlikely to ever be noticable 22:15
any thoughts on my ridiculous ideas for startup speedup?
we also have a bunch of things that have sink called on them from the mainline i expect 22:16
not sure if thwt's worth anything
also i should resurrext that logging that shows exactly what is being demanded from the sc 22:17
maybe zheres some "thats dumb" stuff where we demand atuff be deserialized just to go ignored for most use cases 22:18
vendethiel timotimo: you ran a static analyzer on moarvm? 22:19
timotimo yes, ptc owns a coverity thingie for moar 22:20
we could make an official one, too
go find it, sign in with github, request to be added to the project 22:22
help triage defects
we dont have terribl many
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
i caused some explosions when i tried to make extract key dependent on whether there is a cached hash code already 22:29
its probably not so expensive for most cases during startup, like most strings are likely not ropesy 22:31
there's no way i'll find 50% start up time improvement with this ... texhnique 22:32
and a 2x factor would sure be nice 22:34
without that 2x factor, fuzzing rakudo with p6 code in strings is going to be 100% unhelpful 22:50
23:03 Ven joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!