samcv yay and now working with single codepoint keys too. woo 00:00
now i can do a dance metaphorically 00:02
timotimo offers high-fives 00:22
00:23 buggable joined
samcv :) 01:34
01:49 ilbot3 joined 02:33 ggoebel joined 03:19 geekosaur joined 05:30 brrt joined
brrt okay, other than uncovering a label off-by-one, which is almost certainly either dynasm's problem, i'm no further in figuring out what's wrong 05:40
i'm stuck in a very tight loop that checks if a key exists for the same substring 05:43
that is weird, innit
what if the labels are somehow wrong... 06:00
samcv dynasm labels? 06:01
brrt yeah 06:06
samcv how would you find out? 06:07
brrt well, i know for one thing, that there is an off-by-one 06:12
because i'm supposed to jump to 0x5ff
and i
'm jumping to 0x600
that has very unserious effects so far
but still
samcv why doesn't it have more serious effects?. curious 06:13
sounds like something that could screw things
brrt well, there is a preamble to every basic block 06:14
and it loads the current 'reentry' label to a variable
and when it does that, it assigns it to the %rax register first 06:15
('cause it is a 64 bit number)
well, if you want to affect a 64 bit register in x64, you have to prefix your op
with a 'rex' (register extension) byte 06:16
if you don't have that byte, it will be interpreted as a 32 bit operation
so you'll be writing to $eax, rather than $rax, and your reentry label is just 32 bits wide
which is only important if you throw an exception or something 06:18
samcv hmm so maybe why they haven't caught this bug yes? 06:20
brrt well
fairly sure it's because i'm holding it wrong somehow
nobody cares about dynasm
samcv except us :P? 06:21
brrt it's like this tiny library designed only to write the bootstrap VM for luajit
samcv yeah i had never heard of it before
brrt it's a cool little library, for sure
samcv before i started work on perl 6 that is i mean
brrt (true facebook engineering: rocksdb, a database for fast storage.) 06:22
(let's write a *fast* database, this time)
i'm wondering what assumption with regards to labels i'm breaking…. 06:24
06:25 domidumont joined 06:31 domidumont joined 08:30 zakharyas joined 09:23 lizmat joined 11:07 brrt joined 11:17 Geth joined 11:46 robertle joined
jnthn Righty, I've a little hacking time... 12:44
nwc10 famous last words... 12:50
jnthn :P
Will see if I can get a little more spesh progress in :)
Geth MoarVM/spesh-worker: dc9a63cd8f | (Jonathan Worthington)++ | 4 files
Start giving frames a spesh log correlation ID.

Only when they are warm enough, and up to the point that they have logged enough. Note that the invocations and spesh limit fields of MVMStaticFrame will go away after the refactor, leaving it the same size as they started. In MVMFrame, spesh_log_idx and osr_count will be able to be removed, and we might back this new field 16 bits if that will win better packing.
MoarVM/spesh-worker: 1fb27e574e | (Jonathan Worthington)++ | 3 files
Write unspecialized call entries into the log.
MoarVM/spesh-worker: e1e802a122 | (Jonathan Worthington)++ | 3 files
Write OSR points into spesh log.
timotimo i should delete a bunch of branches i don't need any more 13:52
Geth MoarVM/spesh-worker: f6f896ffa5 | (Jonathan Worthington)++ | 4 files
Add parameter type logging.
timotimo threw out a few 14:15
i think it was 111 branches before, now it's 97
i'll want to look at a few and see if their changes have made it into moar "in spirit", so i can throw them out, too
i'll be on the road for a bit first, though 14:17
Geth MoarVM/spesh-worker: 41419418df | (Jonathan Worthington)++ | 3 files
Log lexical/attr types, static lexical values.
MoarVM/spesh-worker: 62c762b350 | (Jonathan Worthington)++ | 3 files
Log the outcome of decont operations.
jnthn Figuring out how we'll log return value types in this scheme will be a tad more interesting 14:51
14:59 committable6 joined
Geth MoarVM/spesh-worker: 898758839d | (Jonathan Worthington)++ | 3 files
Log the target of an invocation.

This is new information that spesh has in the past not had available to it. It will be used to help us to do better in the case of having predictable closures.
jnthn The ret val is the only thing left. I guess we'll have to put it at the point of actually writing the return value into the calling frame. 15:04
Next week will bring about the larger changes, I guess. 15:06
I'll have to figure out a plan for that
Geth MoarVM/spesh-worker: 36567ce7a8 | (Jonathan Worthington)++ | 3 files
Log types that are returned to a frame.
jnthn Well, that gets us writing all the relevant information from the interpreter into the log
Spectest looks alright also 15:23
A bit slower, but that's no surprise
Alright, enough for this week. :) 15:33
I think my plan for next week is getting the data from logs collated usefully, then refactoring the way we do guards, and then moving specialization work over to the thread. In the process I'll also introduce the certain specializations. 15:35
bbl o/
15:40 domidumont joined 16:34 domidumont joined 17:41 domidumont joined
timotimo hm, if we log the invocation target, is that going to be the code object that's actually the closure, and thus different every time? 17:43
samcv good * 17:44
18:04 robertle joined 18:30 AlexDaniel joined 18:43 domidumont joined 19:08 MasterDuke joined
MasterDuke timotimo: backtrace from a segfault when trying to profile DrForr's List format parser test: 19:11
samcv on todays schedule is getting each collation element into an enum. so we don't have to store the full value, just a reference to a c array which will have the actual value. should save a lot of space 19:16
timotimo MasterDuke: threads, eh?
MasterDuke: it works just fine on my end, the profiling 19:19
MasterDuke i have to remove the lib/.precomp directory for it to segv
timotimo right 19:20
no big surprise, since precomp causes threads to happen
MasterDuke and then the test takes minutes
timotimo only if it has to precomp, you mean? 19:21
MasterDuke runs relatively quickly otherwise
timotimo okay so compiling the library is the slow part
Grammar.pm6 seems to be the culprit 19:22
19:22 FROGGS joined
timotimo mergesubrules and mergesubstates are both not even speshed. maybe the baseline spesh optimization feature in the future will make this run a bit faster 19:50
it's somewhat easy to figure out why something doesn't get jitted. why someone doesn't get speshed on the other hand ... :\ 19:56