| samcv | MasterDuke: does anything seem wrong? or is this just checking the code is alright and you don't notice any problems currently? | 00:53 | |
|
02:56
ilbot3 joined
|
|||
| MasterDuke | i don't notice any problems, but it's curious that memory use is greater, so an overall check would be good | 03:48 | |
| but off to sleep now... | 03:49 | ||
|
06:46
brrt joined
|
|||
| brrt | good * #moarvm | 06:47 | |
|
07:05
domidumont joined
07:11
domidumont joined
07:43
robertle joined
07:49
brrt joined
08:03
zakharyas joined
08:56
zakharyas joined
09:14
zakharyas joined
09:16
zakharyas joined
09:23
zakharyas joined
09:29
zakharyas joined
10:01
geospeck joined
10:11
zakharyas joined
12:02
brrt1 joined
13:20
markmont joined
13:44
zakharyas joined
16:11
brrt joined
16:16
committable6 joined
17:32
domidumont joined
17:54
zakharyas joined
17:55
AlexDaniel joined
19:06
robertle joined
20:20
MasterDuke joined
20:42
zakharyas joined
21:00
geospeck joined
21:18
geospeck joined
21:25
lizmat joined
21:48
geospeck joined
|
|||
| MasterDuke | timotimo: any thoughts as to why my string fsa branch would use more ram? | 22:47 | |
| timotimo | not really; could be overhead from internal fragmentation of the FSA pages perhaps? | 22:58 | |
| MasterDuke | i was also kind of surprised it took the same amount of time. i thought it would be sort of a best case for the fsa and maybe a little faster | 22:59 | |
| timotimo | it might be interesting to see how big the percentage of "direct to malloc" allocations is | 23:00 | |
| MasterDuke | in that code i ran there should have been very few, right? | 23:01 | |
| timotimo | i forgot what your code was :S | 23:02 | |
| MasterDuke | some version of: MVM_SPESH_BLOCKING=1 perl6 -e 'my @ss = "sm.sql".IO.comb; say @ss[*-1]; my @o-ss = @ss.map({ $_ ~ rand.Str }); say @o-ss[*-1];' | 23:03 | |
| might not have had the second part with rand when i was talking about numbers | |||
| jnthn | MasterDuke: The FSA rounds up to its bin size | 23:04 | |
| MasterDuke | arg, i keep forgetting that! | 23:05 | |
| timotimo | m: say rand.Str | ||
| camelia | 0.920356743167877 | ||
| timotimo | ok, those are "long" strings from the perspective of my in-situ storage feature | ||
| jnthn | Aside from the cost of writing all the additional code-paths to cope with it, timotimo's in-situ storage feature is likely to be more of a win on memory for strings | 23:06 | |
| timotimo | actually, not many code paths :) | ||
| mainly in the iterator, and a few to check if one should be made | 23:07 | ||
| jnthn | Hm...I guess maybe a lot of stuff uses the grapheme or codepoint iterator | ||
| timotimo | one of these exists inside "iterate into string" which is used a bunch | ||
| aye | |||
| MasterDuke | right, i guess a small memory increase wouldn't be too surprising. but no speed increase? | ||
| timotimo | there's still something missing, though, as a regex match with a certain char class fails with 32bit in-situ-storage added | ||
| jnthn | MasterDuke: Well, it's an extra branch every time we free a string, for one... | 23:08 | |
| For two, how many string-creating code paths manage to get an FSA hit? | |||
| timotimo | i imagine not having to chase a pointer for in situ storage makes a noticable difference | 23:09 | |
| jnthn | Yeah, it's very cache friendly | ||
| MasterDuke | jnthn: well, that code i showed should, right? lots of tiny strings created | ||
| timotimo | and at some point our gc will support variable sized objects so short strings can have longer in-situ than just 64 bits | 23:10 | |
| jnthn | Perhaps so, but note that's also a trade-off (eat the nursery faster) | ||
| timotimo | true | ||
| jnthn | (And copy more for survivors) | ||
| timotimo | OTOH we already limit the nursery size when strings get allocated | 23:11 | |
| not sure what the threshold for that is | |||
| MasterDuke | jnthn: that note in reply to me? | ||
| jnthn | MasterDuke: The last two were to timotimo :) | ||
| timotimo | no, in response to my variable sized thing | ||
| MasterDuke | ah | ||
| jnthn | #define FSA_SIZE_DEBUG 1 | 23:12 | |
| I guess you turned that off before timing? :) | |||
| timotimo | that's a good idea | ||
| jnthn | I figure MasterDuke++ probably did, just askin' just in case :) | ||
| timotimo | that'd certainly increase both memory usage and run time | ||
| jnthn | MasterDuke: I wasn't to clear a moment ago; I more meant "how many get hit at runtime", which I can't tell from reading the code :) | 23:13 | |
| But if it's a low proportion it might explain the low speedup | |||
| btw, do we currently use the FSA for the strand list? | |||
| timotimo | currently no mention of "fixed" inside MVMString.c at least | 23:16 | |
| jnthn | 'cus that strikes me as likely to be a clearer win | ||
| timotimo | in particular no free call for that | 23:17 | |
|
23:17
markmont joined
|
|||
| timotimo | there's an additional opportunity for putting in-situ storage inside the strands array where a pointer to an actual string object usually lives | 23:17 | |
| that saves chasing *two* pointers | |||
| but it might also make the code a bit more complex | 23:18 | ||
| MasterDuke | jnthn: oh, that may have still been on... | 23:25 | |
| let me check | |||
| yep it was, rerunning now... | 23:26 | ||
| timotimo | wow, ok | ||
| i wish i had thought of that | 23:27 | ||
| MasterDuke does also | 23:29 | ||
| ok. so for this benchmark (where sm.sql is 655k and 10k lines): MVM_SPESH_BLOCKING=1 /usr/bin/time ./install/bin/perl6-m -e 'my @ss = "sm.sql".IO.comb; say @ss[*-1];' | 23:36 | ||
| timotimo | i feel like it's time to say this again: you can tell diff to put #ifdef into the code to give either the before or the after for the patch | 23:37 | |
| MasterDuke | master and my branch take the same time, but master averages 209468maxresident and my branch averages 206980maxresident | 23:38 | |
| timotimo | either diff or apply. probably apply | ||
| MasterDuke | ? | ||
| timotimo | someone might find this useful | 23:39 | |
| not necessarily right now | |||
| MasterDuke | ah, didn't understand what you meant, but that's cool | ||
| *didn't understand at first | 23:40 | ||
| timotimo | mhm | ||
| MasterDuke | with a 10x bigger file, time for both is still the same, but master averages 1192376maxresident and my branch averages 1157600maxresident | 23:46 | |
| gotta go prepare dinner, bbl | |||
| timotimo | that's still a surprisingly small improvement | ||
| jnthn | We're lucky we're saving, though? | 23:48 | |
| In terms of memory size, I mean | |||
| timotimo | i'd like to compare against in-situ | ||
| jnthn | In that the FSA rounds up | 23:49 | |
| So we win when it's round-up beats malloc's overhead | |||
| timotimo | malloc has overhead + it rounds up, too | 23:50 | |