github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 pamplemousse left 00:30 Kaiepi left, Kaiepi joined 01:19 pamplemousse joined 02:59 pamplemousse left 04:29 farcas1982regreg joined
nwc10 good *, #moarvm 05:51
06:56 pilmihilmi joined 07:03 samcv joined 07:05 MasterDuke joined 07:09 sivoais left, moritz left 07:13 Geth left, Geth joined
nine sena_kun: you do know about MoarVM/tools/release? 07:14
tellable6 nine, I'll pass your message to sena_kun
07:15 jjatria joined, sivoais joined, moritz joined 07:21 sivoais left 07:22 sivoais joined 07:26 farcas1982regreg left 07:47 zakharyas joined 07:48 sena_kun joined 08:07 Kaiepi left 08:08 Kaiepi joined 08:52 sena_kun left, sena_kun joined
jnthn morning o/ 09:00
sena_kun o/ 09:01
nwc10 \o 09:02
09:07 Altai-man_ joined 09:09 sena_kun left
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
10:29 dogbert17 joined, timotimo left, dogbert11 left 10:30 timotimo joined
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
10:41 farcas1982regreg joined 10:52 squashable6 left 10:53 squashable6 joined 11:07 sena_kun joined 11:09 Altai-man_ left 11:15 farcas1982regreg left
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
12:46 pilmihilmi left 13:07 Altai-man_ joined 13:09 pamplemousse joined, sena_kun left 13:45 squashable6 left, squashable6 joined
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.
14:17 farcas1982regreg joined 15:07 sena_kun joined 15:09 Altai-man_ left 16:07 farcas1982regreg left
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
17:07 Altai-man_ joined
timotimo very interesting 17:09
17:09 sena_kun left
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
17:44 zakharyas left 19:08 sena_kun joined 19:09 Altai-man_ left 19:20 lucasb joined 19:33 zakharyas joined
[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
20:59 Kaiepi left, Kaeipi joined, Kaeipi left 21:00 Kaeipi joined 21:01 zakharyas left 21:07 Altai-man_ joined 21:09 sena_kun left 21:14 Altai-man_ left 22:29 lucasb left 23:29 squashable6 left 23:30 squashable6 joined, squashable6 left 23:31 squashable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!