| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:44 patrickb left
timotimo i think i've reached a point where things work 01:46
m: my @before = 14930632, 55096, 123560; my @after = 1, 2, 3; say "savings individually: ", (@before Z- @after), " summed: ", ([+] @before Z- @after), " percentages: ", (@before Z/ @after Z* 100) 01:56
camelia ===SORRY!=== Error while compiling <tmp>
Only identical operators may be list associative; since 'Z/' and 'Z*' differ, they are non-associative and you need to clarify with parentheses
at <tmp>:1
------> , " percentages: ", (@before Z/ @…
timotimo m: my @before = 14930632, 55096, 123560; my @after = 1, 2, 3; say "savings individually: ", (@before Z- @after), " summed: ", ([+] @before Z- @after), " percentages: ", ((@before Z/ @after) Z* 100)
camelia savings individually: (14930631 55094 123557) summed: 15109282 percentages: (1493063200)
timotimo don't get too excited, that's just test data
m: my @before = 14930632, 55096, 123560; my @after = 1, 2, 3; say "savings individually: ", (@before Z- @after), " summed: ", ([+] @before Z- @after), " percentages: ", ((@before Z/ @after) X* 100)
camelia savings individually: (14930631 55094 123557) summed: 15109282 percentages: (1493063200 2754800 4118666.666667)
timotimo m: my @before = 14930632, 55096, 123560; my @after = 1, 2, 3; say "savings individually: ", (@before Z- @after), " summed: ", ([+] @before Z- @after), " percentages: ", ((@after Z/ @before) X* 100)
camelia savings individually: (14930631 55094 123557) summed: 15109282 percentages: (0.0000067 0.00363 0.002428)
timotimo just need the real data now
m: my @before = 14930632, 55096, 123560; my @after = 14726520, 54336, 122304; say "savings individually: ", (@before Z- @after), " summed: ", ([+] @before Z- @after), " percentages: ", ((@after Z/ @before) X* 100)
camelia savings individually: (204112 760 1256) summed: 206128 percentages: (98.63293128 98.62059 98.98349)
timotimo 1.4% on core.c and core.d, but only 1.01% on core.e
that is size reduction
yes that is 206 kbyte saved from the setting precomp files
a visualization of entropy for CORE.c.setting before my changes: 01:58
and after my changes: 01:59
since the bytes are arranged in a hilbert curve, you'll see that the frames section got a bit shorter because the big magenta squiggly squares on the left somewhat near the top don't snake past the middle line towards the right 02:01
i *think* the stuff i tossed out was mostly in the uppermost left corner?
the colors in general have shifted a little because the distribution of byte values has changed 02:02
it looks like doing the exact same thing for lexical variables can save some more space 02:50
07:15 domidumont joined
nine one step at a time :) 07:32
09:25 sena_kun joined 09:28 zakharyas joined 09:59 zakharyas left
timotimo working on the second step now :) 10:27
10:34 Altai-man_ joined 10:36 zakharyas joined, sena_kun left
nine samcv: can you please do a point release (2020.01.1)? sena_kun++ would like that as a base for the 2020.01 rakudo release. I've completed steps 1-5 of the release guide already. 11:04
11:16 squashable6 left 11:19 squashable6 joined
timotimo serialization wrangling is hard when you don't know if it's the writing or the reading end that's wrong ... 11:34
i might have fixed the last bug 11:39
m: my @before = 14930632, 55096, 123560; my @after = 14652680, 54128, 121696; say "savings individually: ", (@before Z- @after), " summed: ", ([+] @before Z- @after), " percentages: ", ((@after Z/ @before) X* 100) 11:44
camelia savings individually: (277952 968 1864) summed: 280784 percentages: (98.138378 98.243067 98.491421)
timotimo that's comparing before i started with what it's at now
nwc10 timotimo: have you considered writing a JIT instead? That might be easier :-0)
timotimo 1.8% instead of 1.4% for core.c, 1.7% instead of 1.38% on core.d and 1.5% instead of 1% on core.e 11:45
who wants that?
nwc10 not sure which "that"? I'd like it all, and a pony. But I'd be happy with 1.8% savings in size 11:46
er, sorry, "I want it all". The impolite tone is important, I believe.
timotimo ha 11:47
i'd have liked a little more savings tbh 11:49
that's the third binvis image
for my latest change, that is
Geth MoarVM/compressed_lex_loc_types_serialization: 62bfd1cea6 | (Timo Paulssen)++ | 2 files
"Compress" serialization of local variable types

Object registers are overwhelmingly common, and this very simple scheme saves a bunch of space already, without being too complicated.
MoarVM/compressed_lex_loc_types_serialization: b0e24a7644 | (Timo Paulssen)++ | src/core/bytecode.c
drop redundant "if" clause
MoarVM/compressed_lex_loc_types_serialization: 153d4e80d1 | (Timo Paulssen)++ | 2 files
"Compress" types of lexical variables

same method as before, but this commit also switches the order of lexical names and lexical types; now all names come first, then all types.
11:59 zakharyas left 12:28 lucasb joined 12:33 MasterDuke left 12:34 sena_kun joined 12:36 Altai-man_ left
timotimo haha, oh no 12:55
there's a regex in core that does time parsing, it appears in the string heap, and it has lots and lots of spaces :D 12:56
13:04 zakharyas joined
lizmat yeah, I've been meaning to get rid of that 13:08
timotimo it's barely a blip, though 13:10
lizmat perhaps it makes sense to squash extraneous spaces ?
timotimo for storage in the string heap, or manually in the source code, or for storing the source of a regex in its object? 13:12
dumb question 13:17
how do i format an nqp-level native integer (or boxed integer) to a base 16 string?
lizmat there's nqp::base_I 13:18
I guess you need to upgrade to I first ? 13:19
timotimo mhh
lizmat nqp::base_I(nqp::p6box_i($a),16) 13:20
timotimo not sure i'll have p6box_i available at that position 13:22
lizmat box_i(foo,Int) ? 13:25
timotimo i stole from sprintf's intify and just created a bare $knowhow for this purpose 13:26
OK, cuids are now base 27 13:27
hm, should be 37 actually 13:28
lizmat I thought we only supported upto 36 ?
timotimo oops
i wouldn't mind adding lowercase letters as well, but up to that point uppercase and lowercase were equal
like A through F for base 16
this'll make the core setting shrink yet a tiny bit more 13:29
lizmat why is shrinking the core setting important ? 13:30
timotimo makes me feel good 13:31
lizmat aaah... ok :-)
sena_kun lizmat, lower footprint? 13:32
lizmat yeah, but it is my understanding that the setting is loaded lazily anyway ?
timotimo it's a major contributor to package size and also ram usage for empty program (if you count shared memory) 13:33
well, the setting is memory-mapped, that's true
some things are read and turned into other stuff, like the string heap is read and turned into string objects - lazily, but still.
also, the serialized blob is lazily turned into all the objects we have 13:34
m: my @before = 14652680, 54128, 121696; my @after = 14625888, 54088, 121672; say "savings individually: ", (@before Z- @after), " summed: ", ([+] @before Z- @after), " percentages: ", ((@after Z/ @before) X* 100) 13:35
camelia savings individually: (26792 40 24) summed: 26856 percentages: (99.8171529 99.926101 99.980279)
timotimo oh wow
that's barely worth a thing for the non-c settings 13:36
m: say 26792 / 1024
camelia 26.164063
timotimo the string heap is interesting because there's this "fast table" that's generated by quickly skipping through loads of strings; the exact performance implications of making some already-short strings shorter i'm not exactly sure about 13:38
less memory traffic is good 13:39
i'm not sure if the cuid strings are actually ever deserialized in regular rakudo operation 13:40
looks like with my base-36 cuids the values go up to D6I in core.c.setting 13:42
m: say :36<D6I>
camelia 17082
timotimo pleasant amount of shortening 13:43
though the "only numbers" cuids are already a good step up from "cuuid.{full unix timestamp at sub-milisecond precision}" we had a long long time ago 13:47
14:23 zakharyas left 14:26 zakharyas joined 14:34 Altai-man_ joined 14:36 sena_kun left 14:50 brrt joined
brrt \o 14:50
tellable6 2020-01-20T21:59:36Z #raku-dev <patrickb> brrt: Would you be willing to mentor again? Might a follow up project of last years GSoC be a good project idea?
15:12 squashable6 left 15:14 squashable6 joined
nwc10 o/ 15:34
brrt \o nwc10 15:39
did anybody see, by any chance, the MIR compiler proposal/plan fly by
jnthn No? 15:40
nwc10 did 15:41
brrt 15:42
jnthn: it's sort of on the same level as GNU Lightning, and CraneLift, and ... I guess the expression IR
with the difference that the expression IR is mildly more clever for some of the things we do a lot
brrt is back in an hour or 2 15:43
15:48 brrt left
nine brrt: I posted the link yesterday :) 16:02
tellable6 nine, I'll pass your message to brrt
nine brrt: mere minutes before you joined the channel
tellable6 nine, I'll pass your message to brrt
16:26 domidumont left 16:35 sena_kun joined 16:36 Altai-man_ left 16:40 domidumont joined, domidumont left 16:44 domidumont joined 16:59 brrt joined 18:00 patrickb joined 18:15 brrt left 18:33 zakharyas left 18:34 Altai-man_ joined 18:37 sena_kun left 18:58 squashable6 left 18:59 squashable6 joined 19:25 brrt joined 19:39 MasterDuke joined 19:56 domidumont left 20:07 zakharyas joined 20:16 squashable6 left 20:18 squashable6 joined 20:34 sena_kun joined 20:35 Ven`` joined 20:37 Altai-man_ left 20:57 patrickb left 21:01 zakharyas left 21:24 brrt left
samcv hey nine I just got home. see you wanted a point release? 21:32
sena_kun samcv, o/ 21:33
samcv, yes, having one would be awesome. :)
(though I am not nine, of course)
samcv sena_kun, from master? 21:35
sena_kun samcv, lemme see... yes, it's good 21:36
samcv, sorry for doing it twice, I'll try to do better next time.
samcv ok. give me a bit 21:43
sena_kun, i just got home and it's pretty late. i probably won't get to release until tomorrow. 21:57
sena_kun samcv, ok, thanks for notifying. take your time and have a good rest. :)
22:25 Ven`` left 22:34 Altai-man_ joined 22:37 sena_kun left 22:46 Altai-man_ left