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:04 reportable6 left 00:07 reportable6 joined 00:18 dogbert17 joined 01:35 frost joined 03:12 linkable6 left, evalable6 left 03:13 linkable6 joined 03:14 evalable6 joined 03:46 MasterDuke left 04:46 linkable6 left, evalable6 left 06:02 reportable6 left 06:04 reportable6 joined 08:49 evalable6 joined
Nicholas good *, #moarvm 09:00
lizmat Nicholas o/ 09:20
09:34 CaCode joined
jnthnwrthngtn o/ 09:34
Nicholas \o 09:37
09:47 linkable6 joined
dogbert17 I guess that morning coffee has been consumed? 10:02
10:02 CaCode_ joined 10:05 CaCode left
Geth MoarVM/new-disp-nativecall-libffi-Azure-hack: 6c46f64fb5 | (Nicholas Clark)++ | azure-pipelines.yml
XXX Azure CI should fetch new-disp-nativecall for NQP and Rakudo

This is a hack.		 10:05
MoarVM: nwc10++ created pull request #1597:
New disp nativecall libffi azure hack		 10:06
Nicholas Somewhat WTF - that's failing t/02-rakudo/reproducible-builds.t because of this: 10:24
2021-11-10T10:16:02.7865401Z /bin/sh: 1: moar: not found
2021-11-10T10:16:02.8229601Z The spawned command 'moar --dump before.bc > before.dump' exited unsuccessfully (exit code: 127, signal: 0)
nine Nicholas: that is not the cause of the test failure but a result of it. This dump code only gets run on test failure and I'm not terribly surprised that it doesn't work on Windows 10:26
Nicholas yes, I'd just started to figure that out.
anyway, I don't know how to figure out whether the CI failures on that branch are "meaningful" 10:27
The reason I tried it was that I figured that no-one has done a Win32 build yet 10:28
so if it gets to "build and all nativecall tests pass on Win32" that's probably good enough
nine It is odd that reproducible-builds.t fails so often. I know that there must be an issue. Could be that the code changes just incidentally make them more visible. After all reproducible-builds.t precompiles NativeCall (just because it's a largish module with dependencies and is readily available) 10:30
Is there a more reliable way to call the moar executable? The dumps the test tries to create could be interesting 10:32
Nicholas well, that test is assuming that it's in $PATH 10:33
which is, well, wrong
but I don't know if the config system manages to put the path somewhere in a variable that can be read 10:34
10:37 frost left 10:39 frost joined
nine m: say $*RAKU.compiler.verbose-config<moar><bindir name exe> 10:41
camelia (/home/camelia/rakudo-m-inst-2/bin moar )
nine This should be it 10:42
10:46 frost left 10:59 frost joined 11:50 Altai-man joined 12:03 reportable6 left 12:09 frost left 12:17 CaCode_ left 12:34 CaCode joined 13:59 CaCode left 15:00 linkable6 left, evalable6 left
nine I've made some progress on the expr JIT issue. I've narrowed it down to the tiler which is what maps between the template in core_templates.expr and functions that generate the actual machine instructions (via DynASM). 15:01
15:01 linkable6 joined, evalable6 joined
nine Basically the tiler doesn't know about symbolic references that are generated by "let". It gets fed a tree where the $how is simply a pointer at the value part of the let-node. Then the tiler selects this tile as optimal machine code representation: github.com/MoarVM/MoarVM/blob/mast....tile#L104 15:02
The tile is "test this memory location for non-zero". Simply deleting this line removes the problem. Since no "test a memory location" candidate is available it has to fall back to a combination of "load memory location into register" and "test register for non-zero", i.e. this one: github.com/MoarVM/MoarVM/blob/mast....tile#L102 15:04
And since the JIT is at least smart enough to realize that we have already loaded the value into a register, it uses that.
15:06 vrurg left
nine Now I don't know if I'm anywhere closer to the solution. Seems to me that it's a bit of an architectural problem. "let" gets translated to a discard tile expr-template-compiler.pl and at runtime all we have is that additional edge in the graph (the one from where we use a value to where it's defined). 15:07
15:07 vrurg joined
nine If there were tiles that would take a call node directly as one of its operands then we'd start duplicating those calls a lot as well. The only thing that keeps the common "get a value from a function and process it a bunch of times" structure working is that there are no such tiles, so the compiler has to put the value into a register and have everyone else access the register as an intermediary. 15:10
16:28 cognominal left 16:34 patrickb joined
patrickb o/ 16:34
tellable6 2021-11-07T21:32:50Z #raku <japhb> patrickb github.com/japhb/Terminal-LineEdit...4ce1cab3e5 -- thanks for the suggestion!
16:35 Kaipi left, Kaipi joined 17:05 reportable6 joined 17:25 linkable6 left 17:53 MasterDuke joined 18:02 reportable6 left 18:06 Altai-man left
lizmat looking at an spesh inline log, I see a lot of failed inlines because of getlexperinvtype_o 18:11
is that low-hanging fruit somehow ? 18:12
nine lizmat: actually, it might well be. getlexperinvtype_o basically just alls MVM_frame_find_lexical_by_name which in github.com/MoarVM/MoarVM/commit/e2...77626de81f was converted to using the frame walker which correctly handles inlining. So the reason for marking this op :noinline might actually be gone. 18:39
lizmat well, that would be nice :-)
MasterDuke any objections to merging github.com/MoarVM/MoarVM/pull/1584 and github.com/MoarVM/MoarVM/pull/1596 ? 18:41
nine You could give it a try. Just remove the :noinline marker from src/core/oplist and run tools/update_ops.raku followed by make install
lizmat nine: I hope someone with more moarvm chops will do that :-) 18:42
MasterDuke everything builds and passes tests 18:59
lizmat +1 from me... :-) 19:02
Geth MoarVM: MasterDuke17++ created pull request #1598:
getlexperinvtype_o is now inlinable
MoarVM: 6033be47b3 | MasterDuke17++ (committed using GitHub Web editor) | 6 files
Another attempt at jitting some not so common ops that are still seen bailing in a spesh log (#1584)

  * Move scset(obj|code) impl out into a function...
and then just call that from the interpreter and the jit.
  * Jit getcomp
... (8 more lines)		 19:19
19:20 CaCode joined
Geth MoarVM: bdd6794e5e | MasterDuke17++ (committed using GitHub Web editor) | 2 files
getlexperinvtype_o is now inlinable (#1598)

  "getlexperinvtype_o basically just calls MVM_frame_find_lexical_by_name
which in github.com/MoarVM/MoarVM/commit/e2...77626de81f was converted to using the frame walker which correctly handles inlining. So the reason for marking this op :noinline might actually be gone."
   - nine, #moarvm, 2021/11/10 18:39:19		 19:28
19:32 CaCode_ joined 19:35 CaCode left 19:37 stanrifkin joined
stanrifkin maybe change your website to mention libera.chat instead of irc.freenode 19:38
are there some virtual machine programming tutorials? 19:39
lizmat stanrifkin: URL / 19:40
?
stanrifkin ?
lizmat re irc.freenode mention: I thought we covered them all ? 19:41
stanrifkin moarvm.org/contributing.html
-> communicate
Do you see it? 19:43
Geth MoarVM: 9a37bb61d7 | (Daniel Green)++ | src/strings/ops.c
Use alloca in more parts of MVM_string_index...

based on how it's done in knuth_morris_pratt_string_index(). Also simplify by using the already created `n_graphs` variable everywhere instead of `needle->body.num_graphs`.
I tested this with a one-liner that just does some `.contains()` and ... (5 more lines)		 19:44
MoarVM: f27cdeaec8 | MasterDuke17++ (committed using GitHub Web editor) | src/strings/ops.c
Merge pull request #1596 from MasterDuke17/use_alloca_in_MVM_string_memmem_grapheme32str
lizmat stanrifkin: github.com/MoarVM/moarvm.org/pull/13 19:46
stanrifkin good
lizmat MasterDuke: will do the alloca fix in a separate bump 19:51
for better bisectability
MasterDuke sure, np
japhb { name => 'hp', cost-per-point => 3, base => 'hits' }, 20:01
{ name => 'mp', cost-per-point => 3, base => 'mana' },
*Sigh*
20:05 reportable6 joined
lizmat hopes that sp_assertparamcheck is a similarly low-hanging fruit (as it currently prevents inlining in e.g. push-until-lazy) 20:11
pretty sure test-t has gotten faster with these 20:12
20:27 linkable6 joined 20:52 MasterDuke left
nine lizmat: sp_assertparamcheck is on the other end of the spectrum. Its presence means that we couldn't spesh argument processing and that means we can't inline. It's not so much this individual op itself 20:57
20:58 MasterDuke joined
lizmat aw too bad :-) 20:59
so what part of argument checking is problematic then ? 21:00
timo doesn't spesh add comments about arg spesh failing? 21:06
22:28 stanrifkin left 22:49 dogbert17 left, dogbert11 joined 23:19 patrickb 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!