Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-01-24

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:56 colomon joined #moarvm
03:04 colomon joined #moarvm
05:35 Hotkeys joined #moarvm
05:35 Hotkeys hello
05:36 Hotkeys as of https://github.com/MoarVM/MoarVM/commit/ba7bdeb0ec4d37de40517ac1cc24fef1ef94cd25 moar won't build on windows (for me on two machines) because it cannot find msinttypes/inttypes.h
05:42 Hotkeys It appears that $config{'toolchain'} isn't initialized
05:42 Hotkeys "Configuring native build environment ................... Use of uninitialized value $config{"toolchain"} in string eq at Configure.pl line 266."
05:42 Hotkeys I'm not really sure what a good solution here would be, so I'm just reporting it
05:46 Hotkeys oops sorry
05:47 Hotkeys looks like this was already fixed and rakudo just hasn't bumped the moar version yet
05:47 Hotkeys my apologies
07:28 domidumont joined #moarvm
07:33 domidumont joined #moarvm
10:13 leont joined #moarvm
12:58 colomon joined #moarvm
13:07 FROGGS joined #moarvm
13:52 FROGGS_ joined #moarvm
15:24 zakharyas joined #moarvm
16:33 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:37 jnthn Maybe. Though .comb of a long string may also show it up in its memory use :)
16:37 timotimo right
16:37 jnthn How common are single-char strings?
16:38 jnthn 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
16:38 jnthn *nod*
16:38 timotimo well, that's exactly what i want to find out :)
16:39 timotimo alternatively, is there a single point where MVMString gets created? perhaps.
16:39 timotimo mostly in the encode and decode functions, right?
16:39 timotimo and perhaps substr and flatten ropes in the ops
16:40 jnthn Well, a *lot* of places use the codepoint and grapheme iterators.
16:40 jnthn All the encode/decode functions certainly do that.
16:40 timotimo oh, wait, MVMString is also a REPR by itself
16:40 jnthn aye
16:41 timotimo but its initialize method wouldn't be late enough to catch the size of the created string
16:41 timotimo i ought to ponder this a bit more
16:41 timotimo BBIAB
16:57 timotimo taking hashes of our strings is also driven by the codepoint iterator now?
16:58 timotimo if so, i must have missed the commits that made it so during the bigger nfg refactor or where-ever that happened
16:58 timotimo 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
16:59 jnthn No, hashing them always turns thme into 32-bit grapheme buffers at the moment.
17:00 jnthn That'll want to change
17:00 timotimo ah
17:01 timotimo 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
17:01 jnthn 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
17:02 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 :)
17:04 timotimo this neat little article here says malloc(1) gives you 32 bytes of used-up memory
17:04 timotimo 8 byte for tracking data and then it's padded up to the minimum malloc will allocate, which seems to be 32
17:09 timotimo huh, i can probably find out how often a one-character-string gets allocated with a little perf script
17:09 timotimo 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!
17:16 timotimo 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!
18:34 lizmat joined #moarvm
19:17 virtualsue joined #moarvm
19:21 domidumont joined #moarvm
19:43 ggoebel14 joined #moarvm
20:00 colomon joined #moarvm
20:04 domidumont joined #moarvm
22:32 kjs_ joined #moarvm
22:51 colomon joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary