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:57 rakuUser left 01:03 reportable6 joined 01:11 frost joined 02:11 bisectable6 left, bloatable6 left, linkable6 left, unicodable6 left, greppable6 left, benchable6 left, tellable6 left, notable6 left, squashable6 left, releasable6 left, reportable6 left, sourceable6 left, coverable6 left, statisfiable6 left, shareable6 left, nativecallable6 left, committable6 left, quotable6 left, evalable6 left 02:12 sourceable6 joined, committable6 joined 02:13 linkable6 joined, notable6 joined 02:14 releasable6 joined 03:12 statisfiable6 joined, nativecallable6 joined, greppable6 joined 03:13 bisectable6 joined, quotable6 joined 03:14 shareable6 joined, evalable6 joined, bloatable6 joined 04:12 tellable6 joined 04:13 squashable6 joined 05:13 benchable6 joined 06:14 coverable6 joined 06:54 patrickb joined 07:12 unicodable6 joined
Nicholas good *able6, #moarvm 07:20
08:04 reportable6 joined 08:07 patrickb left 08:47 Kaiepi left, Kaiepi joined 08:53 Kaiepi left 08:58 Kaiepi joined
jnthnwrthngtn moarning o/ 09:33
Nicholas \o
09:58 evalable6 left, linkable6 left 10:16 nebuchadnezzar left 10:28 Kaipi joined 10:29 Kaiepi left
nine jnthnwrthngtn: you could have pleased that --rxtrace test by just turning --rxtrace into a noop ;) After all the test just made sure that it doesn't crash. We seem to have never promised anything more 10:45
timo yup, certainly underpromising we are, maybe not overdelivering any more this time 10:46
jnthnwrthngtn nine: Yes, but when I saw it had a negative effect on find_method I was especially keen to see it gone; that's a hot path on startup now, and startup time seems notably worse on new-disp
I was just glancing callgrind output and...hmm. Why is MVM_op_get_mark doing a bunch if branching when it could just store the mark in the MVM op info?
It accounts for 2.75% of CPU cycles on startup 10:47
timo someone smart™ could probably write a moar debugserver client that does essentially the same thing as rxtrace except perhaps with much better output; interactively introspectable output perhaps
jnthnwrthngtn *bunch of branching, although it's `if` all the way...
timo jnthnwrthngtn: i think i did that to make the op data shrink
but 2.75% is kind of astounding
jnthnwrthngtn We call it while doing inline cache building 10:48
timo i would have assumed it'd come from verifying frames
are those two bits like, in a row?
jnthnwrthngtn A lot from there also
timo we don't actually have many different marks at all, perhaps we'll want to store the mark in a thinner field than two whole bytes 10:49
jnthnwrthngtn We don't have to store the string even, we could just have an integer in the op info and use it to index a table of string constants
And there's few of them so it can just be 8 bits 10:50
nine Every single caller of MVM_op_get_mark looks at the second character. So instead of a full string, all we really need is 1 byte
jnthnwrthngtn Or less
hah :) Even simpler
timo we have like start, middle, end, maybe one more?
jnthnwrthngtn but...is that really true?
I thought some of validation would care about the first...
timo the validator should be at least storing the first byte
to compare against the next ops 10:51
nine Oh, sorry, the validator actually looks at cur_mark[0], too
timo if not, we'd be letting through some very suspect bytecode. which i guess would only really show up in fuzzing tests
nine But still, it's way less than 256 different options
jnthnwrthngtn Indeed. Anyway, it's almost 20 million (!) cycles spent there on startup, so if anybody fancies going after those... :) 10:52
timo so, callgrind counts instruction fetch, right? without cachegrind, we don't really get to find out if a memory access for an array of the values is faster or not
measuring is hard :) 10:54
nine I'd just map those 2 bytes to 1 byte internally. 3 bits for the type, 5 bits for the id is more than enough.
jnthnwrthngtn timo: yes, true 10:55
10:58 linkable6 joined 11:02 nebuchadnezzar joined
jnthnwrthngtn Hurrah, today I think we'll finally be rid of the legacy invoke protocol 11:15
11:16 tealecloud joined
Nicholas "Wake up, time to die!" 11:18
also, I keep thinking that there's some verison of Logan's Run (the film? the book?) where there are cuts to coundowns "10" "9" "8" etc (days to go), in the context of extops 11:19
jnthnwrthngtn I suspect we're as low as we're going to get on extops until the point we decide to make the final push to be rid of them 11:24
I've done all that I need for the sake of new-disp by now
11:26 Kaipi left 11:39 Kaiepi joined
Nicholas jnthnwrthngtn: in 36ff5d15a6020faa92a590dc569bf8144785f58c you write "the extops are now free of all things that are to go away as part of new-disp." but you don't seem to change any actual extops code. 11:53
this doesn't quite seem consistent to my poor befuddled brain 11:54
jnthnwrthngtn Nicholas: There was a change in src/vm/moar/ops/perl6_ops.c 11:56
Nicholas oh yes. There. I missed that. Cofnused it with the NQP code hunk above. 11:57
11:59 evalable6 joined 12:02 reportable6 left 12:03 reportable6 joined
jnthnwrthngtn I think next is 1) elimiante last usage of hllize, 2) eliminate hllize impl, 3) a replacement for nqp::isinvokable that doesn't depend on the old invoke protocol 12:05
Nicholas to check - lunch has already happened? 12:06
and beer fridge is in good shape?
jnthnwrthngtn Yes, just had lunch. Beer fridge is...OK, although I think restocking shall soon be required. 12:11
12:23 Kaipi joined 12:24 Kaiepi left
jnthnwrthngtn 1 is done. 3 is getting there. Might need a rebootstrap to do 2, and I may see if having done 3 lets me get rid of other invoke spec usages before the rebootstrap 12:56
Geth MoarVM/new-disp: a9d912b89a | (Jonathan Worthington)++ | 5 files
Add HLL-configurable lang-isinvokable dispatcher

Which will come to replace the isinvokable op, which is hopefully the final thing that currently depends on the invocation spec mechanism.
  (Since isinvokable implementations boil down to type guards, we can
expect that they'll naturally optimize away under specialization in many cases; we never got around to writing the specialization logic for isinvokable, and now get the same effect "for free" by it being a dispatcher.)		 13:02
dogbert11 jnthnwrthngtn: something tells me you're using more than four fingers when typing on the keyboard :) 13:03
dogbert11 learned to type in class several times but still falls back to using two or four fingers 13:04
jnthnwrthngtn All 8 fingers, thumb for spaces :) 13:09
And shift done by whichever hand is not typing the letter to uppercase.
timo there's a software called KMonad that lets you hella program your keyboard even if it's just a boring old usb one 13:10
jnthnwrthngtn Though curiously always the same thumb, which means my space bar is worn on one side and like new on the other one
timo so you can have the typical qmk features like one key being one thing when tapped and another when held
like having shift on each side's middle finger for example 13:11
or putting all modifiers on the home row with this mechanism
lizmat sounds like what MacOS has: keeping a letter down, gives you a menu of accented versions of that letter
timo tapping the shift key to get a left or right parenthesis
lizmat éëèêęėē
timo not sure if KMonad also supports "tapdances" out of the box 13:12
like, hold-then-tap a key for something different from tap-then-hold or tap-tap, etc etc
MasterDuke when i was programming in racket and closure i did the 'tap shift to get left or right parens' thing
timo with a 100% keyboard these things aren't "needed", but the less your hand has to travel away from home row, the faster and more ergonomic you can be, at least that's the theory
MasterDuke don't know why i don't still have that enabled
timo where did you get that from? 13:13
13:13 Ven_de_Thiel joined
MasterDuke i'm trying to remember now, i don't think it was kmonad 13:13
timo maybe it was a specific editor for the language 13:15
that's kind of a natural place to put that kind of functionality
prose / chat doesn't have all that many parenthesis unless you like smileys :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)
MasterDuke no, it was some sort of systemwide linux utility
xcape, pretty sure that was it 13:18
13:19 frost left
timo neat 13:21
duckduckgo has enormous trouble finding "xcape"
huh
okay, i searched for just xcape first, found mostly thigns called "xscape", then i used the "search for \"xcape\" only" link, which did not find xcape, only pages that mention xcape in passing, like the "alternatives to" page for karabiner or something, and then i added Linux to the search to get "\"xcape\" linux" which did not find the page, but "xcape linux" gives it as the first result 13:23
github.com/ItayGarin/ktrl - "You can think of ktrl as an attempt to re-implement QMK as a Linux daemon." 13:24
MasterDuke ha. i have no memory of how i first found it
timo probably not by knowing its name :D 13:27
getting the first and second byte of an op's mark in two separate functions may help give us a smaller and faster op_get_mark implementation than the one with a bunch of ifs, even without going the route of a table / array to hold the data 13:32
Geth MoarVM/new-disp: 2e93ba07a7 | (Jonathan Worthington)++ | src/core/interp.c
Make deprecated multi-dispatch cache op throw

Now that NQP is rebootstrapped and doesn't use it.		 13:36
nine jnthnwrthngtn: oh, you already replaced that hllize MAST::Op? 13:42
I was just gonna push that change 13:43
jnthnwrthngtn Yes
nine I'll remove hllize from MoarVM 13:44
Or rather, already have. Just running tests again
Geth MoarVM/new-disp: 587d0a2aa3 | (Jonathan Worthington)++ | 12 files
Eliminate hllize/hllizefor ops

As well as the HLL mapping implementation that they depended on, which seems to get rid of the final use of legacy invocation too.		 13:45
jnthnwrthngtn More than that...
jnthnwrthngtn Oh :)
Altai-man yay
jnthnwrthngtn Darn, I didn't know you were working on that.
Altai-man congrats, jnthnwrthngtn 13:46
nine jnthnwrthngtn: oh, you already replaced that hllize MAST::Op?
I was just gonna push that change
jnthnwrthngtn Yes
fwiw, I'm now ripping out ->invoke and similar
nine I'll remove hllize from MoarVM 13:47
Or rather, already have. Just running tests again 13:48
Geth MoarVM/new-disp: 587d0a2aa3 | (Jonathan Worthington)++ | 12 files
Eliminate hllize/hllizefor ops

As well as the HLL mapping implementation that they depended on, which seems to get rid of the final use of legacy invocation too.
jnthnwrthngtn More than that...
jnthnwrthngtn Oh :)
Darn, I didn't know you were working on that.
fwiw, I'm now ripping out ->invoke and similar
Geth MoarVM/new-disp: 569fe17f4a | (Stefan Seifert)++ | 2 files
Remove now unused legacy hllize configuration keys
jnthnwrthngtn Ah, I had missed that
nine++
nine So not all work was in vain ;) 13:49
Geth MoarVM/new-disp: 7f6e90bf93 | (Jonathan Worthington)++ | 9 files
Remove isinvokable and setinvokespec ops

The latter needs to become a no-op for now, until the next time we do an NQP rebootstrap.		 13:53
jnthnwrthngtn Thanks for doing the vast majority of the hllize replacement work :)
nine It was a really good exercise for understanding dispatchers :) 13:55
jnthnwrthngtn: feels good to remove/disable that code, doesn't it? 14:00
jnthnwrthngtn Indeed :) 14:04
At one point the amount of stuff that needed reworking felt overwhelming.
Nicholas Am I doing something wrong. My NQP is at dac798be72a32d32e8eab582a78cd2e8a37a0c60 but +++ Compiling gen/moar/stage1/NQPP6QRegex.moarvm 14:07
fails with
MoarVM op 'setinvokespec' is unknown as a core or extension op at gen/moar/stage1/QAST.nqp:1847 (gen/moar/stage1/QAST.moarvm:check_ret_val)
... 14:08
nine Yet in the end, it's always the same old "do one step after another" that gets you there
MasterDuke Nicholas: same here. did a pull and successfull build in moarvm, and then a pull in nqp, but get that error 14:12
ah, fine after that most recent nqp commit 14:13
Geth MoarVM/new-disp: d4a09e34e8 | (Jonathan Worthington)++ | 13 files
Remove legacy invocation leftovers
 14:14
MasterDuke in my scrollback, stage parse on new-disp has gone from 50s to 46.7s (don't know how far back the 50s was though) 14:16
nine: btw, you were mentioned last night colabti.org/irclogger/irclogger_lo...08-31#l239 with a subsequent question 14:21
Geth MoarVM/new-disp: 4ba017ab2d | (Jonathan Worthington)++ | 2 files
Remove some now-unused arg handling functions
 14:22
timo wasn't at some point "the way we do argument handling is unreasonably complex so the jit skips implementing some cases" a thing, and is that now fixable with the change in how arguments are passed? 14:27
it was related to autoboxing / autounboxing as i recall? plus optional parameters i guess?
MasterDuke that was prepargs, right?
timo no i think it was *param_* 14:29
MasterDuke ah
timo prepargs always came down to some kind of *invoke_* not being handled, since the stretch from prepargs to whatever-invoke-is-used was handled as one single thing
MasterDuke yep, i have two closed PRs for jitting param ops github.com/MoarVM/MoarVM/pulls?q=i...s%3Aclosed since it was more complicated than i'd realized 14:30
yep, i have two closed PRs for jitting param ops github.com/MoarVM/MoarVM/pulls?q=i...s%3Aclosed since it was more complicated than i'd realized 14:31
timo the way we invoke dispatchers is cool because it gets rid of these preparation steps
Geth MoarVM/new-disp: 5afaac7a0f | (Jonathan Worthington)++ | src/spesh/deopt.c
Update deopt to set up dispatch arg context
timo and we do invoke a lot of things via dispatchers now
jnthnwrthngtn Yes, I know there was some amount of JIT pain because it was spread over many ops before
timo github.com/MoarVM/MoarVM/blob/mast...rgs.c#L296 - returning structs from these functions was part of the issue i seem to recall 14:33
anyway, getting parameters out of the args "buffer" (which is now essentially zero-copy) still requires handling of boxing and autounboxing in cases of spec mismatches, right? 14:36
jnthnwrthngtn Yes 14:37
(And as before, spesh is able to optimize away the indirections there.) 14:46
Geth MoarVM/new-disp: 312e0593e4 | (Jonathan Worthington)++ | 8 files
Eliminate legacy args handling on callee side

This gets rid of the many bits of branching in args handling to decide between legacy and dispatch args handling, as well as making the frame data structure smaller.		 14:54
timo :+1:
jnthnwrthngtn nine: I think that we can't yet be rid of `frame->args` (and prepargs and arg_*) because JIT of nativecalls relies on them. 14:55
Or at least, it seems that way to me. :) 14:56
nine So the time comes near to look at NativeCall in a dispatch world_
?
timo possibly, though it's not on the critical path towards new-disp going in master, so it's up to whom-ever when to actually implement that 14:57
MasterDuke rough numbers, but running `sloccount src\` on master and new-disp gives 284338 and 290159 respectively 14:59
jnthnwrthngtn nine: As timo said, it won't be a merge blocker, but it will mean we can't do that final bit of cleanup / frame shrinkage, yes 15:00
nine: I suspect there's some nice speedups possible
nine Speedups in NativeCall or in general due to the frame shrinkage? 15:01
jnthnwrthngtn nine: I was thinking the former, but the latter is probably slightly true also
timo oh, what makes frames shrink? less bytecode because we're no longer compiling the nativecall bodies? 15:03
jnthnwrthngtn timo: At the moment every ->work has an area allocated on the end of it for ->args 15:04
timo: So we'll do away with those registers needing to be allocated
timo oh, that's also still in nativecallinvoke, ok 15:06
ok, i now claim it *is* on the critical path :P 15:12
15:14 rakuUser joined
Geth MoarVM/new-disp: 0bf5a3b6fd | (Jonathan Worthington)++ | 15 files
Remove leftovers of the legacy method cache

Including its lazy deserialization, which going by the code comments removed along with it was a source of no small amount of pain.		 15:23
Nicholas commit a8898a70e604abce75a7c85e066677d6c41e8cf4 - yes, it was such a sweet and lovely thing. 15:26
jnthnwrthngtn RIP
IT OUT!
15:27 linkable6 left
Nicholas you killed my [insert a better joke than I can think of right now] - prepare to die 15:27
15:27 squashable6 left
[Coke] Nicholas: "my dispatcher" seems apropos. 15:28
and almost scans.
Nicholas yes.
15:28 linkable6 joined
Nicholas but also, I still vaguely remember that code - "to the pain". and it's more "you killed my nemesis - prepare to be hugged" 15:29
jnthnwrthngtn Once ->args goes, ->cur_args_callsite goes with it, so every frame is two pointers smaller
nine No tear shed here over seen that one gone :)
Nicholas lizmat: commit a8898a70e604abce75a7c85e066677d6c41e8cf4 -- Note that deserialize_method_cache_lazy() is cruel and unforgiving. 15:30
it might be relevant for the weekly.
15:30 squashable6 joined
Nicholas and now commit 0bf5a3b6fdbb18db6225152709407a8582f146bd 15:30
15:30 linkable6 left
jnthnwrthngtn I think I've run out of stuff to rip out and have to resume fixing/optimizing again :) 15:30
Nicholas or language class? 15:31
jnthnwrthngtn Teacher has holiday today
Nicholas oh. That's sort of \o/ as that's good for us. Assuming you're still on a roll.
jnthnwrthngtn Oh, and that happens on Thursday, and it's only Wednesday, I think.
Nicholas oh I'm confused. I thought that it was Wednesday. But I'm not that good at rememberign these things 15:32
All mornings seem the same.
15:33 linkable6 joined
nine And since it's always morning... 15:36
jnthnwrthngtn It seems that t/spec/S32-io/dir.rakudo.moar and t/spec/S03-junctions/autothreading.t are both cases of the same thing 15:37
Nicholas all mornings are equal, but some mornings are more equal than others. And next week, oh great, school restarts, which means hardcore getting up early. 15:41
jnthnwrthngtn Hmm. This is a tricky one.
(In a nutshell: junction named args)
(To multis) 15:42
We use bind failure to mean "move along to the next candidate", but in the case of junction named args we'd like to auto-thread... 15:43
I guess it's possible to detect that we might hit such a situation (due to Any or narrower typed named args in the signature), and insert a "try autothreading on bind failure" thingy into the multi dispatch plan 15:54
Then we can skip over it if there's a callsame or whatever 15:55
But the dir one is weird because...why does it try to auto-thread there... 15:57
m: .say for dir(none(".","..")) 16:01
camelia none((".cpanm".IO ".local".IO ".npm".IO ".perlbrew".IO ".rcc".IO "Perlito".IO "evalbot".IO "log".IO "nqp-js".IO "p1".IO "p2".IO "perl5".IO "std".IO ".bashrc".IO "mbox".IO ".cpan".IO "dalek-queue".IO "rakudo-j-inst-1".IO "rakudo-j-1".IO "rakudo-j-inst-…
jnthnwrthngtn I...don't know that we expect that to auto-thread at all 16:02
oops
m: .say for ".".IO.dir(test => none(".",".."))
camelia none((".".IO), ("..".IO))
Nicholas forgive my naive teddy-bear level understanding, but I thought that none() was something to do with junctions, and that junctions thread, but, I don't remember enough about junctions to know whether none is (sort of like) xor (which can't short-circuit) whereas and and or can... 16:04
jnthnwrthngtn m: .say for dir(test => none(".", ".."))
camelia none((".".IO), ("..".IO))
jnthnwrthngtn That's the evaluation I meant to run before
Yes, none is a kind of jucntion 16:05
I guess there's two things here: 1) I've busted threading over junctions that are passed as named args, 2) unrelatedly, I've discovered that the `test` argument to `dir` is of type Any, whereas it may be more useful were it of type Mu 16:06
(2 is a question for master, not new-disp)
Well, it's related in that both cases trigger the thing I need to fix, I'm just a bit surprsied about `dir` 16:07
lizmat: Dunno if you have opinions on ^^
Nicholas because if it were Mu, the juntion would be passed to it as-is, rather than the calling code having to iterate over the junction, pass the "bits" down to lots of calls, and then build a junction return result frmo the calls? Beacuse docs.raku.org/images/type-graph-Mu.svg 16:12
jnthnwrthngtn Yes 16:13
And more importantly, it'd apply the junction against the filename in question
Which would give useful results
nine jnthnwrthngtn: a call to &return should happen even in inlined frames, right? It's just that there should be a local handler for the control exception which will put the result into some register and let us continue 16:17
jnthnwrthngtn Yes 16:18
I think we also try to rewrite those throws into gotos
nine If it's &return that was inlined 16:21
If our inlinee just calls &return, there will be a throw
jnthnwrthngtn Yes, then it should all happen through exception handling 16:22
nine Apparently it just can't find the handler
The plot thickens as timo++ likes to say. 16:31
FH (0), i.e. the inlinees frame handler that should catch this control exception ends at the sp_dispatch_o r8(3), lits(raku-rv-decont), ... op which is the one that dispatches to &return.
If I add some code _after_ the return in the sub, the error goes away 16:32
jnthnwrthngtn ooh, is it gonna be another inclusive/exclusive bug?
nine exactly
jnthnwrthngtn You know, maybe the current discrepancy in semantics between positionals and named args with regards to multiple dispatch and junctions is just crazy and I shouldn't even try to replicate it 16:33
When there's a far easier solution
Which is to just handle it like positional ones: if there's no match, it's a failover at the end 16:34
Then I "just" have to make multi-junction-failover deal in named args too 16:35
timo the funniest thing about junctions in named arguments is 1) ordering 16:48
nine That MVM_EX_CAT_RETURN handler may be a bit hard to reach: {start_offset = 4294967295, end_offset = 4294967295, category_mask = 32, action = 1, block_reg = 19, goto_offset = 4294967295, label_reg = 19, inlinee = 0} 16:50
Maybe it's not an off-by-one error but rather it's shy cousin, the off-by-4-odd-billion 16:52
timo inflation, eh? 16:53
my history teacher told us that at one point they were getting wheelbarrows full of pointers and before giving them out to people they would write a bunch of zeroes at the end with sharpie 16:54
lizmat jnthnwrthngtn: looks like changing the sig for :test to Mu would be the easiest thing, no? 17:01
jnthnwrthngtn lizmat: Yes, it'd need doing in the sub and method
lizmat oddly, the method version already has Mu 17:02
timo interesting since one of the results jonathan showed was the method version 17:03
nine I think it's indeed an off-by-one error, when setting up the control flow graph. We remove the active handler and then process the instruction 17:09
Or something like that 17:12
lizmat github.com/rakudo/rakudo/commit/21a7117dbe # jnthnwrthngtn
jnthnwrthngtn Neat
Geth MoarVM/new-disp: 99bf756123 | (Jonathan Worthington)++ | 4 files
Additions for guarding with named args also

  * A way to get the total number of arguments, both positional and named,
   which can then be accessed as a flat view in order to access both the
   prim spec and value
  * Liberalize dispatch program construction and compilation to allow for
   guards to be placed on named args
This works out fine because dispatch programs are always relative to a given callsite shape, and names - and their order - form part of the shape.		 17:29
jnthnwrthngtn Seems we're down to 1 failing spectest file :) 17:40
(With a push I'm about to do)
Yup, only t/spec/S05-modifier/counted-match.t remains failing 17:42
So 1 spectest, 1 test, and reinstating inlining for Raku multis/methods.# 17:43
And...all the stuff the ecosystem needs :)
And...the thing nine++ is hutning.
Home time o/ 17:44
17:46 evalable6 left, linkable6 left, linkable6 joined 17:47 evalable6 joined
lizmat jnthnwrthngtn ++ 17:58
[Coke] I think we still have the nativecall failures on windows when running with TEST_JOBS > 1
I will do a run today to check
(doing it now) 18:02
I haven't done a windows build in a few weeks.
18:02 reportable6 left 18:12 tealecloud left
[Coke] several compiler warnings on windows about casting 18:13
will try to grab those also
gist.github.com/coke/65fafa7206e21...bdd8a57a20 - (right now just the warnings) 18:19
(one of those is in 3rdparty, I know) 18:28
Yup, ativecall tests still failing when run concurrently (and it seems sporadic) 18:35
(that is, while many tests fail each run, I don't think it's the same ones each time) 18:37
also pseudostash.t fails (but I think that's failing everywhere for me, on master, on osx..>)
Nicholas it is, but I can't remember why it's failing
18:44 tealecloud joined 18:49 tealecloud left
[Coke] yup, definitely not the same tests failing each time. 18:53
Maybe it's some first-come, first-win thing. 18:54
would precomp be involved in any of those tests?
lizmat perhaps of helper test libraries ? 18:56
[Coke] though I guess if it was precomp, it would get better over multiple runs, or at least be consistent which ones failed once they had a bad run. 18:58
lizmat yeah, one would expect gthat
*that
[Coke] Happy to try debugging as time permits. last time I was unable to get a failing run into a debugger since it required the concurrency issues.
anyone has any suggestions, all ears. 18:59
timo .o( activecall ) 19:06
19:16 discord-raku-bot left 19:17 MasterDuke left 19:22 MasterDuke joined, gfldex left 19:24 Ven_de_Thiel left
lizmat . 19:24
nine I have got a fix and it's truly wonderful! But I do not have enough space in this line to describe it.
lizmat there's more lines -) 19:25
nine Actually I would have hade enough space as it's really just the deletion of 2 lines of code, very much akin to github.com/MoarVM/MoarVM/commit/29...7fe83daea1 19:26
It's the "why" that will take more :)
lizmat correclty :-) 19:28
vrurg nine: A Great Fermat Fix... 19:31
19:39 gfldex joined
nine :) 19:41
Better commit it right away
19:46 tbrowder left, tbrowder joined 19:52 discord-raku-bot joined 19:54 linkable6 left
Geth MoarVM/new-disp: 4cb37ce1c0 | (Stefan Seifert)++ | src/spesh/graph.c
Fix return in inlined frame not getting cought

When a frame containing an explicit return was inlined, but the &return sub was not inlined into said frame, the control exception thrown by that return was not getting cought. This led to errors like inifinite loops in JITed code or
  "return outside a routine".
... (10 more lines)		 19:55
20:05 reportable6 joined
timo damn when do we fail to inline &return? 20:12
jnthnwrthngtn
.oO( *sigh* Is there a distribution that's basically Ubuntu but without snaps? )
 20:13
Nicholas I'm roughly aware of what snaps are, but what's the pain with them?
nine Or why it should be like Ubuntu ;) 20:14
Nicholas and I don't know if the answer is "go upstream - Debian" or if there's some downstream Ubuntu derivative with naps purged.
nine timo: MVM_SPESH_NODELAY=1 is good at creating such edge cases
MasterDuke i use kubuntu on my laptop and don't seem to run into them 20:16
jnthnwrthngtn Nicholas: It was updating Chrome automatically, and doing so in such a way that it suddenly starts to SIGABRT on new tabs, so I told it "no, don't do that", and now it gives me 14 days of warnings that it's going to update Chrome before doing the same bloody thing. That and the kubectl one keeps losing its config files.
*Chromium I guess
I mean, I guess I can find another way to install these things, I just wish the answer was still "apt" 20:17
nine++ # another nice fix
MasterDuke i pretty much just always use apt 20:18
nine jnthnwrthngtn: do you have any memory about why there was a distinction between control and catch handlers in the cfg builder? Those were two fixes that were really just removing the 2 halfs of that distiction 20:20
timo maybe because most handlers don't catch control? or the default resume behavior perhaps? 20:21
nine The distinction was there to restrict which handler blocks got edges drawn to. But that would require that we actually know which type of exceptions the covered code could throw, which we don't in the case of invocations. 20:22
japhb jnthnwrthngtn: Linux Mint is basically Ubuntu with no snaps (and a generally friendlier disposition). I get Chromium and FF via normal apt updates. 20:25
jnthnwrthngtn japhb: Ah, that's good to know; thanks. 20:26
japhb (Actually, I usually use the panel tray icon, because Mint's updater pays attention to what type of update it is (security, kernel, misc, ...) and has a helpful "look at the changelogs before deciding" view)
But it's all apt underneath.
(And I still do apt installs on the command line, because why not?) 20:27
When I installed the first version of Mint after Ubuntu went all in on snaps, the installer had a big warning that's like "WE'VE TURNED OFF SNAP. IF YOU WERE EXPECTING SNAP, GO READ THE BLOG POST ABOUT IT." 20:28
jnthnwrthngtn nine: Actually having read the commit more carefully now I'm not sure how nice of a fix it is... 20:30
nine: Initially, we kept every exception handler alive by adding an edge from the entry BB 20:31
That meant that we could never ever remove one
At some point, I noticed that if you, for example, killed an entire branch (due to constant folding), then we couldn't delete any handlers inside of that. 20:32
nine jnthnwrthngtn: interesting timing. I was just going through it again because I got doubts
jnthnwrthngtn Yeah, my "nine++" was actually before reading the code and just skimming the message :)
Nicholas neuralize it with rebase? :-) 20:33
jnthnwrthngtn Anyway, I think for catch handlers, inlining restrictions meant we'd never ever see enough to eliminate them in realistic situations anyway
nine I think the real bug is still there and just verified it. We're missing edges from the blocks covered by the handler. My commit just works around that
jnthnwrthngtn But with control exceptions many of them are thrown in a lightweight way.
That we can rewrite into gotos
Anyway, the goal was to add edges to the handler from every covered BB
If all *those* go away, then the handler is covering nothing 20:34
Such is the theory
MasterDuke are there any plans for future control exception optimizations? i know tux thinks next/last/etc are what's currently slow about his test-t 20:35
jnthnwrthngtn And yes, missing edges - perhaps thanks to inlining - may be related, although I think we *also* refuse to throw away blocks inside an inlinee
It's possible we're losing them in some other way
Or that there's a construction bug in the graph in the first place, but that seems less likely
Anyway, I think the catch handler opt-out was because a more accurate set of edges didn't stand to win us anything 20:36
nine For one, the cfg builder only considers dispatch_* ops, but not the spesh versions thereof
jnthnwrthngtn Oh?
I'm sure I remember teaching graph.c about runkfunk and runbytecode 20:37
nine You did for variable arguments, but not for handlers
jnthnwrthngtn Hm, handlers, or just BB terminators? 20:38
nine github.com/MoarVM/MoarVM/blob/new-...aph.c#L728
jnthnwrthngtn I may be confusing my CFG implementations, but I thought the handler edge insertion was driven by BB boundaries (e.g. "end of covered region BB means edge")
nine BB terminators are fine
jnthnwrthngtn Oh, we're trying to be clever and only put edges where we think we need 'em, huh... :) 20:39
Yeah, I forgot that; the last project I worked on where I did a fresh CFG and similar impl, I didn't do that, just shoved 'em on ever block in the try region :) 20:40
*every
I wonder if that simplicity loses us anything 20:41
Or rather, if trying to be clever wins us anything
nine That seems actually be the real cause of the bug :)
jnthnwrthngtn Yay. Did you make it add the edges unconditionally, or add the extra ops? 20:43
Geth MoarVM/new-disp: e3f77ed4f4 | (Stefan Seifert)++ | src/spesh/graph.c
Revert "Fix return in inlined frame not getting cought"

This reverts commit 4cb37ce1c0e4fc1f24fa4f89f2ed49bf7c2e2f72.		 20:44
MoarVM/new-disp: 42d3b8af4d | (Stefan Seifert)++ | src/spesh/graph.c
Fix return in inlined frame not getting cought

When a frame containing an explicit return was inlined, but the &return sub was not inlined into said frame, the control exception thrown by that return was not getting cought. This led to errors like inifinite loops in JITed code or
  "return outside a routine".
... (8 more lines)
nine Now the graph looks the way I like it to :)
Nicholas is this another commit/revert pair to "fix in post" ? 20:45
20:45 tealecloud joined
nine yes 20:45
jnthnwrthngtn Wow, somebody other than me did a spello. :)
Nicholas if it wasn't clear, this is actually a serious suggestion - I am assuming that new-disp will get rebased. And at that point, take out the adjacent pairs of commit/oops.
nine oops 20:46
jnthnwrthngtn Nicholas: It's a good idea, now whoever does the rebase just needs to remember :) 20:48
20:50 tealecloud left 20:56 linkable6 joined
jnthnwrthngtn For some reason I thought t/02-rakudo/18-pseudostash.t was going to be tricky to debug. Turns out...if I read the comment in the test it told me pretty much what'd need changing! 21:06
So, clean `make test` 21:07
And one failing file in `make spectest`
That one *does* look like an awkward debug; if anybody fancies some golfing...
[Coke] is it just straight golfing with a new-disp rakudo? I can throw some cycles at that. 21:11
which test?
jnthnwrthngtn t/spec/S05-modifier/counted-match.t 21:13
[Coke] ... I do not think all these things I put in this glass make a manhattan. blech. 21:16
ah. perhaps I used 5x too many bitters, which is.. yup. That's it. 21:18
jnthnwrthngtn I'm...guessing it tastes bitter?
jnthnwrthngtn knows almost nothing about making cocktails 21:19
MasterDuke heh. i was going to make a manhattan this evening, but my vermouth is getting a bit old
i do however love angostura, so i go heavy on the bitters
[Coke] does booze expire? :)
MasterDuke not most, but since vermouth is just fortified wine it can 21:20
[Coke] drinking a manhattan in honor of a friend, and I'm afraid I've just ruined this one. Ah well, will try again.
vrurg In a couple of hundred years everything would expire...
MasterDuke easy solution though, just add 4x more bourbon and hope you don't have to drive anywhere soon
[Coke] HA 21:21
... ok, manhattan & coke, that has taken the edge off the bitters.
MasterDuke well, they've drunk wine from ancient greece/rome that wasn't terrible because it was completely sealed
21:30 Altai-man_ joined
vrurg MasterDuke: really? I've only heard of non-drinkable findings. 21:32
[Coke] ok, I can get the test failing, will golf a bit. 21:33
MasterDuke hm, i could have sworn i'd read of something found that was tried relatively recently (past year or so), but now i can't find the article. dunno, maybe i'm mistaken 21:37
[Coke] "aa" ~~ m:nth(any(1))/./; "aa" ~~ m:nth(any(1))/./; 21:40
japhb wonders what the oldest find was where someone went "Hey, I wonder what that tastes like!"
[Coke] the strings can be different, but there has to be two consecutive matches against junctions. 21:41
any junctions seem to trigger it.
that is, any kind of junctions, not specifically any() junction. :)
guessing maybe something is getting accidentally reused when junctions are involved? 21:43
MasterDuke well, i know they've definitely tasted honey found in pyramids
timo i'd try to taste the background radiation of the universe if that made any sense 21:44
MasterDuke wouldn't that be easy? just stick your tongue out?
[Coke] Nah, it's all gone locally. 21:46
dogbert11 the assertion triggered when running t/spec/S32-io/io-cathandle.t with MVM_SPESH_NODELAY and a small nursery is github.com/MoarVM/MoarVM/blob/new-...eopt.c#L32 21:53
22:02 Altai-man_ left 22:06 Altai-man left
Geth MoarVM/new-disp: 5d1dc330b7 | (Jonathan Worthington)++ | 3 files
Ensure args proc setup/cleanup gets inlined

It doesn't account for many cycles, so removing the calling overhead is worth it.		 22:09
MasterDuke jnthnwrthngtn: the change in find_method_qualified, that's faster? istr a large speedup when compiling custom operators a long time ago by switching to nqp::findmethod
jnthnwrthngtn MasterDuke: nqp::findmethod will usually be faster now, *but* it'll be faster when there's a monomorphic or polymorphic site; this one is clearly megamorphic in any non-trivial application 22:11
(highly variable in both type and name) 22:12
MasterDuke *only* be faster when there's a monomorphic or polymorphic site?
jnthnwrthngtn Yes 22:13
MasterDuke ah, interesting
jnthnwrthngtn There's something in place to handle megamorphic in method name but relatively stable in type already in place...
Which helps with, for example, the protoregex site
Startup time is going to be...an interesting battle.
We've saved deserializing big method caches (yay) 22:14
But have gained deserializing some full meta-objects that we maybe didn't have to before, and the callgrind output (under MVM_6model_get_how) pretty much confirms it 22:15
No less than 25% of current startup time is underneath that
MasterDuke btw, not new-disp related, but as i mentioned to timo yesterday, github.com/faster-cpython/ideas/is...dated-desc has a bunch of stuff about improving startup for python that might provide inspiration
and other non-startup things 22:16
timo i haven't checked in a little while, but at some point we executed a boatload of empty class and role bodies upon startup. like, all the exception classes for example 22:19
[Coke] jnthnwrthngtn: does that :nth golf help? (I didn't feel like I trimmed much.) 22:24
jnthnwrthngtn [Coke]: Kinda in that it shows that it's not dependent on other stuff in the test file etc. 22:29
Too tired to dig more into it today, I think
afk for a bit
23:06 linkable6 left, evalable6 left 23:08 linkable6 joined 23:09 evalable6 joined 23:24 tealecloud joined 23:28 tealecloud left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!