|
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: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:13 | ||
|
06:38
rba left
06:39
rba joined
06:50
SmokeMachine left,
RakuIRCLogger left,
crystalfrost[m] left
06:51
SmokeMachine joined
06:54
crystalfrost[m] joined
06:55
RakuIRCLogger left,
RakuIRCLogger joined
06:59
RakuIRCLogger left,
RakuIRCLogger joined
07:39
sena_kun joined
08:39
RakuIRCLogger left,
RakuIRCLogger 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 | |||
| :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 | ||
|
21:38
sena_kun left
21:42
jnthn left
22:36
linkable6 left
22:38
linkable6 joined
23:17
jnthn joined
|
|||