|
00:08
Ven joined
02:22
geekosaur joined
|
|||
| samcv | timotimo, btw if you try and use UCD git repo. there is now a git submodule | 03:38 | |
| since i am using some of the grammar based Unicode datafile parsers that i have from my other repo | |||
| so you'll have to run git submodule update --init --recursive prolly | 03:39 | ||
|
06:52
robertle joined
07:45
zakharyas joined
07:55
domidumont joined
08:02
domidumont joined
|
|||
| jnthn | morning, #moarvm | 08:11 | |
| samcv | morning jnthn | 10:21 | |
| jnthn | o/ samcv | ||
|
11:00
Ven joined
|
|||
| samcv | jnthn, hashes don't take up too much extra space right | 11:14 | |
| so i made c arrays for all the different property values gist.github.com/samcv/84b738e17f9e...b3931e0a7c and so if somebody requests <:foo<Property_Value>> we have to look up the property value in the associated c array | 11:16 | ||
| right now we don't support the property value names really well at all | |||
| m: say ')' ~~ /<:Line_Break<Close_Punctuation>>/; say ')' ~~ /<:Line_Break<CP>>/ | 11:21 | ||
| camelia | Nil ｢)｣ |
||
| samcv | but loading c hashes is not very resource intensive right? | ||
| if we just did it on demand | 11:22 | ||
|
11:22
AlexDaniel joined
11:43
Ven_ joined
11:50
Ven_ joined
|
|||
| jnthn | samcv: Our hashes ain't the most memory efficient, though they're some pointers per entry cheaper than a stock uthash at least :P | 11:56 | |
| (Our hash implementation started out as uthash but is only just about recognizable as it now, I suspect) | |||
| samcv | heh | ||
| i gotta head to bed. night o/ | 12:03 | ||
| lizmat | night, samcv! | 12:04 | |
| nine | samcv: sleep well! | ||
| samcv | thanks :) | ||
|
12:24
Ven joined
12:32
Ven_ joined
12:39
Ven_ joined
12:49
Ven_ joined
12:54
Ven_ joined
12:56
Ven joined
|
|||
| Geth | MoarVM/even-moar-jit: 25 commits pushed by (Pawel Murias)++, (Jonathan Worthington)++, (Jimmy Zhuo)++, jnthn++, cono++, (Bart Wiegmans)++ review: github.com/MoarVM/MoarVM/compare/e...40944f7c0a |
13:02 | |
|
13:20
brrt joined
|
|||
| brrt | so yesterday i wasted an evening rebasing even-moar-jit on current master | 13:21 | |
| it was not a good idea | |||
| all sorts of stuff broke | |||
| jnthn | Oh? :S | ||
| What kinds of stuff, ooc? | 13:22 | ||
|
13:24
Ven_ joined
|
|||
| brrt | well, i had refactored the graph builder and the label handling code in the new JIT | 13:39 | |
| and that conflicted with changes I had introduced in the old JIT, so stuff like sequence numbers, return structure, object labels... didn't work anymore | 13:40 | ||
| was quite a trick getting it to compile agian | |||
| eventually I made a diff between the rebased branch and the original one, applied it, and that made stuff work | |||
| obviously, because now the branches are equal | 13:41 | ||
| i'm not sure if it's useful for anything but historical interest | 13:42 | ||
|
14:16
domidumont joined
14:21
brrt joined
14:27
zakharyas joined
14:55
Ven joined
15:01
Ven_ joined
15:08
Ven joined
15:13
AlexDaniel joined
15:15
Ven_ joined
15:21
Ven_ joined
15:31
Ven_ joined
15:36
robertle joined
15:39
Ven_ joined
15:47
Ven_ joined
|
|||
| Geth | MoarVM: 62bc54e939 | (Jonathan Worthington)++ | src/6model/reprs/Decoder.c Fix inconsistency in decode stream API. The take bytes API should, like the take chars one, return null if it cannot satisfy the request. |
15:55 | |
|
16:24
Ven joined
16:49
Ven_ joined
18:02
brrt joined
|
|||
| brrt | blerg perst: brrt-to-the-future.blogspot.nl/2017...alues.html | 19:03 | |
| could've been longer, would probably not have been worth it | |||
| brrt afk & | |||
|
19:43
brrt joined
19:51
zakharyas joined
|
|||
| Geth | MoarVM/even-moar-jit: 33bf8d025a | (Bart Wiegmans)++ | src/jit/linear_scan.c Uses preceed definitions Suppose a tile uses and defines a value at the same time, e.g. $a = $a + $b Then the definition of $a would open a hole, only for the use to close it immediately. If it were the other way arround, the JIT would presume a hole (backwards from $a) where there wasn't any. So this patch fixes that. |
20:25 | |
| Zoffix | brrt++ good post | 20:33 | |
| brrt | thanks Zoffix | ||
| i had more topics to discuss, and I didn't even mention timotimo++ and MasterDuke++'s help in finding bugs :-) | 20:34 | ||
| jnthn | brrt++ # blogging | 20:36 | |
| yoleaux | 18:43Z <Zoffix> jnthn: BTW what do you think of making IO::Handle.encoding consistent with other attributes? You can change $fh.chomp/.nl-in/.nl-out by assigning to them, while $fh.encoding takes an arg instead. I kinda left it alone, but if we're doing all these refactors that touch encoding, maybe we should nail that consistency too? | ||
| jnthn | .tell Zoffix I'm fine with making encoding work like the rest in principle; would prefer it's done after my branch, though, since that already does more than enough :) | 20:37 | |
| yoleaux | jnthn: I'll pass your message to Zoffix. | ||
| Zoffix | k | 20:38 | |
| yoleaux | 20:37Z <jnthn> Zoffix: I'm fine with making encoding work like the rest in principle; would prefer it's done after my branch, though, since that already does more than enough :) | ||
| brrt | thanks :-) | 20:39 | |
| Geth | MoarVM/even-moar-jit: 62bc54e939 | (Jonathan Worthington)++ | src/6model/reprs/Decoder.c Fix inconsistency in decode stream API. The take bytes API should, like the take chars one, return null if it cannot satisfy the request. |
||
| MoarVM/even-moar-jit: 42d2eaa96e | (Bart Wiegmans)++ | src/6model/reprs/Decoder.c Merge remote-tracking branch 'origin/master' into even-moar-jit |
|||
| brrt | i want to do a more thorough exposition of the jit-bisect script and friends at some point | 20:40 | |
| but there are more immediately relevant things to do still | |||
| timotimo | extension points will be amazing | 21:45 | |
| MasterDuke | timotimo: do you know if the jit statistics in profiles are correct with the new jit? | 21:48 | |
| timotimo | should be | 21:51 | |
| shouldn't make a difference at all, i don't think | 21:52 | ||
| MasterDuke | cool, so should be relatively easy to compare old jit and new with profiles | 21:53 | |
| timotimo: what sorts of things should be faster now with the new jit? | 21:57 | ||
| timotimo | the percentage of things jitted vs not shouldn't differ at all | 21:58 | |
| MasterDuke | yeah, but i thought the new jit was supposed to produce faster code? | 21:59 | |
| timotimo | aye | 22:00 | |
| when you look at the code the old jit generates, you'll see that it's full of movs | |||
| the new one should emit significantly fewer movs | |||
| MasterDuke | so it should be faster in every case? | ||
| timotimo | not necessarily, though | 22:01 | |
| if i'm not mistaken, it still has to restore every value back to memory at the end of an exprjitted block so that the old jit can take over | |||
| so if the bits that the exprjit does are very short, we won't win much | |||
| and there's still the question of proper weighting of tiles so that the jit will choose tilings well | 22:03 | ||
|
22:34
geekosaur joined
23:50
eater joined
|
|||