Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-12-06

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

All times shown according to UTC.

Time Nick Message
02:34 vendethiel joined #moarvm
03:16 kjs_ joined #moarvm
05:46 TimToady_ joined #moarvm
08:44 domidumont joined #moarvm
08:49 domidumont joined #moarvm
10:51 vendethiel joined #moarvm
11:16 leont joined #moarvm
11:27 18WABBFX8 joined #moarvm
12:32 nebuchadnezzar joined #moarvm
12:44 kjs_ joined #moarvm
12:55 timotimo jnthn: frame.c has the instrumentation level barrier check if the levels are unequal. if they are, it sets to the instances current instrumentation level and then only does a single instrumentation; is that correct? perhaps we want to make profiling, cross-thread-writing, and coverage reporting to be mutually exclusive
13:41 moritz_ joined #moarvm
13:41 arnsholt_ joined #moarvm
13:41 ashleydev joined #moarvm
13:42 Util joined #moarvm
13:45 vendethiel joined #moarvm
13:45 timotimo there seems to not be a precedent yet for allocating objects during a spesh or instrumentation phase. but i expect it'll be all right
13:55 kjs_ joined #moarvm
13:57 ilmari joined #moarvm
14:21 jnthn timotimo: We assume during spesh that we won't allocate, fwiw
14:22 jnthn (That's relied on in various places)
14:24 timotimo oh, good to know
14:24 vendethiel joined #moarvm
14:24 timotimo how do i allocate a spesh slot that a later op can then allocate an object into?
14:25 timotimo can i just set it to 0 and later change the effective_spesh_slots array?
14:27 jnthn I...guess
14:27 timotimo i'm trying to give each spesh graph a little BOOTIntArray where it stores if a given line has already been reported
14:27 timotimo it feels icky; it looks like you agree :)
14:27 jnthn On the instrumentation: yeah, we don't have a story on composing those yet. It's a hard problem, so I decided to just leave it :)
14:28 jnthn For when there's time :)
14:28 timotimo right. i wasn't expecting it to be easy to just instrument one after the other
14:28 timotimo i could just go full insanity mode and use malloc to allocate that BOOTIntArray
14:28 jnthn You usually only use one or the other anyway
14:28 timotimo yeah, who would profile *and* coverage-analyze
14:29 jnthn You're not actually doing anything with spesh, just writing an instrumentation?
14:29 timotimo and if you expect things to blow up because of threadedness trouble, you wouldn't run a coverage log either
14:29 timotimo that's right
14:29 jnthn ah
14:29 jnthn Then at least if it busts it's low-impact :)
14:29 timotimo it puts a reporting op after each bb's batch of PHI ops
14:29 timotimo hehe.
14:29 timotimo then i'll keep the current way until i find it breaks
14:30 virtualsue joined #moarvm
14:30 timotimo it'll be running against the spec test suite, so it'll have plenty of work and opportunity to asplode
14:30 timotimo if i pre-size that array at instrumentation time to hold all possible reportable numbers, it'll not be trouble to access the BOOTIntArray concurrently either!
14:32 timotimo i'm starting to think this isn't going to suck terribly :)
14:32 jnthn :)
14:43 timotimo cool. tc is null. that's new.
14:43 * timotimo builds with 0 optimization
14:44 timotimo huh. effective_spesh_slots is 0
14:45 timotimo well, that's not so nice
14:46 dalek MoarVM/line_based_coverage: 5795ee0 | timotimo++ | / (11 files):
14:46 dalek MoarVM/line_based_coverage: first prototype of a per-line coverage reporter
14:46 dalek MoarVM/line_based_coverage: review: https://github.com/MoarVM/MoarVM/commit/5795ee0f3e
14:47 timotimo maybe it's something obvious that makes that happen. it occurs when the interpreter hits the coverage_log instruction
14:50 timotimo or perhaps it's impossible to use spesh slots from instrumentation because it neglects to set up ... something?
14:57 timotimo perhaps because it kicks out all spesh candidates after instrumenting? and perhaps that makes the spesh slots disappear, too? :\
14:59 timotimo jnthn: maybe you can figure something out, i'll be AFK for a bit
15:20 ilmari joined #moarvm
15:28 camelia joined #moarvm
15:39 flussenc1 joined #moarvm
15:55 flussence joined #moarvm
16:07 kjs_ joined #moarvm
16:09 JimmyZ so jvm has less than 300 opcode and we have more than 750 opcode? ;)
16:36 dalek joined #moarvm
16:57 jnthn JimmyZ: Did you count all of their VM-implemented methods too?
17:02 JimmyZ jnthn: I didn't , but I know they have special VM-implemented methods
17:02 jnthn Right, so you need to count those too to get a fair comparison.
17:07 timotimo jnthn: got a clue about the disappearing spesh slots?
17:11 jnthn Oh... I guess it's that instrumenation does not actually go through the full spesh pipeline.
17:11 timotimo right
17:11 jnthn Otherwise we'd think instrumented frames were already specialized.
17:11 timotimo but i can do it for this one?
17:12 jnthn Um...not...easily...
17:12 timotimo OK, so i'll use malloc instead of the gc to alloc those arrays? :P
17:12 jnthn Or I can't see an asy way :(
17:12 jnthn Yeah, that'd do it
17:13 flussence joined #moarvm
17:13 vendethiel joined #moarvm
17:21 timotimo grmbl. we don't have a GET_I64
17:23 timotimo oh, we do
17:23 timotimo it's just named differently
17:38 timotimo hm. my MVMArray isn't being set up right, it seems
17:40 timotimo body->slots ends up being a null pointer
17:41 timotimo but body->elems is set to 1
17:41 timotimo .o( if we only have 1 element, we could totally store that in the body pointer! what a fantastic space saving idea!!)
17:45 timotimo oh, i have to use zeroed alloc
17:45 timotimo malloc*
17:45 timotimo i forgot malloc doesn't do that for you :)
17:46 timotimo that's a silly mistake to make :)
17:49 timotimo ho-hum. a segfault in "goto NEXT"
17:51 domidumont joined #moarvm
17:52 timotimo my instruction is defined to be str int32 int32 int64 and i do cur_op += 20; that should be right, right?
17:55 timotimo haha. in my last commit i forgot to add the new files
17:57 dalek MoarVM/line_based_coverage: 6a7c350 | timotimo++ | / (6 files):
17:57 dalek MoarVM/line_based_coverage: add missing files, adjust op to not use spesh slot
17:57 dalek MoarVM/line_based_coverage:
17:57 dalek MoarVM/line_based_coverage: since instrumented frames are actually not fully speshed,
17:57 dalek MoarVM/line_based_coverage: and can't easily be, we have to rely on a literal int64
17:57 dalek MoarVM/line_based_coverage: as a pointer to the line report store and allocate it
17:57 dalek MoarVM/line_based_coverage: without involving the GC, so it won't move.
17:57 dalek MoarVM/line_based_coverage: review: https://github.com/MoarVM/MoarVM/commit/6a7c350ae1
18:01 timotimo oh! it's because i'm corrupting jumplists!
18:08 timotimo hum.
18:09 timotimo my jumplist detection code doesn't work here
18:10 timotimo there isn't actually a jumplist, so the bytecode itself must have been corrupted or something?
18:13 timotimo oh. my conclusion about jumplist not being there might well be wrong
18:13 timotimo as i used the spesh log, but that only triggers when frames get considered hot
18:17 timotimo whoa, ouch. num_preds is 0 for all those BBs?
18:17 jnthn timotimo: I think we may compute those as part of SSA
18:18 jnthn And if you just copied the profiler code, it knows it doesn't need that analysis doing
18:18 timotimo right, that'd make sense
18:18 timotimo :)
18:18 timotimo i did copy that! :)
18:18 jnthn So simply asks for a CFG without SSA applying.
18:18 timotimo if i can rely on all blocks following the jumplist to be chained in linear_next properly, i can just skip them that way
18:20 timotimo ho-hum.
18:20 timotimo now i just don't instrument bbs that have exactly one instruction which is a goto
18:20 timotimo and that gets me to ===SORRY!===
18:20 timotimo No lexical found with name 'decints'
18:22 timotimo damn. const_iX NYI; so i'm creating bogus bytecode here
18:25 timotimo neato! i have something that survives a simple "say 'hi!!'"
18:31 timotimo next step is to throw out the BOOTIntArray and use a little chunk of memory instead, to make the impact a bit less severe
18:34 dalek MoarVM/line_based_coverage: 479e645 | timotimo++ | src/instrument/line_coverage.c:
18:34 dalek MoarVM/line_based_coverage: properly skip over jumplists
18:34 dalek MoarVM/line_based_coverage: review: https://github.com/MoarVM/MoarVM/commit/479e6455d0
18:56 dalek MoarVM/line_based_coverage: 0d94be2 | timotimo++ | src/ (3 files):
18:56 dalek MoarVM/line_based_coverage: use a blob of memory instead of BOOTIntArray
18:56 dalek MoarVM/line_based_coverage:
18:56 dalek MoarVM/line_based_coverage: this ought to make things a bit less expensive.
18:56 dalek MoarVM/line_based_coverage: review: https://github.com/MoarVM/MoarVM/commit/0d94be2359
19:29 dalek Heuristic branch merge: pushed 35 commits to MoarVM/even-moar-jit by bdw
19:29 timotimo ohai brrt
19:39 brrt joined #moarvm
19:40 brrt ohai timotiom
19:40 brrt i was actually just pushing something i'd merged earlier :-)
19:41 timotimo oh, ok
19:41 timotimo you know how happy i am every time i see you commit stuff ;)
19:42 timotimo i'll be afk for half an hour now, after that i'll teach spesh to kick out coverage reports that have already fired before we hit the spesh and that'll allow a few frames to be jitted again
19:42 timotimo but i'm running a full spec test run at the moment, collecting all coverage reports with tail -f on the one file and putting the result into another file
19:42 timotimo it's already 300 megabytes big :)
19:45 brrt wow :-o
19:47 brrt anyway, i maybe get some work down on the tiler linearisation tomorrow
19:47 brrt i hope :-)
19:47 brrt see you!
19:47 jnthn o/ brrt
20:12 timotimo \o/
20:37 JimmyZ joined #moarvm
21:49 leont joined #moarvm

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