01:49
ilbot3 joined
|
|||
timotimo | not sure if sleep went well | 06:08 | |
still getting an explosion when profiling this game i have | 06:13 | ||
amazing. Mu's "item" method is being specialized into enterspesh, getarg, prof_allocated, set, set, takedispatcher, prof_exit, return | 06:15 | ||
ah, it used to have a param_sn that got kicked out | 06:16 | ||
06:31
brrt joined
|
|||
brrt | ohai #moarvm | 06:32 | |
so interesting fact; when I do my infinite loop, i have a 'final entry' | 06:33 | ||
timotimo | that feel when your rr session explodes with a malloc problem when trying to MVM_dump_bytecode(tc) ;( | 06:39 | |
06:47
domidumont joined
|
|||
brrt | haha | 06:50 | |
that feeling when a debugger crashes in general | |||
okay, i'm seeing i officially don't understand | 06:51 | ||
why compare an object with the flags of the other | 06:52 | ||
06:54
domidumont joined
|
|||
timotimo | that seems wrong? | 06:54 | |
though that ought to mean you know what the fix ought to be? | 06:58 | ||
nwc10 | good *, #moarvm | 07:07 | |
timotimo | yo nwc10 | ||
07:12
brrt joined
|
|||
brrt | kind of wrong, yes | 07:13 | |
timotimo | break adjusted to free malloc space - why does this happen? :\ | ||
the ... f? | 07:14 | ||
setting "unwindonsignal" off (so that i could debug what's going on) makes it suddenly work instead of crashing with a segfault | |||
oh, now it dies again when i started it from a different place in the code | 07:16 | ||
just fantastic | |||
i can't reverse-step out of the function i called, so even though i was inside "rr replay" i have to restart the rr replay session :\ | 07:18 | ||
something's not right with the bytecode dumper helpers i wrote; the place it shows my IP to be at doesn't match up with what the interpreter's doing | 07:25 | ||
brrt | hmmm | 07:26 | |
timotimo | 9 ops further up there's a findmeth, or 10 ops down there's one | 07:27 | |
and the interpreter's currently doing a findmeth op | |||
actually, what if it's looking at the wrong frame on the stack? | 07:28 | ||
i do see the IP right after an invoke_o | |||
well, it's most likely this frame's bytecode i'm looking at | 07:35 | ||
i.e. the first few instructions match with the contents of the dump | |||
aha i found where the instruction pointer's at | 07:36 | ||
i wonder if it's sensible that decont on a low-level null just gives the object itself back rather than asploding | 07:42 | ||
08:53
robertle joined
09:43
Voldenet joined
|
|||
jnthn | Since there haven't been any complaints yet about gist.github.com/jnthn/8ee6dc06edc7...7ffabb86b5 I figure I'll dig into it somehow :) | 10:05 | |
brrt | i'm scared but very curious about its reult | 10:08 | |
jnthn | brrt: What parts of it scare you? | 10:11 | |
jnthn is all for trying to reduce risk :) | 10:12 | ||
brrt | well, the multithreaded bit | 10:14 | |
but i guess it should be mostly alright :-) | |||
jnthn | Ah | 10:15 | |
I actually thing it'll be less scary than today | |||
brrt | i suppose it is | ||
jnthn | In that today *every* thread running might be racing to produce specializations | ||
brrt | true | ||
jnthn | So every spesh data structure in MVMStaticFrame has to be desinged to cope with multiple writers | ||
Whereas now it'll be single writer, multiple readers | |||
brrt | but i mostly use single threaded applicaitons so i never see that | 10:16 | |
jnthn | True | ||
I think the scheme I suggested for getting predictability will give it, though? | 10:17 | ||
I'm wondering a bit about taking on gist.github.com/jnthn/8ee6dc06edc7...pe-logging first | |||
Since it's kinda orthogonal-ish to the rest | 10:18 | ||
Hm, or maybe that's not so wise :) | |||
Hah, no, it ain't | |||
It'll increase the number of deopt points and hose up the recent argument handling changes, I fear | 10:19 | ||
jnthn makes a branch, digs into the new bits | 10:20 | ||
Geth | MoarVM/spesh-worker: 9c7e6edc7f | (Jonathan Worthington)++ | 6 files Add MVMSpeshLog representation. Holds a log to be passed from an executing thread to the spesh worker thread. |
11:01 | |
jnthn | lunch & | 11:04 | |
brrt nods, that scheme ought to work | 11:11 | ||
11:18
brrt1 joined
11:38
nebuchadnezzar joined
|
|||
JimmyZ | jnthn: replied your gist.github.com/jnthn/95d0705d225e...aa337624b, though maybe I am wrong | 11:44 | |
jnthn | That's somewhat orthogonal to box/unbox | 11:48 | |
Though very much related to escape analysis | |||
timotimo | wow, 32bit for used and alloc :) | 11:50 | |
jnthn | Not sure how long the logs will want to be :) | 11:51 | |
timotimo | it's 2x 64bit for every entry | ||
m: ((2 ** 32 - 1) * 8) / 1024 / 1024 | |||
camelia | WARNINGS for <tmp>: Useless use of "/" in expression "/ 1024 / 1024" in sink context (line 1) |
||
jnthn | Really? :) | ||
timotimo | m: say ((2 ** 32 - 1) * 8) / 1024 / 1024 | ||
camelia | 32767.9999924 | ||
jnthn | used/limit are in terms of entries, not in terms of bytes :) | 11:52 | |
timotimo | so, 32 giga-entries? | ||
yeah | |||
32 gigabytes in entries per log, i mean | |||
m: say ((2 ** 16 - 1) * 8) / 1024 / 1024 | |||
camelia | 0.4999924 | ||
timotimo | or half a gigabyte of log data per thread if we went down to 16 | ||
JimmyZ wonders what jnthn's thought about Allocation Sinking Optimization compare to other EA Algorithms :P | |||
jnthn | We could, though given there's one log held per thread :P | 11:53 | |
timotimo | though of course there's alignment that might force used + limit to be 64bit wide anyway | ||
jnthn | JimmyZ: It's not clear that the AS thing isn't tied to tracing | ||
timotimo: Yeah, it seems like an odd place to try and save a few bytes :) | |||
JimmyZ | jnthn: oh, yea | ||
timotimo | true that | ||
JimmyZ | yeah | ||
jnthn | On a 64-bit system an entry is actually 24 bytes | 11:54 | |
kind is 4 (alignment makes it being less not worth it) | |||
id is 4 | |||
Then the biggest union branch is 16 | 11:55 | ||
(entry, 2 pointers) | |||
timotimo | wow, how'd i miscount that? | ||
jnthn | Not enough lunch? Too much lunch? :) | ||
timotimo | i've only had breakfast and a nap | 11:56 | |
i think now the cat is demanding attention | 11:59 | ||
12:18
AlexDaniel joined
|
|||
timotimo | okay that was almost an hour of neck-scratches and bellyrubs | 12:46 | |
Geth | MoarVM/spesh-worker: 465451fab3 | (Jonathan Worthington)++ | src/core/instance.h Try to organize instance.h It has grown a huge amount of state over time. This attempts to group the related pieces in some way, to get a better sense of what's in there. |
12:47 | |
timotimo | haha there was still a reference to APR in there | 12:48 | |
jnthn | Yeah :P | 12:49 | |
Finally I can see what state spesh actually has :) | |||
heh, tempted to do a simialr thing for threadcontext.h too | 13:08 | ||
Having just started to do it - yes, 'cus I think I found a dead field and code to go with it too :) | 13:13 | ||
timotimo | the fun i'm having ATM is things asploding in a non-speshed frame, though of course the bad data could come from a wrong-speshed frame | 13:17 | |
Geth | MoarVM/spesh-worker: 6ddfcffb12 | (Jonathan Worthington)++ | src/core/threadcontext.h Organize the mass of state in threadcontext.h some So it's easier to see what's in there and what key subsystems are using. |
13:20 | |
MoarVM/spesh-worker: ac8450a6b5 | (Jonathan Worthington)++ | 3 files Add/mark spesh log queue and per-thread spesh log Currently these are not yet initialized. |
13:30 | ||
14:05
SourceBaby joined
14:26
colomon joined
|
|||
Geth | MoarVM/spesh-worker: 0f1de2d36d | (Jonathan Worthington)++ | 4 files Remove now-unused cur_usecapture field. |
14:35 | |
MoarVM/spesh-worker: 07b722958b | (Jonathan Worthington)++ | 6 files Start specialization worker thread at startup. |
|||
timotimo | sigh, the internet connection here keeps dying | 14:49 | |
interesting, we don't keep a handle on the spesh thread in the instance object after all? | 14:50 | ||
i suppose we don't need any other handle than the queue | 14:53 | ||
jnthn | timotimo: I was trying to think of what I'd need it for and couldn't :) | ||
If we get a reason to ahve it we can add it :) | 14:54 | ||
timotimo | yeah, i can't come up with anything either | ||
Geth | MoarVM/spesh-worker: 3fb2d40d2c | (Jonathan Worthington)++ | 7 files Set up initial per-thread spesh log, if enabled. |
15:15 | |
MoarVM/spesh-worker: 937dcb2cb0 | (Jonathan Worthington)++ | src/spesh/worker.c It helps to actually run the created thread. |
|||
timotimo | heh. | 15:19 | |
man you runed it! | |||
15:21
brrt joined
|
|||
brrt | he wants to JIT compile a specialization selector | 15:26 | |
okay, we can do that | |||
but | |||
if we're going to go that way | 15:27 | ||
why not compile all specializations in a single frame | |||
oh, i know why | |||
because we might not be able to compile all specialized versions | |||
timotimo | whenever we add another specialization, we'd have to recompile the whole thing, no? | 15:35 | |
that could perhaps be expensive | |||
and re-use of registers and such will have to be A Thing, as opposed to how we do inlining where we just put the whole work of the inlinee at the end of the inliner's work area | |||
jnthn | It has occurred to me that we might be able to shortcut quite a lot of the invocation work, though :) | 15:37 | |
brrt | i'm listening | ||
jnthn | And have the selector end up just jumping into the JITted target code | ||
Frame creation has quite a few conditionals and calculations and so on | |||
timotimo | ah, yes, interesting | 15:38 | |
making invocation cheaper is something we'll all benefit from | |||
jnthn | Bump-the-pointer'ing the CallStackRegion for example should be easy to compile | ||
And sometimes that's all we'll have to do | |||
15:56
brrt joined
|
|||
brrt nods | 15:57 | ||
and suggest that the expr jit should make this kind of thing easy | |||
because it introduces a layer that the 'C' code can work with to make machine code | 15:58 | ||
could also be done in dynasm, for sure | |||
…. oh, wow | 16:25 | ||
how even does this happen | |||
my label is off by one.... | |||
16:47
AlexDaniel joined
17:03
robertle joined
|
|||
timotimo | if i need to make a branch for advanced moarvm-under-gdb stepping functions (step in and out of moar-bytecode-level funcitons and such), i'll probably call it here_come_the_hotsteppa | 17:35 | |
jnthn | :P | 17:39 | |
18:16
domidumont joined
18:29
zakharyas joined
19:09
buggable joined
|
|||
samcv | \o/ yay it's working | 20:38 | |
and seems to be working even when i dump all the data into it. not just a partial run | |||
and also work when there's collation elements attached to a non-terminal node | |||
HelpBot[perl6] | \o/ | 21:14 | |
21:16
lizmat joined
|
|||
samcv | and luckily the code has less paths now as well. so that's a ++ as well :) whenever doing recursion the more code paths really can screw you over | 21:18 | |
now it just has ternary operators and maybe one if condition period | 21:20 | ||
for the code that creates the c code | |||
21:58
nebuchadnezzar joined
|