Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-11-22

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

All times shown according to UTC.

Time Nick Message
01:05 vendethiel joined #moarvm
01:29 vendethiel joined #moarvm
01:52 vendethiel joined #moarvm
02:32 btyler joined #moarvm
02:32 dalek joined #moarvm
02:32 hoelzro joined #moarvm
02:32 oetiker joined #moarvm
02:32 lue joined #moarvm
02:41 lue joined #moarvm
03:29 vendethiel joined #moarvm
04:28 JimmyZ joined #moarvm
05:04 kjs_ joined #moarvm
05:18 vendethiel joined #moarvm
06:04 vendethiel joined #moarvm
06:40 vendethiel joined #moarvm
11:10 oetiker joined #moarvm
11:10 hoelzro joined #moarvm
11:10 dalek joined #moarvm
11:10 btyler joined #moarvm
11:13 vendethiel joined #moarvm
11:29 zakharyas joined #moarvm
11:37 zakharyas1 joined #moarvm
11:40 dalek MoarVM: 898fe2a | (Timo Paulssen)++ | src/spesh/optimize.c:
11:40 dalek MoarVM: integrate set with previous instruction if possible
11:40 dalek MoarVM:
11:40 dalek MoarVM: cases where an operation sets an intermediate register that
11:40 dalek MoarVM: only gets read by a set immediately following that operation
11:41 dalek MoarVM: occur frequently enough that this should be worth the tiny
11:41 dalek MoarVM: bit of analysis work.
11:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/898fe2a62a
12:32 dalek MoarVM: 63c5d88 | (Timo Paulssen)++ | src/spesh/args.c:
12:32 dalek MoarVM: non-passed optional parameters make some BBs unreachable
12:32 dalek MoarVM:
12:32 dalek MoarVM: they don't get removed yet, perhaps because they are still
12:32 dalek MoarVM: referred to by the dominance tree?
12:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/63c5d88724
12:33 timotimo ^- this also wants an accompanying case for the other branch of named optional parameters
12:33 timotimo where we turn the instruction into a goto and ignore the "other" successor
12:34 timotimo and i'm not entirely sure what keeps the BBs alive that no longer get referred to
12:38 timotimo oh, i know what's wrong with that
12:39 timotimo the potential goto we're kicking out would skip the next block. we're just turning a potential skip into a guaranteed fall-through
12:39 timotimo that's fair, then
12:39 timotimo future optimizations may be happy to see the predecessors disappear for that particular future block
12:39 dalek joined #moarvm
12:53 tgt joined #moarvm
13:26 timotimo i may have to build a "not quite legit" fact discovery thing that relies on the mechanism we use to turn the SSA back into regular bytecode ...
13:26 timotimo by looking at version gaps and building an artificial "set", or alternatively raising the version on the instruction that writes to a too-low version ...
13:33 timotimo it seems like it's now safe to uncomment the optimize_can_op now
13:33 * timotimo is spec-testing right now
13:44 dalek MoarVM: f89f527 | (Timo Paulssen)++ | src/spesh/optimize.c:
13:44 dalek MoarVM: re-activate optimize_can_op; survives spec tests now.
13:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f89f527ecb
13:44 dalek MoarVM: 2aa669d | (Timo Paulssen)++ | src/spesh/optimize.c:
13:44 dalek MoarVM: turning stuff into sets should also cause fact copying
13:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2aa669dcf0
13:57 timotimo hmpf.
13:58 timotimo given a not_i whose source operand's value is known, setting the target operand's known value as well makes the core setting compilation fail
13:58 timotimo could it be we're setting a known_value somewhere that's not actually correct?!
14:13 dalek MoarVM/spesh_constant_folding: 7f1646f | (Timo Paulssen)++ | src/spesh/optimize.c:
14:13 dalek MoarVM/spesh_constant_folding: trivial constant folding for not_i
14:13 dalek MoarVM/spesh_constant_folding:
14:13 dalek MoarVM/spesh_constant_folding: this breaks the rakudo build; maybe there's an optimization
14:13 dalek MoarVM/spesh_constant_folding: somewhere that sets a KNOWN_VALUE that ends up not having
14:13 dalek MoarVM/spesh_constant_folding: the correct value set?
14:13 dalek MoarVM/spesh_constant_folding: review: https://github.com/MoarVM/MoarVM/commit/7f1646fe2b
14:42 FROGGS[mobile] joined #moarvm
14:57 timotimo is it expected that the benchmark '[+] (1 .. 10_1024).comb>>.Int' will spend a whole lot of time in bind and bind_one_param? (compared to the rest of things, that is)
14:57 timotimo 13.49% of exclusive time spent in "find_best_dispatchee", 11.55% of x-time in bind and 11.05% in bind_one_param
14:58 timotimo next one is &return with 9.16% x-time spent
14:59 timotimo also the GC activity is fun to look at. first a bunch of stuff gets promoted, then 10 collections long it'll only promote and retain a bit of stuff, almost exactly the same amount each time
14:59 timotimo then it basically promotes + retains about 100% each time for 35 runs
15:00 timotimo then it promotes & retains almost nothing at all for almost 500 runs
15:00 timotimo then it promotes and retains wildly fluctuating amounts between 25% and 100%
15:01 timotimo interestingly, the profiler notices exactly two allocations in total
15:01 timotimo one BOOTCode and one Block
15:06 timotimo huh. 'my int $i = 0; while $i < 1024 { my int $j = 0; while $j < 1024 { $k = $i + $j; $j = $j + 1 }; $i = $i + 1 }; say $k' also spends almost all of its time in find_best_dispatchee + bind_one_param and bind
15:07 timotimo 23.75% + 23.29% + 21.91%
15:07 timotimo then 10% in at_key and 5.6% in a different at_key
15:26 dalek joined #moarvm
16:10 kjs_ joined #moarvm
16:30 kjs_ joined #moarvm
16:36 japhb That seems ... wildly wrong.  All types are known and native; there are no loop controls and the loops are of the simplest non-infinite type.  Why is this not optimized out the wazoo, and never dispatching anywhere?
16:46 timotimo good q.
16:46 timotimo i would have expected that as well.
16:50 timotimo something quite weird happens with another of the benchmarks where there's a whole bunch of GC runs that discard almost 100% of their data, but the allocations tab doesn't show much; a manual introspection of the nursery with my gdb helper thingie reveals that the nursery gets filled up with MVMStaticFrame instances over and over and over
17:08 timotimo on the one hand, these things annoy me greatly because i have no clue where to look to find out what's wrong
17:08 timotimo on the other hand: yay, there's still performance improvements that can be had!
17:08 timotimo also: why does it look like the loops in that last benchmark don't get inlined?
17:09 * timotimo is hoping for a little bit of jnthn magic to fix these things up a bit
17:11 timotimo i wonder if we do worse than we used to in these benchmarks? i can't really run benchmarks on my desktop at the moment, as its ipv4 is b0rked from a distro upgrade ...
17:52 FROGGS__ joined #moarvm
17:58 zakharyas joined #moarvm
18:28 colomon joined #moarvm
18:32 timotimo i see that our profiler has no way to handle operations that may or may not allocate
18:32 timotimo how about adding a "does the object that was passed to prof_allocated reside at the very end of the nursery?" and set more extops in rakudo to "ALLOCATING"?
18:41 timotimo jnthn: sorry for the huge amount of backlog filler %)
18:51 timotimo so ... the at_key use comes from Stash
18:51 timotimo why the hell would it want to access a Stash object rather than going directly through the lexpad for that code?!
19:01 dalek MoarVM: a1a9f88 | (Timo Paulssen)++ | src/core/interp.c:
19:01 dalek MoarVM: when bindlex fails, we should report "bindlex", not "getlex"
19:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a1a9f88f00
19:01 dalek MoarVM: e92c6c8 | (Timo Paulssen)++ | src/profiler/instrument.c:
19:01 dalek MoarVM: takeclosure is a very popular allocating op.
19:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e92c6c8433
19:01 timotimo ^- this gives us more precise profiles
19:02 timotimo bind_one_param allocates 4194308 BOOTCode objects in the doubly nested while loop we have up there
19:02 timotimo which ... just wow.
19:03 timotimo is_bindable and at_key give 1048577 each and find_best_dispatchee is responsible for another 2097160
19:03 timotimo i *still* don't know why we're going through Stash, though
19:03 timotimo we really should be inlining these blocks anyway
19:03 timotimo m: say "test"
19:03 camelia rakudo-moar 3bbf7b: OUTPUT«test␤»
19:04 timotimo m: "that benchmark allocates { 8389651 / 4194308 } as many BOOTCode as it does Scalar"
19:04 camelia rakudo-moar 3bbf7b: ( no output )
19:04 timotimo m: say "that benchmark allocates { 8389651 / 4194308 } as many BOOTCode as it does Scalar"
19:04 camelia rakudo-moar 3bbf7b: OUTPUT«that benchmark allocates 2.00024676 as many BOOTCode as it does Scalar␤»
19:04 timotimo that's pretty impressive.
19:04 timotimo but all of these Scalar allocations happen in at_key and bind_one_parameter
19:26 timotimo japhb: see what i did there? for some reason i was missing the declaration of $k as a lexical and that made stuff blow up >_<
19:27 timotimo and of course that's already fixed in newest perl6-bench
19:28 timotimo grrr. been hunting ghosts again
19:29 timotimo jnthn: if you don't have time (or energy (which i would understand)) to backlog over my wall of text, i'd like you to answer at least this simple-ish question:
19:29 timotimo for ops (i've only looked at extops here, really) that only sometimes allocate, should there be a check "does the value we got back from that operation look like it was allocated very recently?"
19:31 jnthn Well, for simplicity we may want to consider just always putting the check in.
19:31 jnthn Sicne it goes in the profiling code
19:31 timotimo that's what i thought; so you think the check sounds like a sane idea?
19:32 timotimo i'd probably compare if object address + object size is equal to or at least "close to" the current allocation pointer of the nursery
19:32 timotimo hm, but that wouldn't cover allocating "directly to gen2"
19:32 jnthn To the degree a guy who has been traveling for 20 hours knows what's sane... :P
19:32 jnthn We don't need to cover "directly to gen2" really
19:32 timotimo OK
19:32 jnthn It's typically done by thing slike deserialization or bytecode loading
19:32 jnthn Which aren't really anything the user can do anything about in their program
19:34 timotimo fair enough
19:35 timotimo jnthn: https://github.com/rakudo/rakudo/blob/nom/src/core/metaops.pm#L3 - do you know of a way how to make this allocate a ludicrous amount of BOOTCode?
19:35 timotimo could nqp::getstaticcode or something similar be used for that?
19:35 timotimo maybe a macro would be sensible ... not that we have that working yet %)
19:37 jnthn Well, I put a desugars mechanism into Actions with the idea of turning some of these very common meta-ops into just some QAST nodes
19:37 jnthn I can live with all the list-processing meta-ops involving a bit of HOP; you're normally dealing with a bunch of data.
19:38 timotimo ah
19:38 jnthn But would prefer the assign and not ones just do some code-gen, I think...
19:38 timotimo great. what should i grep for to find that?
19:39 jnthn But can only do that when you know they are executing immediately
19:39 jnthn So it's not so straightforward
19:39 timotimo oh, you mean we have to check we're not doing something like my &foo = &[+=]
19:39 jnthn Exact.
19:39 timotimo i have an idea how to figure that out in the optimizer. in the Actions, however ... not so much
19:40 timotimo maybe it could be a use case for Want?
19:40 timotimo er, no, that doesn't make sense
19:40 timotimo if += appears in void context, it wouldn't do anything at all
19:42 timotimo ah, the desugar thing is the very first thing in actions
19:46 jnthn The optimizer may actually be a much easier place than the desugar...
19:46 jnthn Since you have the context to hand
19:47 timotimo that should decrease the memory pressure on tight loops that use += a *whole* lot
19:50 Ven joined #moarvm
19:51 timotimo 294 collections instead of 938 when i write the += out
19:55 jnthn so collect /o\
19:55 jnthn bbiab
20:10 Ven joined #moarvm
20:59 dalek MoarVM/6pe: 5a3f555 | jonathan++ | docs/6model-parametric-extensions.markdown:
20:59 dalek MoarVM/6pe: Start documenting the parametric 6model design.
20:59 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/5a3f5553c6
20:59 dalek MoarVM/6pe: b9c4ee9 | jonathan++ | / (6 files):
20:59 dalek MoarVM/6pe: Stub parametricity-related ops.
20:59 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/b9c4ee9fe9
20:59 dalek MoarVM/6pe: 7812954 | jonathan++ | src/6model/6model.h:
20:59 dalek MoarVM/6pe: STable extensions for parametricity.
20:59 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/78129541f5
20:59 dalek MoarVM/6pe: 5edcbb5 | jonathan++ | src/gc/collect.c:
20:59 dalek MoarVM/6pe: GC marking for STable parametricity bits.
20:59 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/5edcbb5462
21:00 jnthn Hm, and there were more commits, but I overflew dalek....
21:02 FROGGS__ jnthn: that's a prep for NSA?
21:02 FROGGS__ such abbr
21:03 jnthn Amongst other things, yes.
21:03 jnthn It's one of the two main VM-level pieces needed for NSA
21:04 FROGGS__ what's the other one?
21:04 jnthn Well, or it will be when I get it done. :P
21:04 jnthn Other one is the native references.
21:04 jnthn I'm very contented with the 6pe design.
21:04 jnthn Well, what I have of it so far
21:04 FROGGS that sounds good to me :o)
21:05 jnthn Still need some more brain cycles on the native references stuff. Something felt a little off last time I was working on those.
21:05 jnthn Probably I just need some more concentrated, non-exhausted time.
21:06 jnthn Train journeys tend to be good thinking time, and I'll be back and forth to Stockholm like a yoyo for the next several weeks... So I think I'll get a design I like straightened out and coded up within the next weeks. :)
21:06 FROGGS what are native refs in one sentence?
21:08 jnthn Well, consider the naive compilation of: my $x := @omg-i'm-a-native-int-array[42]; $x = 69;
21:08 jnthn There's no Scalar container in a native array. A native reference is an assignable thingy that is a reference to a native location.
21:09 FROGGS ohh, understood
21:09 jnthn They're a bit curious to design because you're trying to optimize for being able to kill them off in the earliest possible optimizer. :)
21:09 FROGGS thanks :o)
21:09 jnthn That is, those that Perl6::Optimizer can kill off, it should. What it can't, spesh + inlining should be able to do something about.
21:10 jnthn At least, for the kinds of cases people are likely to write.
21:12 jnthn So jetlag. Very bedtime. zzz
21:12 TimToady o/
21:12 FROGGS gnight jnthn :o)
22:02 timotimo &infix:<+> is put into the metaop as a QAST::Var lexical
22:02 timotimo that's a tiny bit problematic
22:03 FROGGS ⁺ <--- just a tiny bit
22:03 timotimo :)
22:03 timotimo i wonder how i should analyze this to figure out it's not going to change under my feet
22:04 timotimo m: &infix:<+> = sub ($a, $b) { 1 };
22:04 camelia rakudo-moar 3bbf7b: OUTPUT«Cannot modify an immutable Sub+{<anon>}+{Precedence}␤  in block <unit> at /tmp/1sBJjsoRIM:1␤␤»
22:04 FROGGS m: my &infix:<+> = sub ($a, $b) { 1 };
22:04 camelia rakudo-moar 3bbf7b: ( no output )
22:04 FROGGS would that hurt also?
22:11 timotimo no
22:11 timotimo it's just being referenced
22:11 timotimo oh, i'd just copy the name over into the call's name
22:11 timotimo and that'd be fine

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