github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 05:51
nine sena_kun: you do know about MoarVM/tools/release? 07:14
tellable6 nine, I'll pass your message to sena_kun
jnthn morning o/ 09:00
sena_kun o/ 09:01
nwc10 \o 09:02
jnthn After further consideration, I decided that constant arguments won't go into callsites after all; we'll just stick with the names of named arguments doing that. 09:59
It'd lead to an explosion in the number of callsites, and significantly complicates capture handling. 10:00
Instead, callsites will gain a "this is a literal" flag. This will be possible to set on an object argument too.
Which means we can do it on a QAST::WVal, for example. 10:01
Well, on the value that comes from one.
lizmat class method call simplification, I guess ?
jnthn Well, if you have Foo.new then it would know that type guards on Foo don't need to be added 10:02
lizmat right
which they are now, right ?
jnthn It's hard to answer that, because the new dispatch mechanism that we'll use for method calls doesn't exist today :) 10:03
If the code is hot enough, spesh already knows a wval doesn't need guarding. 10:04
But this means we'd do a bit better pre-spesh, and give spesh a guard it doesn't need to eliminate.
Well, not give... :)
lizmat :-) 10:06
Geth MoarVM/new-disp: 76c4844b83 | (Jonathan Worthington)++ | 8 files
Add callsite flag for literal argument

Which shall be used as part of the new dispatch mechanism, to know when it need not actually guard an argument.
10:41
timotimo i just learned about io_uring, which is like a ring buffer where you can push requests for syscalls to happen in and get results from syscalls out and you can submit a whole bunch of syscalls with one call 12:39
and you can even have a symbol for a to-be-created file descriptor (a "pre-registration") so you can submit an open, a read, and a close in one fell swoop
we'll likely not do much with that ourselves, but libuv will probably put that in at some point 12:40
what's perhaps more interesting is the potential of pushing eBPF programs along with your syscall requests
imagine reading a zstd compressed file with a "single syscall", yum! 12:41
MasterDuke yeah, i've been reading about it on and off recently 12:42
dogbert17 jnthn: will your new dispatch mechanism improve things wrt e.g. R#2002 You've written a lot of interesting stuff in your response. 13:47
linkable6 R#2002 [open]: github.com/rakudo/rakudo/issues/2002 [dispatching][performance] `where` in single `multi` vs. `sub` is 10x slower
jnthn Not by itself, but it'll be a bit easier to fix those cases, I think 13:55
dogbert17 Nice, there are a couple of bugs reported wrt dispatching, didn't know if you had looked at them recently 13:57
jnthn If it's about the exact semantics of multi dispatch, that's not really on my radar 14:05
I'm changing the way we cache outcomes rather than the way we make decisions.
Geth MoarVM/new-disp: 82a38cecc1 | (Jonathan Worthington)++ | 9 files
Add callsite flag for literal argument

Which shall be used as part of the new dispatch mechanism, to know when it need not actually guard an argument.
16:39
MoarVM/new-disp: caca374811 | (Jonathan Worthington)++ | 17 files
Add an inline caching mechanism

This allows us to cache stuff against bytecode instructions. The main goal is that we shall use it for dispatchers to cache guards and their outcomes there. However, to test out the mechanism and try to get it stable, we first use it to cache getlexstatic_o lookups, which before now only stop needing to be looked up after specialization. (We'll also be able to get spesh to stop logging this instruction and instead just have it pull the resolution out of the cache.)
MoarVM/new-disp: 5aae7a41f0 | (Jonathan Worthington)++ | 3 files
Wire dispatch ops up to dispatch cache

Which just pushes the NYI a step further forward for now.
17:00
timotimo very interesting 17:09
jnthn Time for a break after doing that lot. :) Next is to figure out the new capture/argument stuff. 17:10
tellable6 2020-05-05T16:59:40Z #raku-dev <AlexDaniel> jnthn perhaps another opportunity to reject a feature that nobody is asking for: github.com/Raku/problem-solving/issues/188
AlexDaniel yeah, very unfortunate timing on that one… 17:11
sorry :)
jnthn haha
Will look at it in a bit. 17:12
[Coke] can someone explain to me what 'buffertocu' is doing? What's a CU? 19:37
... compilation unit?
nine yes
Load bytecode from memory 19:38
MasterDuke timotimo, nine: have you seen this? pretty cool julialang.org/blog/2020/05/rr/
[Coke] it just loads it, it doesn't execute?
MasterDuke tl;dr: "In Julia 1.5, which will be released in a few weeks, there is now a new command line flag --bug-report=rr that will automatically create and upload an rr recording." 19:39
nine [Coke]: correct. With the exception of the deserialization frame. We run that when we load bytecode 19:40
MasterDuke: neat
[Coke] nine: github.com/Raku/nqp/commit/39b348c6c9 is a very minimalistic doc for that. Thanks. 19:49
the trunc and extend ops return the modified value, yes? 19:53
timotimo yeah 19:54
[Coke] in both cases, the opcode modifier is the target size? (if so, what's the passed in size?) 19:57
nine [Coke]: it's not adding to a compilation unit. It will create a completely new one and fill it with the stuff from the bytecode. I.e. this is used when you run a script or EVAL (i.e. non-precompiled code). Rakudo compiles your source to QAST. Then QASTCompilerMAST compiles this to MBC which it collects in a buffer (int8 array). It then passes this buffer to MoarVM to get a compilation unit that's ready for 20:01
tellable6 2020-05-05T19:51:42Z #raku-dev <tbrowder> nine that commit fixed issue #147--i owe you a test file. thanks!
nine execution.
[Coke] does it return that CU to the user? 20:02
s/to the user/from the opcode/ ?
tbrowder nine: although it looks like you did that, too! 20:05
nine [Coke]: yes 20:52
tbrowder: err...yes