|
01:56
MasterDuke joined
|
|||
| MasterDuke | hm, trying to remember where i left off. so there was some type information attached to the sub parameter, but it was lost by the time spesh was using the facts it knew about... | 02:05 | |
| timo | i'm thinking it's the connections from BB0 to the interesting BBs that cause version 0 of the register from being mixed into the one we're interested in | 02:17 | |
| MasterDuke | is version 0 always a problem? is that a generic thing that could be improved? | 02:19 | |
| timo | it's been a long time since I looked at why we set these connections up, the one from BB 0 to other BBs | 02:21 | |
| MasterDuke | i guess there always has to be some connection, right? anything passed in and used has to be accounted for | 02:26 | |
| timo | hm? | 02:27 | |
| BB 0 is kind-of fake, and so are versions 0 of the registers I think | |||
| MasterDuke | oh, hmm | ||
| timo | as i recall it was made to cover situations we didn't properly handle yet, so that we don't optimize things we can't without breaking things | 02:29 | |
| i'm finally putting in the first command that actually uses data from inside the rrdb | 02:30 | ||
| MasterDuke | i must admit i haven't looked at your commits too closely. is there an actual database involved? | 02:32 | |
| timo | yes, an sqlite3 database | ||
| MasterDuke | nice | 02:33 | |
| timo | one thing it could do in theory is track all object pointers backwards through GC runs, but the data it takes to have all of that is relatively large, and recording all these events also takes a good amount of time | 02:34 | |
| MasterDuke | sqlite3 is one of those things i want to use all the time. zstd is another | ||
| timo | (so i put in a flag you can pass to the command that skips recording that) | ||
|
02:37
guifa_ left
|
|||
| MasterDuke | ugh...i'd hoped to do some more work on this iter boolification, but i can feel myself crashing. and this chair is nice for sitting, but somewhat surprisingly not so good for sleeping. hopefully can get some time tomorrow | 02:39 | |
| later...and then will also look at your gdb commits, i definitely like the idea of doing more to make the debugging experience better | 02:40 | ||
| timo | later! | 02:41 | |
|
02:45
MasterDuke left
02:50
coverable6 left,
unicodable6__ left,
sourceable6 left,
quotable6 left,
shareable6 left,
greppable6 left,
tellable6 left,
evalable6 left,
committable6 left,
linkable6 left,
nativecallable6 left,
huggable6 left,
notable6 left,
releasable6 left,
bisectable6 left,
bloatable6 left,
benchable6 left
02:53
committable6 joined,
coverable6 joined,
greppable6 joined
02:54
unicodable6 joined,
bloatable6 joined,
nativecallable6 joined,
benchable6 joined,
bisectable6 joined
02:55
notable6 joined,
quotable6 joined,
linkable6 joined,
releasable6 joined,
shareable6 joined
02:56
evalable6 joined,
sourceable6 joined,
huggable6 joined,
tellable6 joined
|
|||
| timo | creating the rrdb for a process that ran for 427.54s (though admittedly many threads working in parallel) took half an hour ... the rr replay is 1166571 events long | 02:59 | |
| m: say 1166571 / 60 | 03:00 | ||
| camelia | 19442.85 | ||
| timo | m: say 1166571 / (60 * 30) | ||
| camelia | 648.095 | ||
| timo | 650 events per minute? oof. not very good huh. | ||
|
04:35
releasable6 left,
linkable6 left,
coverable6 left,
unicodable6 left,
committable6 left,
tellable6 left,
evalable6 left,
nativecallable6 left,
benchable6 left,
quotable6 left,
notable6 left,
coverable6 joined,
releasable6 joined,
linkable6 joined
10:42
guifa_ joined
12:49
guifa_ left
12:59
guifa_ joined
13:55
guifa_ left
14:35
guifa_ joined
14:46
shareable6 left,
huggable6 left,
sourceable6 left,
bloatable6 left,
linkable6 left,
bisectable6 left,
coverable6 left,
releasable6 left,
greppable6 left
14:48
shareable6 joined
14:49
greppable6 joined,
bloatable6 joined,
nativecallable6 joined,
quotable6 joined,
linkable6 joined
14:50
unicodable6 joined,
sourceable6 joined,
huggable6 joined,
tellable6 joined,
releasable6 joined
14:51
bisectable6 joined,
benchable6 joined,
notable6 joined,
committable6 joined,
coverable6 joined
14:52
evalable6 joined
15:28
guifa_ left
16:26
guifa_ joined
18:20
guifa_ left
18:29
guifa_ joined
18:32
MasterDuke joined
18:34
guifa_ left
|
|||
| MasterDuke | i thought i would try some larger examples than just my microbenchmark to see if those iter facts ever get propogated, so i added some prints and built rakudo. in `iter_facts()`, there are a bunch of times when it knows the type and sets MVM_SPESH_FACT_ARRAY_ITER. but then in `analyze_phi()`, `common_flags & MVM_SPESH_FACT_ARRAY_ITER`is never true, | 18:35 | |
| even though `common_flags` is a ton | |||
|
19:34
MasterDuke left
20:37
vrurg joined
20:39
vrurg_ left
21:07
MasterDuke joined
|
|||
| MasterDuke | here's an example. BB 16 of 'symbol' (which i believe is `method symbol` in `QAST::Block`) has a known hash iter. but in `analyze_phi()` the only BBs where it looks for an iter in 'symbol' are: 3, 10, 12, 14, 19, 20, 21, and 22 | 21:10 | |
| i guess i'm not sure why we only look for an iter in `analyze_phi()`. i guess that's kind of what was removed in that commit i linked before, more targeted optimization of iters | 21:22 | ||
|
21:29
MasterDuke left
|
|||
| timo | what do you mean by "only look for an iter in analyze_phi"? | 22:21 | |
| the only thing about iters there that i can see is just debug output | 22:22 | ||
|
22:42
bisectable6 left,
bloatable6 left,
unicodable6 left,
notable6 left,
tellable6 left,
releasable6 left,
huggable6 left,
linkable6 left,
sourceable6 left,
quotable6 left,
evalable6 left,
benchable6 left,
shareable6 left,
coverable6 left,
nativecallable6 left,
committable6 left
22:46
greppable6 left
22:48
unicodable6 joined,
linkable6 joined
22:49
evalable6 joined,
shareable6 joined,
bloatable6 joined,
greppable6 joined
22:50
coverable6 joined,
tellable6 joined,
sourceable6 joined,
benchable6 joined
22:51
nativecallable6 joined,
releasable6 joined,
committable6 joined,
quotable6 joined,
bisectable6 joined,
notable6 joined,
huggable6 joined
|
|||