01:56 colomon joined 03:04 colomon joined 05:35 Hotkeys joined
Hotkeys hello 05:35
as of github.com/MoarVM/MoarVM/commit/ba...f1ef94cd25 moar won't build on windows (for me on two machines) because it cannot find msinttypes/inttypes.h 05:36
It appears that $config{'toolchain'} isn't initialized 05:42
"Configuring native build environment ................... Use of uninitialized value $config{"toolchain"} in string eq at Configure.pl line 266."
I'm not really sure what a good solution here would be, so I'm just reporting it
oops sorry 05:46
looks like this was already fixed and rakudo just hasn't bumped the moar version yet 05:47
my apologies
07:28 domidumont joined 07:33 domidumont joined 10:13 leont joined 12:58 colomon joined 13:07 FROGGS joined 13:52 FROGGS_ joined 15:24 zakharyas joined
timotimo jnthn: i'm interested in seeing if an optimization to store single-grapheme strings inside the string struct itself rather than mallocing a single-grapheme buffer; how do i best measure this? potentially by making my old gdb thingie that goes through the whole heap work again against latest moar? 16:33
jnthn Maybe. Though .comb of a long string may also show it up in its memory use :) 16:37
timotimo right
jnthn How common are single-char strings?
We need to make sure the opt is worth the complexity. 16:38
timotimo i'd start by looking at what "the empty program" ends up having
jnthn *nod*
timotimo well, that's exactly what i want to find out :)
alternatively, is there a single point where MVMString gets created? perhaps. 16:39
mostly in the encode and decode functions, right?
and perhaps substr and flatten ropes in the ops
jnthn Well, a *lot* of places use the codepoint and grapheme iterators. 16:40
All the encode/decode functions certainly do that.
timotimo oh, wait, MVMString is also a REPR by itself
jnthn aye
timotimo but its initialize method wouldn't be late enough to catch the size of the created string 16:41
i ought to ponder this a bit more
BBIAB
taking hashes of our strings is also driven by the codepoint iterator now? 16:57
if so, i must have missed the commits that made it so during the bigger nfg refactor or where-ever that happened 16:58
the more interesting optimization may be - if the hash stuff is already taken care of - to actually use unsigned-8bit-storage for known-to-be-ascii strings
jnthn No, hashing them always turns thme into 32-bit grapheme buffers at the moment. 16:59
That'll want to change 17:00
timotimo ah
we put basically every string into a hash while compiling to build the string heap, so at least in that place it won't help if that optimization lands 17:01
jnthn aye
I think it may be a reasonable optimization, though if it causes a lot of code churn to do it now I'll be a tad hesitant
timotimo that's fair 17:02
jnthn Though if the remedy to "causes a lot of code churn" is "OK, here's some patches that first refactor things so such changes are easy", I'll be less hesitant :)
timotimo this neat little article here says malloc(1) gives you 32 bytes of used-up memory 17:04
8 byte for tracking data and then it's padded up to the minimum malloc will allocate, which seems to be 32
huh, i can probably find out how often a one-character-string gets allocated with a little perf script 17:09
find all calls to malloc that have the size set to 1 * 32bit, kick out anything that doesn't have a frame from string/*.c in it, and presto!
Caution: When you run your program in the Visual Studio or with any debugger attached, by default the malloc behaviour is changed a lot, Low Fragmentation Heap is not used and a memory overhead may be not representative of real usage - huh! TIL! 17:16
18:34 lizmat joined 19:17 virtualsue joined 19:21 domidumont joined 19:43 ggoebel14 joined 20:00 colomon joined 20:04 domidumont joined 22:32 kjs_ joined 22:51 colomon 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!