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.
Nicholas good *, * 06:11
japhb Good *, Nicholas 06:12
.oO( Star Nicholas ?)
 06:13
timo good star nicholas 08:57
timo i was just tripped up when attempting to make a reproduced build of a program in go because apparently a release and its corresponding commit have disappeared from a github repository 13:30
something like cpan would have been great here ... 13:31
Nicholas I found this at ex-$ork - `go get` (IIRC) is great. Until the thing you are building against vanishes. 13:34
If we replace the Internet with a monorepository, that should fix the problem.
(who needs branches. Or anything else complex. When you have a monorepository) 13:35
timo back two svn
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/08/01/2022-...merelease/ 13:44
lizmat Q: my uint $a = 42; $a == $a # should that dispatch to the int/int candidate or the Int/Int candidate ? 15:27
or is there a uint/uint candidate missing for == ? 15:28
currently it dispatched to the Int/Int candidate it seems
japhb Yeah, I think we're missing uint candidates all over the place. uint shouldn't dispatch to int, because uint isn't a subset of int. 15:43
jnthn Int/Int is at least safe because there's no range problem, but agree it sounds like unit/unit candidate is missing 15:46
nine Keep in mind that the goal for my uint work was "get to a stable situation that handles uints more correctly" and not "get uint support 100 % finished" 17:53
So yes, a lot of optimization opportunities still open
lizmat ok, I'll be adding some candidates then 18:44
m: my int $b; multi sub a(int $a, int $b) { dd }; multi sub a(Int $a, Int $b) { dd }; a $b, 0 18:47
camelia sub a(Int $a, Int $b)
lizmat that this is selecting the Int Int candidate, also seems meh to me...
is that a static optimisation opportunity ? 18:48
lizmat github.com/rakudo/rakudo/commit/47f9b2860b 19:18
m: my int @a = ^10; my uint $b = 5; @a[$b] for ^10000000; say now - ENTER now 19:49
camelia 3.07404725
lizmat m: my int @a = ^10; my int $b = 5; @a[$b] for ^10000000; say now - ENTER now
camelia 1.759042641
lizmat spesh reports this for the uint case:
postcircumfix:<[ ]> BB(8097, 88 bytes) -> BB(1):
target has a :noinline instruction - ins: param_rp_o
int and Int cases for the index *are* inlined 19:50
timo BB 9097? 19:57
lizmat raku -MSIL -e 'my int @a = ^10; my uint $b = 5; @a[$b] for ^100000' 20:00
timo how is it so hueg 20:05
lizmat I haz no idea 20:25
in the native int $b version, it's postcircumfix:<[ ]> BB(8098, 222 bytes) -> BB(1) 20:26
timo do you see a bb with that number in your spesh log?
lizmat I'm using SIL, I'm not actually looking at the spesh log itself 20:27
I'm letting SIL do that :-)
timo i know 20:28
lizmat ok, so I added a native int candidate, and that also doesn't get inlined 20:30
so it's related to nativeness of the $pos
timo: I'm not understanding where the: 20:32
postcircumfix:<[ ]> BB(8097, 76 bytes) -> BB(1):
target has a :noinline instruction - ins: param_rp_o
comes from. Does that apply to *all* native positional arguments ? 20:33
if not, why does it apply here ?
timo sorry what exactly are you pointing at?
lizmat the reason for not inlining 20:34
target has a :noinline instruction - ins: param_rp_o
timo param_rp_o, especially that it doesn't have sp_, is a sign for arg spesh not having worked
it's the same thing i looked at just the other day 20:37
look where i asked about hllboxtype_u on the 18th of july 20:39
lizmat but it's the same for native int 20:42
timo oh 20:43
that's unfortunately
lizmat m: my int @a = ^10; my uint $b = 5; @a[$b] for ^10000000; say now - ENTER now 20:44
camelia 2.870941504
lizmat m: my int @a = ^10; my int $b = 5; @a[$b] for ^10000000; say now - ENTER now
camelia 1.789156957
lizmat m: my int @a = ^10; my $b = 5; @a[$b] for ^10000000; say now - ENTER now
camelia 0.281685348
lizmat there's a *lot* to be gained here
feels to me
or we give up for now, and remove all of the native int/uint candidates 20:46
timo i see postcircumfix:<[ ]> be inlined into '' (-e:1) here 20:49
but the 8040 i see here isn't a bb id, it's a cuuid maybe :ed
:D
lizmat ? 20:50
you mean spesh is cpnfused ? 20:51
timo no, SIL or me
lizmat I think SIL takes those lines from the log verbatim
timo the reason why it can't inline '' (1) is there's a getlexref_i in it 20:52
lizmat you mean: nqp::atposref_i ?
timo no
lizmat ah, the reference to $pos from the signature ?
timo getlexref_i is what you get when you compile a qast::var of a lexical with :return(int) and scope(ref) or something like that 20:53
it does getlexref_i on $b
lizmat ok, so this issue applies to *all* cases where we have a native in the signature and it gets called with a native 20:55
timo we immediately decont_i that lexref and never use the register again, but we do put the lexref_i result in an sp_resumption 20:56
i'm not sure what we need to do in order to prove whether the resumption can be elided 20:57
perhaps it is possible with more-pea to move the creation of the lexref to when we deoptimize and immediately getlex_i in that spot until then
lizmat neither :-) 20:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!