samcv anyway actually probably file is gonna end up smaller (i hope) since i'm going to de-duplicate property values 02:07
and should allow more caching too, since characters with the same set of properties will refer to the same memory location
it… works. nice 02:34
now to try it out with a full build
i almost thought it was broken… but there's only so many permutations of property values. and it seemed to check for a few random characters. so 02:46
just made a really small bitfield
02:48 ilbot3 joined
samcv and also due to this, potentially the lookup table where we go front codepoints to where the index in the bitfield is, can be much less wide, further decreasing memory requirements 03:19
so say there's 200 permutations of property values, we only need to fill this struct that contains all of the codepoints with not very wide unsigned integers 03:20
diakopter samcv: yes that kind of value sharing is a good idea :) 04:26
I think I measured how many different combinations there were a few years ago; ISTR it was in the thousands 04:27
of course they could be grouped for better compression 04:28
samcv and some of them are derived so we can derive them if it's not too much work 04:29
diakopter wait, now ISTR ucd2pc already did that kind of sharing 04:31
2c
samcv possibly 04:32
diakopter I'll admit, the script isn't ultra perspicuous
samcv yeah i think it dqoes
so far i'm up to 38 properties and so far it takes 8.7K compiled so that's not too shabby 05:12
it does take a quite a while to do its think tho ;)
05:22 vendethiel joined 06:40 geekosaur joined
timotimo man, sure would have loved to catch some Zs that night … 07:14
pahole finds a few bytes here and there that could be saved by rearranging some structs, i'll do that soon, because i need to get back into coding :| 07:18
07:19 domidumont joined
Geth arVM/pahole2017: 5 commits pushed by timo++ 08:12
arVM: timo++ created pull request #503:
Save a tiny bit of space in 6 of our structs		 08:14
08:17 zakharyas joined
Geth arVM/multi_cache_no_segfault_on_null: c415e048da | (Timo Paulssen)++ | src/6model/reprs/MVMMultiCache.c
multi cache shall not asplode when it finds a null argument
 09:22
timotimo ^- broken actually 09:23
will re-push 09:24
Geth arVM/multi_cache_no_segfault_on_null: ef4d0db2ab | (Timo Paulssen)++ | src/6model/reprs/MVMMultiCache.c
multi cache shall not asplode when it finds a null argument
lizmat timotimo: won't that slow down things a lot ? 09:31
timotimo you think?
lizmat *I* don't know :-) 09:32
timotimo how do you figure?
lizmat hence my question
timotimo because we refuse to cache some cases now?
hm. i suppose it could only refuse to cache when it's a low-level null and accept VMNull 09:33
Geth arVM/multi_cache_no_segfault_on_null: 6c21cbb36a | (Timo Paulssen)++ | src/6model/reprs/MVMMultiCache.c
let multi_cache_add survive null args
 09:34
arVM/multi_cache_no_segfault_on_null: 94bdf23444 | (Timo Paulssen)++ | src/6model/reprs/MVMMultiCache.c
we may want to only refuse to work with low-level nulls.
timotimo if you hit this code path that makes it refuse to take from, or add to the cache, it would just have segfaulted previously 09:35
09:41 domidumont joined 09:45 domidumont1 joined 10:35 domidumont joined
Geth arVM/multi_cache_no_segfault_on_null: d7e5fdd7c0 | (Timo Paulssen)++ | src/core/frame.c
liz' code managed to get this to segfault, so guard it
 10:37
arVM: timo++ created pull request #504:
Multi cache no segfault on null		 10:38
10:50 domidumont joined 12:39 brrt joined 13:23 domidumont joined 13:24 domidumont joined
brrt good * #moarvm 14:31
jnthn o/ brrt 15:07
brrt \p jnthn 15:08
i've made reverse progress with writing a blog article about register allocation :-( 15:13
the good news is, though, i do kind of know how to implement the argument-list handler 15:14
the annoying bit about that 15:17
i had originally envisioned the ability to 'swap' registers between live ranges
but that is not generally possible
as it might introduce conflicts
16:02 Ven joined 16:18 Ven joined 16:22 synopsebot6 joined
ilmari grmbles at uses of sizeof(char) 16:24
timotimo oh, is there something wrong with that?
ilmari it's by defintion 1 16:25
if you're being that paranoid you should be using CHAR_BITS instead of "8" for repr_data->bits as well
which is only 8 by POSIX definition, not C
(by virtue of stdint.h's int8_t) 16:26
16:33 Ven joined
timotimo mhm 16:39
we use MVMint8 and MVMuint8 a bunch
16:46 brrt joined 16:51 Ven joined 17:03 Geth joined 17:11 Ven joined 17:12 ggoebel joined 17:20 FROGGS joined 17:31 Ven joined 17:51 domidumont joined 18:03 Ven joined 18:24 Ven joined 18:33 Ven joined 19:04 Ven joined
dogbert17 o/ 19:09
timotimo, jnthn: ok what do you think about this gist, is it better? gist.github.com/dogbert17/8d728478...ea4269da38 19:10
19:46 domidumont joined 20:05 Ven joined 20:24 vendethiel- joined, Ven joined 20:39 Ven joined 20:49 Ven joined 21:06 Ven joined 21:26 Ven joined
timotimo um ... use after free even though we use the safepoint mechanism? 21:39
21:46 Ven joined
timotimo it's specifically designed to make use-after-free impossible :) 21:53
jnthn Hmm 21:55
dogbert17: yes, interesting
dogbert17 I could add the gist as a comment to MoarVM #458 if that's convenient 22:03
jnthn Please do 22:05
jnthn has a bit of a headache at the moment so can't be particularly useful :(
22:06 Ven joined
dogbert17 done 22:09
22:25 Ven joined 22:45 Ven joined 23:05 Ven joined 23:26 Ven joined 23:36 Ven joined 23:50 Ven joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!