| 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 | |||
| also | |||
| 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 | ||
| yes | |||
| 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) | |||
| :sarcasm: | |||
| 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. |
13:22 | |
| MoarVM/spesh-worker: 1fb27e574e | (Jonathan Worthington)++ | 3 files Write unspecialized call entries into the log. |
13:40 | ||
| MoarVM/spesh-worker: e1e802a122 | (Jonathan Worthington)++ | 3 files Write OSR points into spesh log. |
13:51 | ||
| 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. |
14:08 | |
| 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. |
14:35 | |
| MoarVM/spesh-worker: 62c762b350 | (Jonathan Worthington)++ | 3 files Log the outcome of decont operations. |
14:46 | ||
| 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. |
15:01 | |
| 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. |
15:21 | |
| 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: gist.github.com/MasterDuke17/d8872...54682092fd | 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 | ||
| yeah | |||
| 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 | ||