00:08 reportable6 left, reportable6 joined 03:04 frost joined 03:16 frost left 03:35 frost joined 06:07 reportable6 left 06:09 reportable6 joined
Nicholas good *, * 06:11
japhb Good *, Nicholas 06:12
.oO( Star Nicholas ?)
06:38 rba left 06:39 rba joined 06:51 SmokeMachine joined 06:54 crystalfrost[m] joined 07:39 sena_kun joined
timo good star nicholas 08:57
09:22 sena_kun left 09:40 discord-raku-bot left, discord-raku-bot joined 10:04 sena_kun joined 10:30 gfldex left, discord-raku-bot left 11:40 benchable6 left, coverable6 left, greppable6 left, sourceable6 left, releasable6 left, shareable6 left, reportable6 left, bloatable6 left, quotable6 left, nativecallable6 left, notable6 left, unicodable6 left, linkable6 left, evalable6 left, bisectable6 left, committable6 left, statisfiable6 left, tellable6 left 11:41 nativecallable6 joined, coverable6 joined, bisectable6 joined, releasable6 joined, shareable6 joined, committable6 joined, benchable6 joined 11:42 unicodable6 joined, quotable6 joined, tellable6 joined, evalable6 joined, reportable6 joined, statisfiable6 joined, linkable6 joined 11:43 bloatable6 joined, notable6 joined, sourceable6 joined, greppable6 joined 12:07 reportable6 left 12:09 reportable6 joined 13:09 frost left, vrurg left 13:10 vrurg joined
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
14:56 [Coke]_ joined 14:58 [Coke] left
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
16:41 discord-raku-bot joined 16:58 [Coke]_ is now known as [Coke] 17:18 sena_kun left
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
17:54 sena_kun joined 18:06 reportable6 left 18:07 reportable6 joined
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
18:57 sena_kun left 19:00 sena_kun joined
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
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
21:38 sena_kun left 21:42 jnthn left 22:36 linkable6 left 22:38 linkable6 joined 23:17 jnthn joined