00:40
ggoebel joined
00:54
geekosaur joined
01:00
pyrimidine joined
01:48
pyrimidine joined
|
|||
MasterDuke | timotimo: what, at the nqp or rakudo level, causes MVM_serialization_read_int to be called? | 01:49 | |
timotimo | mostly the individual deserialize functions of each repr | ||
but deserialization of "the whole thing" also uses it a couple of times | |||
like "how many objects are in this serialized blob?" -> serialization_read_int | |||
MasterDuke | i happened to notice it's one of the top functions in a perf record of ./perl6-m -e '' | 01:50 | |
timotimo | right | 01:51 | |
it'd be a lot better if our NFAs wouldn't store their entire contents twice | 01:52 | ||
MasterDuke | heh. redundancy is good. a RAID of the NFAs would be even safer! | ||
timotimo | well, it is kind of sort of RAID | 01:53 | |
i'd love it if TimToady could figure out how to clean out the states list before serializing and re-building it when it's needed after deserialization | 01:54 | ||
i'm imagining the win would be noticable | |||
i wonder, did i merge the nfatostatelist branch? | |||
nfa_to_statelist in moarvm | |||
nope, i didn't | 01:55 | ||
MasterDuke | timotimo: hm, no simple way to reduce the # of calls? (like making variables ints reduced smrt_numify calls) | 02:23 | |
timotimo | nah, except for the nfa thing i can't think of anything simple | 02:25 | |
one thing is that we have "lazy deserialization" | |||
i.e. things are only pulled out of the serialized blob when something requests them | |||
look for functions with "demand" in their name | 02:26 | ||
if we could make more classes and functions and such be "touched" during startup, the number of calls for all _serialization_ functions has a chance to fall | |||
MasterDuke | touching things reduces the calls? wouldn't it mean more things do deserialize? | 02:28 | |
*to | |||
timotimo | no, touching less things | 02:33 | |
i mistakened | 02:34 | ||
i tireded | |||
MasterDuke | heh, so touching (using?) fewer classes/functions/etc during startup would reduce the number of calls? | 02:37 | |
timotimo | aye | ||
MasterDuke | hm, any easy way to see what does get touched/used? | 02:38 | |
timotimo | i built something at one point | ||
need to look if it still exists | 02:39 | ||
seems like it's gone | 02:40 | ||
anyway | |||
you can output the sc idx for the objects that get demanded (together with the ID of the SC itself) | 02:41 | ||
just spew it to stdout, for example | |||
MasterDuke | in MVM_serialization_demand_object perhaps? | ||
timotimo | then from a perl6 script you can nqp::wval to get the object from the serialized heap | ||
and ask it what it is, with .HOW.name and such | 02:42 | ||
need to put lots of "try" all over the place, because things can fail magically :P | 02:46 | ||
yes, that's one place to put it | |||
should also be able to get the filename, line, and frame name for frames that get demanded | |||
directly in the C i mean | |||
MasterDuke | from the MVMSerializationContext? | ||
02:48
ilbot3 joined
|
|||
samcv | timotimo, cmph seems nice | 02:53 | |
timotimo | i haven't looked into it more than the first few paragraphs on their site | ||
02:53
pyrimidine joined
|
|||
samcv | timotimo, i made a github repo with the code since they have no git github.com/samcv/cmph | 02:55 | |
one says it takes 2 bytes per key. that's pretty low | 02:56 | ||
idk tho if we have a huge number of cp | |||
but it won't hurt memory if we only load it on demand | |||
timotimo | i'm pretty sure it's supposed to land in the text segment, actually | ||
i.e. shared between processes and such | |||
samcv | well you can load it from a file | 02:57 | |
the hash | |||
timotimo | that's a recipe for desaster | ||
that file has to be installed somewhere, and reliably found, and all that | 02:58 | ||
samcv | :( | 02:59 | |
timotimo | not to mention that a user program can panic in the middle of running when that file doesn't get found and lazily loaded | ||
samcv | we can check the file exists before running? | 03:00 | |
timotimo | well, sure, but then programs that don't need unicode lookups will refuse to start | ||
samcv | uh maybe install moarvm? | 03:01 | |
and not delete the file? idk | |||
timotimo | why wouldn't you want it to be put into the text segment? | ||
samcv | because it takes memory yes? | ||
timotimo | sure | ||
putting it into the text segment makes it zero-overhead for loading | 03:02 | ||
currently we create a hash with uthash at startup, right? | |||
if we have the hash in a file we just need to mmap it, and mmapping it shared and readonly will also give us the shared-between-processes benefit | |||
samcv | no only when needed | ||
timotimo | i was missing that piece of information | ||
samcv | sorry | 03:03 | |
timotimo | how big will the perfect minimal hash be for all codepoint names? | ||
samcv | i dunno | ||
timotimo | can we just run the tool over our dataset? | ||
samcv | yeah | ||
TimToady suspects it will have exponential characteristics | 03:05 | ||
timotimo | oh, if we fail at loading the hash file we can just create the hash during runtime because we still have the list of all codepoint names in our program anyway | 03:06 | |
samcv | sure | ||
timotimo | hmm. i don't feel comfortable making that call | 03:07 | |
samcv | that's weird tho | ||
timotimo | what is? | ||
samcv | i mean i guess we could do it. | 03:08 | |
timotimo | if we want to go the other direction, we could also build the hash table only up to the entry that we were looking for and when we request another name that isn't in the hash currently we just continue where we last stopped | 03:13 | |
we could also have a table of "first character of name" to "position of first name that starts with that in the table" | 03:14 | ||
OSLT | |||
so we don't have to go from 0 to 10000 to find that rare codepoint starting with Z | |||
(again, collecting data about this would be interesting to gauge whether this is useless or not) | 03:15 | ||
but also: that stuff needs locks and everything | 03:16 | ||
samcv | yeah | 03:18 | |
dinner brb | |||
timotimo | sleep bbl :) | ||
samcv | wonder how this would compare github.com/powturbo/TurboPFor/blob.../README.md | 04:03 | |
to having all those if else statements for getting offsets for unicode codepoint properties | |||
04:22
zakharyas joined
04:49
pyrimidine joined
04:54
pyrimidi_ joined
05:06
dogbert11 joined
05:50
pyrimidine joined
06:22
agentzh joined
06:33
agentzh joined
06:48
pyrimidine joined
06:54
pyrimidine joined
06:55
pyrimidi_ joined
07:03
brrt joined
|
|||
brrt | good * #moarvm | 07:08 | |
07:16
nebuchadnezzar joined
|
|||
brrt | .tell timotimo that get_label_for_obj is the mechanism I've used to assign a label to data objects (to pointers, really) | 07:18 | |
yoleaux2 | brrt: I'll pass your message to timotimo. | ||
07:56
pyrimidine joined
08:03
brrt joined
|
|||
samcv | keeping checking this thing out github.com/powturbo/TurboPFor/blob.../README.md it does seem great | 08:47 | |
need to figure out the best encoding though | |||
at least seems to make it easy to bench things | |||
dunno if this stuff builds on MSVC tho | 08:49 | ||
08:58
pyrimidine joined
|
|||
samcv | i think it's time for bed for me. night guys | 09:01 | |
09:16
pyrimidine joined
09:50
Ven joined
09:51
zakharyas joined
10:09
pyrimidine joined
11:02
patrickz joined
11:11
pyrimidine joined
|
|||
patrickz | Hi everyone! How does one typically use gdb with moarvom? I'd like to break in the file MVMArray.c:344 but a simple 'b MVMArray.c:344' does not work. | 11:27 | |
jnthn | Quite often using the perl6-gdb-m script | ||
arnsholt | Ther perl6/nqp files are actually shell scripts | 11:28 | |
patrickz | already did that... | ||
jnthn | OK, and built with debug symbols? | ||
(--debug=3 to MoarVM's Configure.pl) | |||
patrickz | that script complains if there are none as far as I read id | ||
*it | |||
didn't complain for me | |||
jnthn | Ah, then that's why :) | ||
patrickz | ah | ||
rakudobrew doesn't do that by default, right? | |||
jnthn | No | 11:29 | |
Well, MoarVM's configure doesn't do it by default | |||
patrickz | kthx, will rebuild | ||
jnthn | You only need rebuild MoarVM itself | ||
Though dunno how feasible that is if rakudobrew "owns" the build | |||
jnthn never used rakudobrew :) | 11:30 | ||
patrickz | rakudobrew creates pretty normal builds in ~/.rakudobrew/moar-whatever/. One can even build a rakudo oneself and just link the folder in there to make it work with rakudobrew. :-) | 11:31 | |
it's working :-) | 11:44 | ||
jnthn | :) | ||
brrt | i usually also make variants for the nqp scripts | 11:47 | |
and there is a lingering thought in the community to make 'all-in-one' binaries using MoarVM | 11:48 | ||
as far as i can tell, it shouldn't be too hard, but it's just never been done | 11:49 | ||
11:52
pyrimidine joined
11:56
pyrimidine joined
12:16
Ven joined
12:34
brrt joined
12:46
zakharyas joined
12:57
pyrimidine joined
|
|||
timotimo | it's been tried multiple times :) | 13:00 | |
yoleaux2 | 07:18Z <brrt> timotimo: that get_label_for_obj is the mechanism I've used to assign a label to data objects (to pointers, really) | ||
timotimo | at least if you mean "binaries that also include a bunch of moarvm bytecode files" | ||
13:12
Geth joined
|
|||
brrt | yeah, that's pretty much what i mean | 13:17 | |
what made it fail? | |||
timotimo | the core setting's at fault | 13:18 | |
or something like that | |||
you get a rather mysterious error when trying to use it somewhere in the compilation stage | |||
brrt | hmmm | 13:24 | |
13:43
pyrimidine joined
13:58
pyrimidine joined
|
|||
timotimo | i'm considering building a nqp::vmhealth op that gives a hash of tidbits of information | 14:07 | |
and i was wondering if we can have an API where we call a user-supplied function whenever a GC has run with a bunch of data. like, on the event loop thread | |||
jnthn | Finalization does that | 14:08 | |
timotimo | ah, neat | ||
jnthn | Heh | ||
timotimo is looking into building a Prometheus client library | |||
jnthn | You could abuse that somewhat by just creating an throw-away object :) | ||
*a | 14:09 | ||
timotimo | and having information about GC/memory behaviour and similar things would be interesting to have in every moar process | ||
jnthn | For the sake of the finalier | ||
And then making a new one when it runs :P | |||
But that's a total hack :) | |||
timotimo | what, DESTROY { data.new(...) }? :P | ||
jnthn | yeah :P | ||
timotimo | well, i want the data to come from inside the VM, and i don't think DESTROY takes arguments ;) | 14:10 | |
well, it probably "takes" the invocant | |||
so ... i guess you could register the class that has that DESTROY to be "the thing that has to be created when a GC ran"? | |||
jnthn | Yeah, but this is a real hack, I'd not advise it :) | 14:11 | |
timotimo | and it just creates the object at the very end and immediately calls its finalizer | ||
jnthn | I'd do it in some cleaner way | ||
timotimo | yes, i was hoping for a cleaner way, too | ||
but just considering this is kind of amusing | |||
er | |||
jnthn | Like generalizing the post-GC hook that is used to run finalizers | ||
timotimo | (just considering this) (is kind of amusing) | ||
rather than (just) ((considering this) is kind of amusing) | |||
hmpf. the issue about invmod (and thusly expmod) didn't get an answer in the last 7 days on libtom's tommath github issue tracker | 14:15 | ||
when will we free up the earliest deprecated moarvm ops for re-use? | 14:16 | ||
graphs_s "will be deprecated" since 2016-01-12, DEPRECATED_1 since 2016-11-16 | 14:18 | ||
okay they haven't been deprecated for terribly long | 14:19 | ||
14:20
pyrimidine joined
|
|||
timotimo | and DEPRECATED_2 was also just 2017-01-06 | 14:21 | |
14:23
Ven joined
|
|||
timotimo | jnthn: the "run code after GC has finished" thing could be a good hook to install the "dump heap snapshot to disk" thing as well, eh? | 14:33 | |
Geth | MoarVM: dogbert17++ created pull request #531: Fix overflow on 32 bit systems in is_full_collection() |
||
jnthn | Not really because that in itself could trigger GC | 14:34 | |
And render the results useless | |||
timotimo | oh, that's true | ||
15:14
patrickz joined
15:33
patrickz joined
15:52
Ven joined
16:04
lucasb joined
|
|||
lucasb | opcode prof_exit doesn't have an ".s" annotation. is it needed? | 16:05 | |
github.com/MoarVM/MoarVM/blob/mast...plist#L919 | |||
16:08
brrt joined
|
|||
timotimo | no, the exit op is called from user code, i think | 16:12 | |
oh no | 16:13 | ||
that's startprofile and endprofile | |||
16:19
patrickz joined
16:22
Ven joined
|
|||
timotimo | huh, i thought the threads were like a linked list, but i don't see a "next" pointer | 16:26 | |
there it is! | 16:28 | ||
it's not MVMThreadContext, it's MVMThread obects | |||
objects* | |||
i think the comment in MVMThread.h for the next pointer is wrong: | 16:29 | ||
is "next in tc's threads list." | 16:30 | ||
should probably be "next in instance's threads list." | |||
16:48
pyrimidine joined
17:16
patrickz joined
18:16
TimToady joined
18:35
pyrimidine joined
|
|||
samcv | so that seems to get 30% compression compressing integers from 0-20,000 on the fastest compression, so that's good i guess. but not better than i guess doing it yourself. but good to note | 19:29 | |
talking about this btw: github.com/powturbo/TurboPFor | 19:30 | ||
have not yet tried on my actual set of data since our data isn't random | 19:31 | ||
will see what happens when i go back to making a huge list of cp's to bitfield rows | 19:34 | ||
Geth | MoarVM: 18df52c1d4 | (Jan-Olof Hendig)++ | src/gc/orchestrate.c Fix overflow on 32 bit systems in is_full_collection() In order to figure out whether a full GC should be made the code has logic which calculates the percentage of 'promoted' bytes as part of the resident set size. If the calculated percentage is equal to or larger than MVM_GC_GEN2_THRESHOLD_PERCENT a full collection will be made. However, the code which calculate the percent_growth does ... (10 more lines) |
20:07 | |
MoarVM: 0157007402 | (Jonathan Worthington)++ | src/gc/orchestrate.c Merge pull request #531 from dogbert17/master Fix overflow on 32 bit systems in is_full_collection() |
|||
20:09
brrt joined
|
|||
samcv | dogbert11++ | 20:09 | |
timotimo | samcv: were you thinking of compressing the integers that we create with our base40 scheme? | 20:22 | |
samcv | i had not yet. but that may be fun | 20:25 | |
even if it's just to see what happens | |||
timotimo | mhm | 20:26 | |
20:28
pyrimidine joined
|
|||
samcv | let me try that now | 20:29 | |
since it's a lot simpler than doing the point indexes since i already replaced the old code mostly | |||
it may be able to compress a lot, since if it only stores the difference between each 16 bit number that could save a lot | 20:32 | ||
and variable bit integers as well | 20:33 | ||
one of them got 50% compression timotimo | 20:36 | ||
so that's like what, 200KB instead of 1.7MB for storing all the names or whatever | 20:37 | ||
er wait hmm or maybe it's 400K. idk it said the final size was 401188 but ratio is 50.2% | |||
bits per int was 16.06 so actually that didn't compress it at all XD | 20:38 | ||
Geth | MoarVM/even-moar-jit: 36 commits pushed by (Samantha McVey)++, (Jonathan Worthington)++, (Timo Paulssen)++, (Daniel Green)++, (Bart Wiegmans)++, (Lucas Buchala)++, (Zoffix Znet)++, (Benny Siegert)++, niner++ review: github.com/MoarVM/MoarVM/compare/b...3065b2a47b |
||
samcv | maybe not supplying the correct options | ||
timotimo | hmm | 20:40 | |
lots of it is probably tuning, yeah | |||
samcv | maybe gotta specify the int size i think it defaults to 32 bit | 20:41 | |
-f[X[c][H]][.d][s] X = file format: | |||
[1=int8], [2=int16], [4=int32(default)], [f:float] [d:double] | |||
t = text:one integer per line, c=column number in multiple columns line | |||
c = text:integers separated by non digit char | |||
. = decimal digits (default 2) | |||
H = skip first line | |||
s = sorted (increasing), S=sorted (strictly increasing, no duplicates), z=ZigZag | |||
why they gotta make this confusing | |||
maybe i want -f2 ? and not sure how to specify uint | 20:42 | ||
i was running ./icbench -eBENCH -ft maybe that's size_t idk. it was just in the example | 20:43 | ||
running ./icbench -eBENCH -f2 gives me C Size ratio% Bits/Int C MI/s D MI/s Name File | 20:44 | ||
1001838 43.9 14.06 64.32 1822.27 TurboPack base40-nl.txt | |||
1139868 50.0 16.00 63.91 932.25 TurboVByte base40-nl.txt | |||
C Size ratio% Bits/Int C MI/s D MI/s Name File | |||
1001838 43.9 14.06 64.32 1822.27 TurboPack base40-nl.txt | |||
1139868 50.0 16.00 63.91 932.25 TurboVByte base40-nl.txt | |||
before i got | |||
401188 50.2 16.06 67.14 3997.47 TurboPack base40-nl.txt | |||
so shows a lower C size but shows more Bits/Int so i am confused | 20:45 | ||
maybe gonna try -f2t | 20:46 | ||
20:49
pyrimidine joined
|
|||
samcv | anyway 14bits instead of 16 is not too much improvement | 20:54 | |
timotimo | mh, fair enough | 21:06 | |
i've procrastinated the C code for index to codepointname | 21:15 | ||
21:21
pyrimidine joined
21:33
pyrimidine joined
|
|||
timotimo | perl6 -e 'use nqp; nqp::hllize(nqp::vmhealth).perl.say' | 21:33 | |
{"fsa sizeclass current pages" => (2, 2, 2, 5, 3, 287, 4, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0), "fsa sizeclass free elems at end" => (19, 102, 117, 26, 63, 88, 96, 68, 90, 84, 88, | |||
80, 118, 124, 121, 80, 125, 110, 118, 113, 125, 117, 122, 119, 121, 107, 119, 123, 124, 125, 126, 124, 124, 126, 124, 123, 126, 127, 127, 125, 126, 126, 127, 125, 126, 114, 127, 127, 121, 126, 125, 126, 127, 126, 127, 116, 126, 125, 0, 127, 126, 126, 127, 127, 0, 127, 127, 125, 127, 127, 126, 124, 126, 127, 125, 126, 126, 119, 125, 124, 126, 116, 126, 127, 127, 126, 125, 126, 126, 125, 127, 127, 127, 127, | |||
127, 127), "fsa sizeclass pagecounts" => (3, 3, 3, 6, 4, 288, 5, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1), "gc bytes promoted since full collection" => 0, "gc sequence number" => 0, "jit | |||
frames produced" => 14, "num threads" => 2, "spesh frames produced" => 0} | |||
^- probably not correct, these | 21:34 | ||
jnthn | Lies, damned lies, and vmhealth | ||
timotimo | like, it surely can't have 0 spesh frames produced when it jitted 14 frames | 21:35 | |
jnthn | Well, unless it spesh frames really means "spesh'd but didn't jit" | ||
timotimo | perhaps that number is only updated when something is turned on | ||
and the sizeclass stuff is quite spammy :) | |||
samcv | timotimo, this is more interesting gist.github.com/samcv/7939ad8a27e3...3ccb142385 | 21:36 | |
timotimo | oh wait what | ||
samcv | this is the codepoint index to the bitfield | ||
though 53K is still more than I think i did with a ton of if else statements | |||
timotimo | aye, it only increases that number if a spesh limit is set | 21:37 | |
now i just have to put output of that in a big script and see how things evolve | 21:39 | ||
well, it segfaults though :) | 21:40 | ||
oh, haha | 21:41 | ||
i push temp roots, but i don't pop 'em back out | |||
that's a recipe for disaster | |||
gist.github.com/timo/d58473fe86c33...b8f219f79c - my shooter example, but every 60 frames it outputs vmhealth | 21:46 | ||
24 GC runs per 60 frames, eh? :\ | |||
well, two frames without a GC, then one with ... | 21:47 | ||
MasterDuke | timotimo: yesterday i printed out sc->body->sc_idx and idx from the three *_demand_* functions. i then added an nqp::wval op and tried to print the ^name of the results of calling nqp::wval with the pairs of ids | 21:50 | |
some worked, some gave `Invalid SC index in bytecode stream` | 21:51 | ||
timotimo | right | 21:52 | |
i remember that some didn't work, but i don't remember how they b0rked | |||
MasterDuke | but i'm not confident that i gave the right arguments to wval. or if those are the two right things, is that the right order? | 21:53 | |
timotimo | hm, is fsa's current page even interesting compared to number of pages? | 21:54 | |
i don't actually think it is | |||
i might have actually used a different op from wval, come to think of it | |||
scgetobj? scgetobjidx? | 21:55 | ||
i think scgetobjidx gives you the index when you give it an object | |||
MasterDuke | wval calls MVM_sc_get_sc_object | ||
timotimo | ah, so it might be right | 21:57 | |
MasterDuke | why would some give that error? | 22:01 | |
timotimo | *shrug* | ||
jnthn | timotimo: I'd expect current page will probably always be the latest one, since when we free memory we freelist it | 22:05 | |
timotimo | right | 22:08 | |
we never free whole pages yet | |||
i wonder if it'd promote much less to gen2 if i re-used objects with a free list in perl6-space | 22:10 | ||
jnthn | Dunno...if the things only live 1 frame, they'd be collected anyway? | 22:11 | |
MasterDuke | i kind of forget where i started with this, i think it was trying to reduce the number of MVM_serialization_read_int calls. and to do that fewer things need to be *_demand_*ed. so i printed out those ids, which i can use to figure out what it is that's being demanded | ||
jnthn | MasterDuke: Many of those are 'cus of NFAs, fwiw | 22:12 | |
MasterDuke | and in that case, i should look for singletons, since those are more likely to be able to remove | ||
yeah, perl6.moarvm:<dependencies+deserialize> is about 90+% | |||
of the MVM_serialization_read_int calls | 22:13 | ||
oops,`CORE.setting.moarvm:<dependencies+deserialize>` and 70% to be correct | 22:14 | ||
timotimo | jnthn: well, enemies and bullets are on the screen for upwards of 300 frames usually | 22:17 | |
bullets less time, enemies more time | |||
MasterDuke | jnthn: given TimToady is working on NFAs, would these profiles i'm doing likely be completely invalidated when his works lands? | 22:18 | |
timotimo | i forgot to add the "nurseries filled with %d bytes" thing to the health hash | 22:21 | |
apparently i implemented it wrong because it gives me negative values :\ | |||
MVMuint64 bytes_filled = (char *)target->nursery_alloc - (char *)target->nursery_fromspace; | 22:22 | ||
is that wrong? | |||
jnthn | tospae | ||
*tospace | |||
MasterDuke: They may well change from that, yeah, and I'm kinda waiting to see how that work lands up before looking into getting rid of the dupe storage in MVMArrays, which in theory would halve it | 22:23 | ||
timotimo | the descriptions must have confused me | ||
MasterDuke | m: given $TimToady.is-working-on-NFAs { when True { @NFA-related-profiles = () } } | ||
camelia | rakudo-moar 637241: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Variable '$TimToady' is not declaredā¤at <tmp>:1ā¤------> given ā$TimToady.is-working-on-NFAs { when Trueā¤Ā» | ||
timotimo | i'm considering giving these hash keys shorter strings %) | 22:25 | |
MasterDuke | very readable, though i do like the rule (actual rule, or just idiom?) Ruby has of putting ? on the end of methods that return a bool | ||
jnthn: have any ideas for non-NFA related LHF? | 22:26 | ||
jnthn | MasterDuke: In what area? Memory usage? | 22:27 | |
MasterDuke | or cpu | ||
jnthn | Yeah...there's some places I suspect we can save a good bit of memory and thus CPU deserializing those things | 22:28 | |
Did you use moar-ha before? | |||
If you perl6 --profile=heap -e '' | |||
MasterDuke | nope. it's a module, right? | ||
jnthn | Then it'll spit out a heap profile of the stuff in memory after startup | ||
Yeah, panda install App::MoarVM::HeapAnalyzer | 22:29 | ||
Or zef | |||
Just got the former wired into my fingers still :) | |||
And it installs a moar-ha program that you can run on the profile | |||
You'll note that a bunch of memory is taken up by, iirc, Parameter objects | 22:30 | ||
Maybe some others | |||
I've pondered whether we can move some of the unusual Parameter-related bits out into another object that we reference from Parameter | |||
So that the majority of them shrink | 22:31 | ||
You might spot some other easy wins poking around at the data though | |||
MasterDuke | thanks, i'll play around with it | ||
jnthn | I wrote it primarily to help me diagnose leaks | ||
But when I was looking at the data I figured there was a ton of memory use improvements to be found in it | 22:32 | ||
MasterDuke | heh, `summary` is not instant | 22:33 | |
`top` is fast | 22:34 | ||
jnthn | Oh, it does a bunch of caching | 22:36 | |
So the first time you do certain things (like look at a partiuclar snapshot) it's costly | |||
But then it's cheaper | |||
If you do summary again it's probably comparatively fast :) | |||
path is similar; costly the first time, less so the next | |||
In fact nearly instant the next | |||
Though path is probably less interesting if you're hunting for savings; it's very useful for leak hunts though :) | 22:37 | ||
(It tells you the shortest path from a GC root to the object) | |||
timotimo | i had a branch where i was sharing some object related to parameters or scalar descriptors or something | ||
i think the latter | |||
it makes one single test fail ;( | |||
jnthn: got a reason why spesh frames created should not be counted unless the spesh limit is set? | 22:40 | ||
we don't need the value to be exact, so multithreading should be all right (and spesh is going to live on its own thread at some point anyway) | |||
jnthn | timotimo: Hm, I forget but I thought they were always counted | 22:41 | |
timotimo | at least not via this particular field | 22:44 | |
mayhaps there's a per-tc field that also counts? | |||
jnthn | Don't think so, but I forget exactly how I implemented the limit thing :) | ||
timotimo | i'll make it do the thing, then | ||
Geth | MoarVM/vmhealth: 120c3b17f7 | (Timo Paulssen)++ | src/spesh/candidate.c Count spesh_produced even without spesh_limit. |
22:50 | |
MoarVM/vmhealth: 2d9a7567e6 | (Timo Paulssen)++ | 10 files introduce vmhealth op gives moar-specific information about current state: memory in use by nursery and FSA, count of gc runs so far, number of frames speshed and jitted, bytes promoted since last full collection etc. |
|||
timotimo | github.com/timo/SDL2_raw-p6/blob/m...#L311,L323 - see if you can spot the method that creates too many objects here :P | 22:57 | |
i've made it re-use a single SDL_Rect for all those things now, and it reduced the number of gc runs to 19 every 60 frames | 23:06 | ||
MasterDuke | timotimo: will your vmhealth branch be used to make profiling better? | 23:27 | |
timotimo | unlikely | 23:32 | |
i was inspired to make it for the benefit of monitoring solutions like prometheus | 23:34 | ||
samcv | ok i have thought more about collation. so we need a way to designate if we want to reverse the sorting | ||
like swap the sorting order for case | |||
MasterDuke | timotimo: ah, cool | ||
samcv | so capitals come before lowercase versions | ||
23:35
pyrimidine joined
|
|||
timotimo | so you can just set it up for like a web app or something | 23:35 | |
samcv | not sure how that will work with the bitfield type things i have now | ||
timotimo | it'll be kind of more interesting to see something like a timeseries of GC times for minor and major collections and such | ||
samcv | 1, 2, 4, 8 | 23:36 | |
timotimo | number of open files perhaps | ||
samcv | probably want to add another integer value | 23:38 | |
MasterDuke | is an int32 smaller than an int in perl6? | 23:39 | |
samcv | so can have like unicmp_s(a, b, -4, 11 ... | ||
yeah i think so MasterDuke | |||
i think they're all 64bit | |||
jnthn | Sleep time; 'night all | 23:42 | |
samcv | yeah i'll need to do that or else i will have to come up with something crazy for the collation_level int | ||
timotimo | had no internet for a couple minutes there :( | 23:56 | |
timotimo added a freelist for enemy objects |