[00:03] *** reportable6 left [00:04] *** reportable6 joined [00:43] *** frost joined [01:25] ¦ MoarVM/new-disp: 49624aeabd | (Timo Paulssen)++ | src/jit/graph.c [01:25] ¦ MoarVM/new-disp: legojit capturepos* ops and capture*named* [01:25] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/49624aeabd [01:26] i forgot if these go away or something but right now they were high in the bailer leaderboards [01:26] isfalse_s is also very strong [02:10] *** linkable6 left [02:10] *** evalable6 left [02:12] *** evalable6 joined [03:12] *** linkable6 joined [05:38] *** unicodable6 left [05:38] *** reportable6 left [05:38] *** coverable6 left [05:38] *** nativecallable6 left [05:38] *** tellable6 left [05:38] *** bloatable6 left [05:38] *** evalable6 left [05:39] *** unicodable6 joined [05:40] *** coverable6 joined [05:40] *** reportable6 joined [05:41] *** evalable6 joined [05:41] *** tellable6 joined [06:02] *** reportable6 left [06:04] *** reportable6 joined [06:04] good *, reportable6 [07:41] *** nativecallable6 joined [08:04] *** tealecloud joined [09:37] jnthnwrthngtn: coffee! [09:39] *** bloatable6 joined [10:10] perhaps he's run out of coffee [10:14] oh noes. I hope not. [10:19] *** tealecloud left [10:20] that would indeed be a disaster [10:23] m: my $str = "3.0/2"; my $num = +$str; [10:23] rakudo-moar b451f89b6: ( no output ) [10:24] *** tealecloud joined [10:24] m: my $str = "3.0/2"; my $num = +$str; say $num [10:24] rakudo-moar b451f89b6: OUTPUT: «1.5␤» [10:24] looks innocent enough [10:25] try running it under new-disp with MVM_SPESH_NODELAY=1 [10:26] m: say 15.002 / (15.002 + 80.654 + 8.536 + 1.558); [10:26] rakudo-moar b451f89b6: OUTPUT: «0.141863␤» [10:26] hello timo :) [10:27] m: say (15.002 + 80.654 + 8.536 + 1.558) * 0.003 [10:27] rakudo-moar b451f89b6: OUTPUT: «0.31725␤» [10:27] i'm trying to make my achievement from yesterday seem bigger [10:28] the 0.3% of time spent in that one function was all in stage MAST, so i'd like to express it as a fraction of stage mast instead of a fraction of the whole core setting compilation [10:29] m: say 0.31725 * 100 / 15.002 [10:29] rakudo-moar b451f89b6: OUTPUT: «2.114718␤» [10:29] i think this is the percentage of stage mast that the function was taking before i made it basically go away? [10:30] * timo crawls out of bed, shambles across the hallway moaning "prrraaaaaiiisseeeeee ... prrraaaaaiiisseeeeeee ..." [10:30] *** squashable6 left [10:32] *** squashable6 joined [10:37] Hurrah, coffee [10:37] \o/ [10:38] I do appear to have slept the whole morning...darn cold. [10:38] Hm, do I see speedups in the backlog... :) [10:39] *** sena_kun joined [10:39] you seem to be suggesting that "after the morning" exists - this cold seems to be causing you to hallucinate :-( [10:40] timo: Yes, the MAST section of the features page can go. And the roadmap could sure use an update... [10:40] * sena_kun does bumps [10:40] 2021-09-08T17:27:35Z #moarvm sena_kun merged the Data::Record, Kind::Subset::Parameteric, Trait::Traced prs [10:43] coffee FTW [10:43] timo: I suspect fetching the ops we use often into &func is probably going to be reasonably good compared to the lookups every time; not sure there'll be much more to win with any custom dispatcher magic [10:45] timo: The JITting you added is certainly worthwhile; those are used in implementing dispatchers quite a lot [10:50] there's now an nqp pull request for the lookup movement [10:50] there's still some in there that could go into the global scope like null and set and such [10:50] but i have the feeling that we've got a list_b or two with a whole lot of entries [10:54] unless we're actually creating a list now and serializing it t get it out with a wval [10:55] oops the PR doesn't compile lmao [10:57] *** MasterDuke_ joined [10:57] hmm, I wanted to do a run with zef this time to get more info, but zef --config-path=data/zef-config.json update took 7 minutes and is still not finished. :/ [10:57] timo: did I see you say that only the js backend uses directives? [10:58] i did say that! please tell me if i'm wrong? [10:58] IIRC, that’s how I implemented getting the right file name and line number into the rakudo backtraces [10:59] interesting. i did not see any place that actually sets that dynamic variable [10:59] outside of vm/js/ [10:59] timo: The appraoch looks sensible to me [11:00] Though yeah, please make sure it doesn't break anything :D [11:00] Hm, maybe the implementation has changed since? [11:00] Oh, what about in rakudo? [11:00] when did you do that? i seem to recall it was only a month or two ago? [11:00] i believe i looked there as well [11:01] Implement directives? That was ~2016 [11:01] oh, haha [11:02] Probably the first largish thing I did [11:02] '/home/timo/perl6/install/bin/nqp-m' --module-path=blib --ll-exception --target=mbc --output=blib/Perl6/Actions.moarvm gen/moar/Actions.nqp [11:02] list_b op with 384 blocks [11:02] But feel free to optimize it, I think it’s been untouched since then [11:02] when something is executed once instead of 385 times, it's *gotta* have an impact! [11:03] So if the dynamic variable can be removed that would be great [11:06] the metamodel has 412 blocks, can't wait to see what the core setting has to offer [11:08] 17.3k blocks :D [11:09] 17.3k blocks oughta be enough for everybody [11:14] i'm doing a little timing for before/after moving the lookup out of the loop for list_b [11:18] m: say my $b = 1631272404295393032 - 1631272404295036551; say my $a = 1631272616735221172 - 1631272616704178601; say 100 * $b / $a [11:18] rakudo-moar b451f89b6: OUTPUT: «356481␤31042571␤1.148361713␤» [11:19] m: say 1631272739972972185 R- 1631272741032432729 [11:19] rakudo-moar b451f89b6: OUTPUT: «1059460544␤» [11:19] m: say 31042571 / 1059460544 [11:19] rakudo-moar b451f89b6: OUTPUT: «0.0293003559␤» [11:19] haha, i improved something that takes a little less than a thirtieth of a second in the core setting stage mast [11:20] but i made it almost 100x faster [11:21] The accumulation of marginal gains can yield noticeable results [11:22] the other improved ops are much much harder to measure since they are called a whole lot more often and then i'll be reaching "too much overhead for measuring" territory [11:23] I think anything that doesn't harm code quality (and this arguably improves it anyway) and gives a measurable, even if tiny, win is worth it; they add up. [11:25] Especially when added up over all people using Raku. :) [11:26] m: say 7926346 / 1059460544 [11:26] rakudo-moar b451f89b6: OUTPUT: «0.0074814924␤» [11:26] 0.0075 seconds off of the install_core_modules task :) [11:27] which took 20.58 seconds in total [11:33] +++ Cleaning up MOAR [11:33] rm -f -- [11:33] [...] [11:34] inst-perl6-debug-m.o .o .o .o .o .o dynext/libperl6_ops_moar.so [11:34] someone *really* wants .o gone [11:40] i'm running a spec test to be extra sure [11:42] *** MasterDuke_ left [12:02] *** reportable6 left [12:04] *** reportable6 joined [12:15] it passed, but i forgot about the spec test run until now :D [12:42] no new findings in Blin so far. the modules we prepared PRs for should be bumped for the fixes to be visible, but other than that all the hard things left. [12:42] I'm running one with zef now. [12:43] 4 modules, 1 needs a PR and 3 others are hard, from less deps to more deps: hide-methods, DateTime::Timezones, HTML::Canvas. [12:44] maybe running with zef will uncover something too [12:44] *** frost left [12:45] sena_kun: any idea what's wrong with hide-methods ? [12:45] to check, if I understand "4 modules, 1 needs a PR and 3 others are hard" - that means just 3 modules left to investigate, that are broken by new-disp but work on master? [12:45] lizmat, that's a question for jnthnwrthngtn I'd say. [12:45] what is the error mode? [12:46] Nicholas, well, AFAIK they are "investigated", it's just that to create a fix is hard. [12:46] lizmat, # Failed test 'could B.bar not be found now' [12:48] hmmm... if does use ^find_method [12:49] lizmat, it's a diff between master and new-disp, so it is a matter of new-disp to be resolved I believe. [12:50] ok, then I won't touch hide-methods until jnthnwrthngtn tells me I should fix something :-) [12:52] i guess this is the real troublezone: [12:52] # cannot use nextcallee because that would refer [12:52] # to the original method that got wrapped. [12:52] if $class.^mro[1].can($name).head -> &nextone { [12:52] nextone(SELF, |c) [12:52] } [12:55] i wonder what makes the optimizer's visit_children so expensive. is it just that it's called so often, or is it something like "the istype if/else cascade is not optimal for the typical distribution of types" or something [12:56] *** tealecloud left [12:57] *** tealecloud joined [13:06] 13498 Stmts 1st [13:06] 17642 Block [13:06] 18600 typecheck [13:06] 37405 Want [13:06] 43675 Xval or vm [13:06] 56221 Stmts 2nd [13:06] 113632 wval [13:06] 308335 Op [13:06] 323898 Var [13:07] the order they are in is op, want, var, block, stmts 1st, stmts 2nd, regex, wval, typecheck, xval or vm [13:08] *** brrt joined [13:09] so want is a whole lot earlier in the checks than it tends to appear (in the core setting), op and var could be switched but it's not a big difference, wval or vm wants a lot earlier [13:14] good * #moarvm [13:16] hello brrt [13:16] timo: I'd not invest too much time in Perl6::Optimizer as I'm not sure it'll survive in its current form beyond rakuast [13:16] ah i guess that's a good point :) [13:17] Of course, easy wins like reordering those branches by usage is fine [13:17] o/ brrt [13:17] sena_kun: Wow, so we're really down to just 4 modules broken? :D [13:17] the most expensive code frame showing up in my perf reports is MATCH followed by _ws, then termish, then !alt [13:17] not sure i can actually get any performance out them as easily [13:18] (Well, aside from those using nqp::ops where we've decided it's SEP...) [13:18] SEP? [13:18] Somebody Else's Problem [13:18] oh, that was about modules, right [13:19] yes :) [13:19] i should also mention of course that MVM_interp_run has like 7.82% so that's frames that aren't jitted [13:19] so those just don't show up in the measurements as individual entries [13:19] jnthnwrthngtn, well, tbh I am not fond of pakku output with some modules, I am trying zef but the update seems to be still running after... 36 minutes and so I cannot run it. So it still a possibility there are more of them, of course. But maybe not by a lot. [13:20] timo: does that imply that we JIT 92% of runtime? [13:20] (or that 92% of the runtime, is JITted code?) [13:20] or am I reading that number entirely wrong [13:21] brrt: I have an op sp_resumption which at runtime is just meant to do the same as `null` (e.g. null out one register), but it has a bunch of other operands...in the lego JIT it was easy to just make it JIT like `null`, when I tried to copy the `null` template in the EXPR JIT I got an error from the template compiler. [13:21] well, that's not inclusive [13:22] brrt: Dunno if you've time/interest to have a poke at it; I'm guessing it's something small/silly [13:22] I have time and interest :-) [13:22] it literally just means time spent directly in interp_run. the next functions are frame_dispatch, disp_program_run, nqp_nfa_run, fixed_size_alloc, spesh_arg_guard_run, allocate_frame [13:22] ah, okay [13:23] and any other downstream functions, too, I presume [13:23] brrt: OK, then new-disp branches in moar/nqp/rakudo, copy-paste the template for null and change the name to `sp_resumption`, compile and then run probably anything in Rakudo [13:23] iirc it was an oops [13:23] ah [13:24] only 220 commits away from master... [13:30] oh, I was far behind with that branch [13:30] hey, isn't that an implicit goto though? [13:31] no, it has varargs registers [13:36] looks like reordering did not make a measurable difference so *shrug* [13:47] brrt: Varargs regs, but they don't matter at all here [13:47] I think it is this: 'MoarVM oops in spesh thread: Can't add constant for operand type 18' [13:47] Looks familiar [13:56] I ... think I know that code :-) [13:57] that would be MVM_reg_uint16 probably [14:00] Ah, just something the template compiler doesn't know about? [14:08] brrt: do you isfalse_s or do i? [14:10] do we get a little node that negates an int register perhaps? [14:16] maybe i'll introduce MVM_JIT_RV_INT_NEGATED [14:27] *** MasterDuke_ joined [14:29] timo: I was doing some experimenting with jitting isfalse_s recently, by changing the c function to take a flag whether or not to negate the result (some other similar function in the same file does the same thing), but my rough testing showed it to be slower [14:30] But istr it was difficult to find good test raku code [14:30] well, i made the return value mode now that negates the value [14:30] Might want to search the logs, I may have given some more details then [14:31] that shouldn't make it slower in general [14:31] after jitting isfalse_s did anything commonly replace the bail with something else? [14:32] *** MasterDuke_ left [14:33] *** MasterDuke_ joined [14:33] Yeah, that’d probably be better. Don’t remember why I didn’t try implementing that [14:34] Might be able to simplify whatever that other op was too [14:36] https://twitter.com/davidrevoy/status/1436332029768081412 - cool we have a nice illustration of it now [14:37] oh, did you have other ops where the negation would be helpful? [14:38] also it's impressive that we negate an integer by issuing test + setnz + movxz + final mov to the target register [14:39] MVM_coerce_istrue has a ‘flip’ parameter that you might be able to remove [14:43] that is kind-of API, though [14:47] How do you mean? The nqp op doesn’t have that parameter [14:49] Ha, look at src/spesh/optimize.c:1221 that can be simplified (using the existing flip argument), fine as is if the arg gets removed [14:50] MVM_blahblah that are exported can be considered API that users of moarvm could use [14:51] i'm on new-disp, the lines don't line up [14:52] Oh it’s gone there, I guess part of that whole coerce_* turned into dispatchers [14:53] ¦ MoarVM/new-disp: 325625c74f | (Bart Wiegmans)++ | 2 files [14:53] ¦ MoarVM/new-disp: [JIT] Compile MVM_reg_uint16 constants [14:53] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/325625c74f [14:58] dispatch_n isn't jitted, which is used for nqp-numify [14:58] sorry, i meant sp_dispatch_n [15:21] Oh...I thought all the sp_dispatch_* were [15:21] I suspect that's easy to rectify [15:28] brrt++ # that was an easy one [15:29] brrt: Bytecode invocation is now a single op (`sp_runbytecode_*`) rather than a sequence of ops, which maybe will open the way to expr JIT of that too [15:29] Or at least remove one pain point [15:33] *** evalable6 left [15:33] *** linkable6 left [15:37] I can have a look at some (later) time [15:44] No hurry at all. :) They are done (by nine++) in the lego jit already [15:45] :-) [15:45] time for dinner! [15:45] Enjoy [15:45] brrt: but nine is on holiday for the next 10 days [15:46] nudge nudge :-) [15:48] hehe [15:48] nudge received [15:52] *** MasterDuke_ left [15:53] *** brrt left [16:03] oh, his timing is excellent [16:03] ASAN is very excited, and the only thing that changed was 1 commit on MoarVM [16:05] .tell brrt You've made ASAN very excited! http://paste.scsys.co.uk/595856 [16:05] Nicholas, I'll pass your message to brrt [16:05] compiling the core setting [16:12] ¦ MoarVM/new-disp: 4bcc5a0e88 | (Jonathan Worthington)++ | src/core/args.c [16:12] ¦ MoarVM/new-disp: Remove always-false null checks [16:12] ¦ MoarVM/new-disp: [16:12] ¦ MoarVM/new-disp: There will always be at least one callstack record below an executing [16:12] ¦ MoarVM/new-disp: frame record, and if that is a region start, it means there's a whole [16:12] ¦ MoarVM/new-disp: region of records prior to it. Spotted by mlschroe++. [16:12] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/4bcc5a0e88 [16:13] not really in a position to test that. building a non ASAN build to see whether valgrind also gets excited [16:16] grmbl, I tested it before rebasing with brrt's PR and now more core setting build fails with "stack smashing detected" [16:18] ah, I see what's wrong [16:18] you're doing better than I am [16:19] .oO( Smashing stack, grommit ) [16:20] ¦ MoarVM/new-disp: c0320b0818 | (Jonathan Worthington)++ | src/jit/expr.c [16:20] ¦ MoarVM/new-disp: Survive varargs ops in the expression JIT [16:20] ¦ MoarVM/new-disp: [16:20] ¦ MoarVM/new-disp: They can have more operands than the maximum for non-vararg ops, which [16:20] ¦ MoarVM/new-disp: could lead to buffer overruns. [16:20] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/c0320b0818 [16:21] if it makes more sense to rebase to fix this cleanly, please do it. I'm not going to come visit and wave a pitch fork in frustration, even though I *think* I probably can actually travel to you with one without hitting security theathre [16:21] Naughty fingers typed "bugger overruns", glad I caught that before pushing. [16:21] .oO( it is better to be buffered ) [16:22] oh, my, varargs. The thing that (if I vageuly remember) the x86_64 ABI says have the argument count in a register. That regular functions do not. [16:22] At least, IIRC, you can't safely cast one to the other and have it work [16:22] Nicholas: varargs MoarVM ops, not ABI varargs, thankfully [16:22] ah OK. phew [16:22] They don't imply having to do C-level varargs calls [16:23] Mixed feelings on the rebase; the reason that the commit introduced a SEGV was more that it uncovered another shortcoming, rather than being in itself wrong [16:24] yes, then I think don't [16:24] "it should have worked" rather than "whoops, goof" [16:25] um, oops, ASAN even more excited [16:26] now in NQP. (twice, due to parallel make) [16:26] Oh, curious. Maybe I didn't understand the expr jit code as well as I thought then... [16:26] Curious, my Rakudo build completed fine :) [16:27] er, two different backtraces. [16:28] gen/moar/stage1/nqpmo.moarvm is http://paste.scsys.co.uk/595858 [16:29] lol [16:30] er, no, I'm confused, they are the same i think [16:30] Just before that [16:30] /* A HACK. [16:30] lol [16:30] OK, I can fix this easily [16:31] again, "you're doing better than I am" [16:31] I'm told that it's time to eat. So & [16:32] ¦ MoarVM/new-disp: ebfd4d5d6e | (Jonathan Worthington)++ | src/jit/expr.c [16:32] ¦ MoarVM/new-disp: Ensure at least 2 slots in expr JIT operands array [16:32] ¦ MoarVM/new-disp: [16:32] ¦ MoarVM/new-disp: It relies on this when compiling inc_i/dec_i ops. [16:32] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/ebfd4d5d6e [16:33] *** evalable6 joined [16:33] That should do it [16:34] Happy nomming [16:34] *** linkable6 joined [16:57] *** sena_kun left [17:49] *** leont left [17:50] *** leont joined [18:02] *** reportable6 left [18:04] *** reportable6 joined [18:13] *** brrt joined [18:24] ¦ MoarVM/new-disp: 29b67875bd | (Jonathan Worthington)++ | 3 files [18:24] ¦ MoarVM/new-disp: Better sp_bindcomplete handling on inline [18:24] ¦ MoarVM/new-disp: [18:24] ¦ MoarVM/new-disp: Instead of making it block an inline, we can simply delete it, since if [18:24] ¦ MoarVM/new-disp: we're inlining then (at least for now) we know it will be a no-op. [18:24] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/29b67875bd [18:24] ¦ MoarVM/new-disp: 4f2b0bef8e | (Jonathan Worthington)++ | src/spesh/disp.c [18:24] ¦ MoarVM/new-disp: Propagate value result facts in dispach programs [18:24] ¦ MoarVM/new-disp: [18:24] ¦ MoarVM/new-disp: This means that dispatchers that resolve to the identity function - such [18:24] ¦ MoarVM/new-disp: as hllize - will not end up losing the facts known about their input. [18:24] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/4f2b0bef8e [18:28] Curiously, getting dispatch program translation to not insert guards if we already have facts about types proving the guard isn't needed leads to a SEGV in NQP compilation. [18:30] Will have to track down why; that should be a trivial opt to do. (And while in theory we could eliminate those guards later, their insertion involves an SSA version split, which is quite expensive.) [18:30] Though it seems we aren't always deleting proven guards either, and evidently aren't doing so in these cases. [18:31] Time for food/rest [18:33] *** tealecloud left [19:11] *** tealecloud joined [19:26] *** brrt left [19:32] *** brrt joined [19:43] brrt: jnthnwrthngtn fixed the thing that .tell will tell you about [19:44] jnthnwrthngtn: now somewhere in spectest with your most current MoarVM [19:45] o [19:45] 2021-09-10T16:05:09Z #moarvm brrt You've made ASAN very excited! http://paste.scsys.co.uk/595856 [19:45] huh [19:45] see scrollback. your change hit a bug [19:46] er, log. [19:46] ah, I see it [19:47] broken assumptions were broken; MVM_MAX_OPERANDS no longer made sense [19:52] my C89 heart is a little disappointed by the variable size array [19:52] but I'll accept [20:32] sp_bindcomplete also showed up regularly on the bailed jit messages [20:40] ¦ MoarVM/new-disp: 32e0c279f7 | (Timo Paulssen)++ | 3 files [20:40] ¦ MoarVM/new-disp: implement negating return values for c functions, isfalse_s [20:40] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/32e0c279f7 [20:46] Nicholas: Does that mean no ASAN excitement? [21:08] jnthnwrthngtn: there are some bugs lurking in new-disp [21:09] e.g. try running: while MVM_SPESH_NODELAY=1 ./rakudo-m -e 'sleep 1; sub f($str) { my $num = +$str; }; f "3.0/2"'; do :; done [21:16] *** tealecloud left [21:38] Type check failed in binding to parameter 'nu'; expected Int but got Rat (3.0) [21:38] this error? [21:51] timo: yes [21:51] *** brrt left [21:59] ok so we've got the check istype($result, Int) && istype($denom, Int) and that calls Rat.new, otherwise we call infix: with the two numbers [21:59] and it is in fact calling Rat.new here [22:01] i can't seem to get the code of interest into the spesh log, let's see ... [22:03] ah, haha [22:03] i was ctrl-c'ing during the "sleep 1" of the next run [22:03] so the code had in fact not happened yet [22:06] I snuck the 'sleep 1' since it helped reveal the problem quicker [22:34] when i have time i'll have to rr this i'm afraid [22:51] *** evalable6 left [22:51] *** linkable6 left [22:52] *** evalable6 joined [22:54] *** linkable6 joined [23:54] *** coverable6 left [23:54] *** tellable6 left [23:54] *** linkable6 left [23:54] *** unicodable6 left [23:54] *** benchable6 left [23:54] *** releasable6 left [23:54] *** nativecallable6 left [23:54] *** sourceable6 left [23:54] *** bloatable6 left [23:54] *** statisfiable6 left [23:54] *** bisectable6 left [23:54] *** reportable6 left [23:54] *** evalable6 left [23:55] *** tellable6 joined [23:55] *** benchable6 joined [23:57] *** nativecallable6 joined [23:57] *** coverable6 joined