01:28 avuserow joined 01:54 FROGGS_ joined 06:53 zakharyas joined 07:00 JimmyZ joined 07:10 FROGGS joined 07:12 FROGGS joined 07:13 kjs_ joined 07:35 kjs_ joined 07:51 JimmyZ_ joined 08:01 odc joined 08:04 zakharyas joined 08:17 zakharyas joined 08:39 kjs_ joined 08:57 zakharyas joined, zakharyas1 joined
jnthn manages to catch the long-standing inline + GC segfault in his debugger :) 09:03
frame->spesh_cand->num_locals 09:07
195
195 * sizeof(MVMRegister)
1560
frame->allocd_work
1256
Yeah...that's bust.
JimmyZ jnthn++ 09:42
jnthn Will known in the next 10 mins if I've managed to nail it, I think. 09:43
dalek arVM: 17896bc | jnthn++ | src/gc/roots.c:
Don't mark inlined locals for logging frames.

When a continuation is taken involving a logging frame, it can easily end up living much longer than we might expect, and the specialization may complete without it. Make "not a logging frame" a condition for marking extra locals added due to inlining.		 09:57
jnthn FROGGS: Plesae can you see if this patch fixes github.com/MoarVM/MoarVM/issues/133 ? 09:59
timotimo jnthn: did you have an opinion on building an sp_advancearriter opcode that'd let us turn a shift on an array iterator into a cheap advance op and then a direct pointer lookup with sp_get_*? 10:02
jnthn timotimo: So we can JIT iterator stuff better? 10:05
timotimo github.com/MoarVM/MoarVM/blob/mast...Iter.c#L52 - could make this switch obsolete and move all these error checks to the front
yes
i'm not sure to what extent nqp::iter is actually used inside perl6 code itself 10:06
.o( well, shift in particular )
grepping for nqp::shift would probably give many cases of actually shifting stuff from arrays, too
jnthn Yeah, I think it's more used in NQP code 10:07
Maybe it's wait until after Austria
Because then we'll understand the GLR needs a bit better
timotimo gotcha
i'm looking for simple-ish tasks to pull myself out of writer's block or whatever it is i'm having
dalek arVM: 0df2d6f | jnthn++ | src/core/interp.c:
Fix crash upon trying to clone a type object.

Closes #128.		 10:11
jnthn timotimo: Hm, so quick-reward things? 10:13
timotimo i think so 10:14
jnthn timotimo: Making the profiler still give output if the program dies with an exception is not too hard, I think. 10:15
timotimo: Also you could look at depth limiting, so that it aggregates results below a certain call-tree depth when building the output
timotimo: So that then the data for CORE.setting would be useful 10:16
timotimo i had a quick glance at the depth limiting, but it looked like if i did the "obvious" change it'd ignore data from the innermost frames, too
jnthn I was going to do it by recording all the data 10:17
And then just trimming it when we turn it into data structures
'cus the recording of all the data is in quite compact C data structures
Whereas the thing we use to produce the JSON grows huge.
timotimo ah, aye 10:18
so the change would be in the nqp code rather than the c code?
jnthn No, I was going to do it in the C code
But in the C code that builds the data structures 10:19
Lemme show you where...momnet
dump_call_graph_node in src/profiler/profile.c
timotimo mhm 10:20
jnthn timotimo: I pondered adding an extra arg to that recursive routine 10:22
timotimo: That is depth
timotimo: And if it passes a threshold, do something different with the succs beneath it 10:23
timotimo right; the only thing we'd need then is to calculate and remove the exclusive time, no?
but we'd leave the callees list empty 10:24
jnthn Well, "leave callees list empty" is one way to go
But then we miss out on data 10:25
10:25 FROGGS joined
timotimo even if we still recurse and calculate all ze stuff? 10:26
jnthn I was pondering that we could somehow aggregate the data below that point into a single node
And insert a node with a name like <AGGREGATED_42> or so 10:27
timotimo hm. flatten out and then aggregate the callee's tree? (or rather: generate the aggregated callees node directly rather than building a tree and then flattening it)
jnthn timotimo: I was going to make a node and then write a different recursive thing over succs that we pass that node to 10:29
timotimo: And then it just aggregates the data into that one node
timotimo mhm mhm
would that aggregate node have all the callees, then? 10:30
or would it be a much simpler node?
jnthn Well, I was thinking a single node.
You don't have to worry about times
Well;
Hmm
timotimo hm, so what exactly would be aggregated? all entry counts below that point in the tree?
jnthn Actually better I think would be to make it so if we have 10:31
timotimo also, i haven't looked deep into how the allocations data looks
i think that's "beside" the tree
jnthn No, it's in the tree
...loads of nodes down to limit... -> node hitting limit
And below that node we had succ1 -> blah
succ2 -> [blah2 -> blah3, blah4 -> blah3 -> blah5] 10:32
Then we'd end up with the node that hit the limit having a flat bunch of children
succ1, succ2, blah2, blah3 (which aggregates), blah4, blah5
Then we still get all the per-routine timings right. 10:33
And then further annotate those flattened out children with an extra key in the hash
timotimo the key being just a signal for "this is an aggregate node"? 10:34
jnthn So in the UI instead of seeing a graph below a certain point, you just see a list of things that got called
Right
Well
Not even aggregate in some cases
I mean, if there's just a chain of calls below a certain point, we'd have raised them all up to immediate children of the node when we reached the depth limit 10:35
timotimo mhm
jnthn That is, we turn a tree into a set, and aggregate if we see multiple nodes for the same static frame
timotimo mhm 10:36
does it seem like a good or bad idea to just keep that a list and do linear searches to see if a given routine/frame has already been added to that set?
jnthn Linear search is OK here
I think the thing that blows up CORE.setting compilation is hugely deep chains of as_mast calls or whatever we call it 10:37
As in, the profile of CORE.setting compilation
timotimo mhm mhm 10:38
jnthn And there's only around 10-20 candidates
timotimo and perhaps parts of the parse tree that go pretty deep?
jnthn Maybe in places 10:39
FROGGS jnthn: lemme see (MoarVM#133) 10:48
hmmm, I've got problems accessing github :o/ 10:50
jnthn: #133 is solved, aye 11:03
err, jnthn++ even :o)
jnthn \o/ 11:04
I figured that may be the same bug :)
12:05 JimmyZ joined
dalek arVM/esc: f03cb5e | jonathan++ | / (4 files):
Start annotating ops that allocate.
 12:16
arVM/esc: 236c7a8 | jonathan++ | src/spesh/dump.c:
Add dump support for escape information.

We're not recording any yet.
arVM/esc: a19689a | jonathan++ | src/spesh/ (3 files):
Start recording allocation sites.
jnthn masak++ helped with those too 12:17
(They're from yesterday, at BJ airport)
masak jnthn: I'm guessing you found/fixed the segfault? :) 12:36
jnthn masak: Oh...no, that was uncommitted so the patch still lives on my laptop 12:37
masak ah ha.
JimmyZ jnthn: looks like missing break after 'found = 1' in 236c7a81b1 12:50
jnthn JimmyZ: That's probably more efficient, though makes no difference to correctness 12:53
JimmyZ aye
jnthn Feel free to tweak it. 12:54
dalek arVM/esc: 0c32ff2 | jimmy++ | src/spesh/dump.c:
add missing break
 12:58
13:38 FROGGS[mobile] joined 13:46 FROGGS joined 14:30 FROGGS joined 16:08 JimmyZ_ joined 17:09 vendethiel joined
dalek arVM: 685ad32 | jnthn++ | src/main.c:
Improve usage, include environment variables.
 17:18
17:51 Ven joined 18:47 brrt joined
brrt \o 18:55
18:57 Ven joined
jnthn o/ brrt 18:59
brrt hi jnthn
back from china
?
jnthn Yes :)
brrt glad to be home? i would be :-) 19:02
ehm... did we implement clone in the JIT?
jnthn Yes, very :) 19:03
Oh, good point about the clone thing. Hmm.
brrt oh, we do that by calling MVM_repr_clone 19:04
so we can just update that definition
hmm.. 19:08
i wonder if we could allocate some register space for temporary roots
that way, it'd be easier to use in the JIT directly 19:09
dalek arVM: cedaaa3 | (Bart Wiegmans)++ | src/6model/reprconv.c:
Fix concreteness test for the reprconv.

This also closes #128, but now for the JIT.		 19:17
arVM: b4dd2f0 | (Bart Wiegmans)++ | src/main.c:
Document bytecode directory environment flag
 19:19
brrt 'software maintenance' :-) 19:20
20:12 lizmat joined 20:44 brrt left 21:05 japhb joined 21:45 kjs_ joined 22:27 kjs_ 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!