Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
00:02
reportable6 left
00:05
reportable6 joined
01:28
frost joined
02:03
nine left,
nine joined
04:54
squashable6 left
04:57
squashable6 joined
05:06
squashable6 left
|
|||
Nicholas | good *, #moarvm | 05:44 | |
05:49
kjp joined
|
|||
japhb | Good *, Nicholas | 05:57 | |
06:03
reportable6 left
06:05
reportable6 joined
|
|||
nine | Better *, all | 06:11 | |
08:08
squashable6 joined
09:00
japhb left
09:12
japhb joined
|
|||
jnthnwrthngtn | moarning o/ | 09:21 | |
Nicholas | \o | ||
nine | jnthnwrthngtn: in github.com/MoarVM/MoarVM/commit/8b...b8ffaebdbb you added the deopt pre ins and deopt synth annotations. Presumably the deopt pre ins annotation is there to contain the correct deopt destination PC. But the deopt synth annotation contains the index that the materializations are registered for. | 10:04 | |
In the failing example, all stacked guards deopt to the same: -> pc 218 | 10:09 | ||
But I don't know if that's coincidence or if that will always be true. In the latter case I wonder what the pre deopt ins annotation is needed for | 10:10 | ||
jnthnwrthngtn | Any guards stacked up ahead of a runbytecode, be they a product of dispatch program translation or of ensuring we can link a specialization or inline, should deopt to immediately before the dispatch op | 10:14 | |
Which is why it's a pre-deopt point | |||
Which is why it's a pre-deopt point | 10:15 | ||
We also dispatch_o is a curious case: | |||
dispatch_o .d w(obj) str callsite :cache :deoptallpoint :predeoptonepoint :maycausedeopt :specializable :postlogged :deoptonepoint | |||
It actually has every kind of deopt point. | |||
nine | This looks like the synt points already will use the index of a pre-deopt point: ann->data.deopt_idx = predeopt_index; So why then add an additional deopt-pre-ins annotation? | ||
jnthnwrthngtn | 1. predeopt because if the guards stacked up ahead fail we need to deopt to before the dispatch instruction | ||
1. predeopt because if the guards stacked up ahead fail we need to deopt to before the dispatch instruction | 10:16 | ||
2. deoptonepoint for if we inserted a return value guard afterwards | |||
3. deoptallpoint for global deopt | |||
nine: Oh, I see what you mean...totally missed that it was doing that when I first read | 10:18 | ||
Maybe that's not needed, given we just add the synth one in src/spesh/disp.c | 10:19 | ||
10:19
brrt joined
|
|||
Nicholas | good *, brrt | 10:22 | |
brrt | \o Nicholas | 10:24 | |
does jnthn have is normal name again | |||
not yet... | |||
MasterDuke | timo: github.com/MoarVM/MoarVM/blame/mas...ion.c#L960 might be something for you | 10:55 | |
jnthnwrthngtn | Yay, enough megamorphic handlers done that the rather involved Agrammon application now never fills up a dispatch cache. | 11:09 | |
Well, on the use case I threw at it, anyway | 11:11 | ||
11:26
brrt left
11:36
brrt joined
|
|||
Geth | MoarVM: MasterDuke17++ created pull request #1571: Fix some of the things found by the clang static analyzer |
11:59 | |
12:02
reportable6 left
|
|||
Geth | MoarVM: d12d6f35cb | (Daniel Green)++ | src/6model/reprs/MVMCapture.c Add some context to capture arg exceptions Say what op they were thrown from (if any) and include both the given and allowed values. |
12:31 | |
MoarVM: 7b5b6bad77 | MasterDuke17++ (committed using GitHub Web editor) | src/6model/reprs/MVMCapture.c Merge pull request #1566 from MasterDuke17/add_some_context_to_capture_arg_exceptions |
|||
MoarVM: b3e14b1512 | (Daniel Green)++ | src/profiler/configuration.c Add default case when determining an operand size Otherwise GCC at the -O2 optimization level warns that `size` may be used uninitialized. |
12:32 | ||
MoarVM: 4293ea853a | (Daniel Green)++ | src/strings/ops.c Silence a GCC warning at optimization level -O2... by twice moving a conditional in MVM_string_index outside a loop, so it won't potentially be used uninitialized. I think it couldn't actually happen, but this is probably a little faster also. |
|||
MoarVM: d48a5a4129 | MasterDuke17++ (committed using GitHub Web editor) | 2 files Merge pull request #1570 from MasterDuke17/fix_warnings_found_by_gcc_at_O2_optimization_level |
|||
MoarVM/master: 4 commits pushed by (Daniel Green)++, MasterDuke17++ | 12:36 | ||
13:03
reportable6 joined
14:03
linkable6 left,
evalable6 left
14:04
evalable6 joined
14:16
frost left
15:05
linkable6 joined
15:09
brrt left
|
|||
timo | the moarvm talk just ended half an hour ago? | 15:32 | |
MasterDuke | did anyone here register to listen/attend live? some of the other talks looked interesting too, but i couldn't quite justify the cost | 15:37 | |
btw, the clang static analyzer found a lot more things than those couple i fixed, i just took the ones that were really easy to verify | 15:38 | ||
jnthnwrthngtn | I survived the talk. And some questions afterwards. :) | 15:44 | |
It was recorded and I believe the video will be out later today | 15:47 | ||
MasterDuke | nice | 15:53 | |
if anyone wants to repro, it was really easy, i just did a configure and make clean, then `scan-build make -j12` | 15:58 | ||
sena_kun | jnthnwrthngtn++ | 16:00 | |
timo | later today sounds great | 16:12 | |
16:15
patrickb joined
16:17
patrickb left
16:59
vrurg left
17:04
vrurg joined
|
|||
[Coke] | jnthnwrthngtn: doing the work, talking the talk... | 17:28 | |
17:43
linkable6 left
18:02
reportable6 left
18:05
reportable6 joined
|
|||
timo | sliding the slides | 18:32 | |
Nicholas | drinking the tea | 18:39 | |
aha, but more | |||
punning the puns | |||
I believe that's more important round here. | 18:40 | ||
lizmat was punning in court for 4 hours today | 18:46 | ||
apart from being in the car for 5+ hours today | 18:47 | ||
lizmat is very tired and calls it an early day | 18:48 | ||
Nicholas | that doesn't sound that fun | ||
lizmat | no, it wasn't, but at least it was hopefully the last time in this case | ||
& | |||
timo | casing the case | 18:51 | |
[Coke] thinks the last time he was in court, he punned a juror. | 18:58 | ||
Nicholas | so where on bittorrent is this talk video then? :-) | 19:00 | |
timo slaps th emule | 19:02 | ||
Nicholas | I suspect that at some point we might find it here www.youtube.com/channel/UCwG9512Wm...6Iqshz4Dpg | 19:04 | |
MasterDuke | "now that's a name i haven't heard in a long time" | 19:06 | |
timo | hope someone set up a camera on a tripod in an empty theater :P | 19:08 | |
gotta see the newest moarvlm flick as soon as it comes out | |||
MasterDuke | timo: btw, why is it that some small scripts create gigantic profiles? is that just a limitation of how we collect profile data? or is it indicative of something non-optimal happening when rakudo/moarvm run the code? | 19:12 | |
[Coke] | Nicholas linked to the channel, is this one the talk? youtu.be/dQw4w9WgXcQ | 19:13 | |
Nicholas | :-) | ||
score! | |||
timo | MasterDuke: probably all my fault :) | 19:36 | |
MasterDuke | i guess that calls for 3 smacks with a wet noodle, as my grandmother would say | 19:37 | |
timo | cruel o_O | ||
MasterDuke | i guess it depends on whether they're ramen or udon | 19:38 | |
timo | canneloni perhaps | ||
MasterDuke | for example, on a branch of Text::Diff::Sift4 that reverts a bunch of converting stuff to nqp ops, profiling `use Text::Diff::Sift4; my $a; for "words_1k.txt".IO.lines -> $word { $a := sift4($word, "testing") }; say now - INIT now` creates something like a 16mb sql file | 19:42 | |
timo | i think we still have that thing where we accidentally record recursions instead of loops under certain circumstances involving inlining | 19:43 | |
MasterDuke | while on master (which doesn't change any overall structure, just uses nqp ops in a bunch of places, using a 10k file only creates a 578k html file | ||
hm, that sounds a little familiar. i don't remember if there was a proposed fix though? | 19:44 | ||
the sift4 code doesn't have any explicit recursion | 19:45 | ||
timo | right | ||
MasterDuke | ha! 16mb on that branch normally. 330k on that branch with MVM_SPESH_INLINE_DISABLE=1 | 19:47 | |
and runtime is only 0.27s | 19:48 | ||
19:53
evalable6 left
|
|||
timo | i might actually put in a "don't do this optimization if profiling is turned on" so we get correct profiles until i fix it properly | 19:54 | |
MasterDuke | well, inlining is so good for performance it might significantly throw off total runtime measurements | 19:59 | |
do you know how to fix it? | 20:00 | ||
timo | i've got to hope :P | 20:06 | |
not every inlining causes the problem, only some specific cases | 20:08 | ||
so i would only disable some inlinings, or even better, some secondary optimization | |||
20:46
linkable6 joined
|
|||
jnthnwrthngtn | I wonder if the optimization where we rewrite exception handling to goto (which can happen over inline boundaries) fails to correctly handle leaving of the inline | 20:47 | |
MasterDuke | the kind of exception handling that's used to implement `last`? because i do use that in the code | 20:49 | |
timo | i believe that's the one, yeah, jnthnwrthngtn | 20:50 | |
jnthnwrthngtn | MasterDuke: It may manage that, yes | 20:51 | |
timo | did you continue the code that puts info about inline caches / morphism-amount in the profiler output? | ||
jnthnwrthngtn | I think it does control exceptions mostly (that doesn't have an exception object) | ||
timo: I didn't get it to output the SQL yet | 20:52 | ||
timo: But the JSON makes it into the HTML output, so "just" needs me (or somebody else!) to remember how to JavaScript + Angular | |||
Geth | MoarVM: MasterDuke17++ created pull request #1572: Lego jit implementation of nqp::abs_i |
||
timo | oh, is it pushed up already? | 20:53 | |
jnthnwrthngtn | The MoarVM bit is, and I think it automatically makes it into the JSON blob as a result | ||
627c92ccb00 in MoarVM | 20:54 | ||
timo | cool, i'll have a look while waiting for your talk's VOD or something :) | ||
20:54
linkable6 left
|
|||
jnthnwrthngtn | The profiler UI is the only thing I ever wrote in Angular; the next web app I needed to make I did in React, and then I decided I vastly preferred it. :) | 20:55 | |
(Preferred React, to be clear.) | 20:56 | ||
afk for a bit | |||
timo | yeah, react somehow makes more sense to me as well. perhaps a lot of that is how angular split things into components and modules or something like that? didn't get my head wrapped around that at that point, but react is a lot more explicit about where things come from | 21:03 | |
japhb | jnthnwrthngtn: Well, to be fair, the creators of AngularJS seemingly preferred something else as well (since Google went "Dear me, don't use AngularJS, use Angular2 instead -- it's a complete ground-up rewrite! Everything's different! We swear it's better now!") | 21:19 | |
Even within Google, those of us on the "consumer" side of those frameworks looked askance across the campus at the "producer" side. | 21:20 | ||
I think my personal reaction was something like "Fool me once ..." | 21:22 | ||
timo | "askance"? | ||
do we have vscode users in here? i can't seem to find a list of commits in the VCS panel? | 21:23 | ||
japhb | www.dictionary.com/browse/askance | 21:24 | |
(Not being a jerk -- it's actually a pretty clear definition) | |||
timo | i see | ||
japhb wonders if the suspicion variant was based on the sideways look variant -- because you wanted to at least keep things you couldn't trust in your peripheral vision, and subtly check on them every so often | 21:26 | ||
timo | jnthnwrthngtn: i thought we wanted the info about mono/poly/mega in a separate place that's per-routine rather than per-callgraph-node | 21:52 | |
21:55
linkable6 joined
|
|||
timo | no recording yet, huh? | 23:36 | |
23:55
evalable6 joined
|