github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
02:14 evalable6 left, linkable6 left, squashable6 left 02:15 squashable6 joined, bloatable6 joined, committable6 joined, statisfiable6 joined 02:16 releasable6 joined, sourceable6 joined, nativecallable6 joined, benchable6 joined, tellable6 joined, quotable6 joined, coverable6 joined, evalable6 joined, shareable6 joined 02:17 greppable6 joined, bisectable6 joined, linkable6 joined, unicodable6 joined, notable6 joined 03:17 linkable6 left, committable6 left, evalable6 left, sourceable6 left, tellable6 left, benchable6 left, releasable6 left, quotable6 left 03:18 evalable6 joined 03:19 sourceable6 joined, releasable6 joined, benchable6 joined 03:20 tellable6 joined, quotable6 joined, linkable6 joined, committable6 joined 05:53 japhb left 05:55 japhb joined
nwc10 good *, #moarvm 07:26
nine Oh, is it * again? 07:33
moritz you know how timezone works, it's always * somewhere 07:34
nwc10 it keeps happening.
3 days without hot beverage mishaps. I wonder how long I can keep this up. I have no tea...
nine No mishaps, but did you have hot beverages at all? 07:40
nwc10 yes. There was tea. There was coffee. 08:02
08:23 Kaeipi joined
MasterDuke github.com/MoarVM/MoarVM/pull/1470 and github.com/rakudo/rakudo/pull/4320 now have several different versions, many of them relatively independent (i.e., you kind of want to look at each commit and its diff from master, not necessarily to the previous commit) 08:26
is there any other good way to propose multiple different options, besides just creating multiple PRs? 08:27
maybe i just need to extract the various diffs and put them in a gist 08:28
and now a completely different question. jnthn mentioned logging pow_I, which involved adding `:logged` to its entry in the oplist, and then possibly some additions to src/spesh/facts.c., and maybe some tweaks in src/core/interp.c, etc. 08:32
i assume there's some cost to logging, or, what's the reason not to log everything? 08:33
nine Yes, there is a cost 08:34
MasterDuke very few ops are logged, does it only make sense to do so for ops that have different kinds of return values? e.g., pow_I could return an Int or a Num, contrasted with mul_I which only returns an Int (both can throw in some error conditions) 08:37
my new pow2_I (to maybe replace the existing pow_I) instead returns an Int type object instead of a Num, but that's still different enough to make logging potentially worthwhile? 08:39
also, add_bb_facts has cases for lots of ops (not just :logged ones), so e.g., (add|sub|mul|div|mod|neg|abs)_I all have a case that that just does a copy_facts between two registers 08:42
would it make sense to add a bunch more cases? pow_I, b(and|or|xor|not)_(i|I) 08:43
08:57 domidumont joined
nwc10 no noes. Was within 1cm of finishing the coffee when I got a minor explosion. I think that the coffee slug "failed" on the edge, and that releases all the pressure (like a damn burst) and the flow rapidly erodes more of the coffee slug. 09:01
Have to reset the counter.
sena_kun MasterDuke, ping? 09:53
gist.github.com/Altai-man/32a9fb9c...14603ab658 <- this looks to me like a moarvm regression, not a false positive. 09:56
MasterDuke sena_kun: i still can't repro locally 10:11
sena_kun MasterDuke, you have clonned the github.com/coke/raku-uni repo? 10:13
MasterDuke yep. its test passes when run from the cloned repo, also `zef install App::Uni` succeeds for me
sena_kun MasterDuke, and your raku --version is v2021.03-176-g6fdc2b690? 10:14
MasterDuke v2021.03-178-g10c3dbb94
Built on MoarVM version 2021.03-50-g948128995.
sena_kun re-installs moar-blead 10:16
lizmat sena_kun: github.com/coke/raku-uni also tests clean for me on MacOS 10:18
sena_kun I wonder how on earth I can reproduce it so reliably. 10:19
Welcome to Rakudo(tm) v2021.03-178-g10c3dbb94.
[App::Uni] # You failed 1 test of 8
lizmat hmmm... my raku says: Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.03. 10:20
wtf ?
sena_kun lizmat, didn't you make it optional? When fonts are present or something. 10:22
lizmat made what optional?
the "𝐑𝐚𝐤𝐮𝐝𝐨" you mean? 10:23
sena_kun lizmat, the message font.
yeah
lizmat yeah, it's only shown when starting the REPL
I was more pointing towards the version shown? 10:24
sena_kun lizmat, when I start REPL there is indeed Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.03.
lizmat ah, *phew*
sena_kun raku --version shows me Welcome to Rakudo(tm) v2021.03-178-g10c3dbb94.
lizmat right.... ok, that was the other difference, I remember now :-) 10:25
*phew*
sena_kun Ok, so Blin can spot the regression and I can spot the regression manually. 10:26
But two people cannot.
MasterDuke what os are you on?
sena_kun gnu/linux box
MasterDuke i'm using arch linux 10:27
sena_kun void linux if it gives something
OTOH I don't think it does. I'm using an intel CPU.
MasterDuke amd 10:29
sena_kun I suspect it's something else. Can you do `which zef`? As in, what raku binary runs zef, is it the correct one? 10:30
MasterDuke i only have one raku binary, and was using the zef binary in the zef repo 10:31
sena_kun Hmmm. Apparently, I am not qualified enough to find a solution. I'll gladly run commands if anything that can clarify the case comes to mind. 10:32
MasterDuke maybe vrurg can try to repro on the machine where blin runs 10:33
10:33 dogbert17 joined
sena_kun I kinda don't want to manually revert moarvm commits in a binary search manner, bump and rebuild to find out which one causes that on this machine, but maybe that's the way. 10:35
lizmat sena_kun: I'm not 100% convinced it's in MoarVM 10:37
dogbert17 what happens if you run this golf (cough cough) a few times, does it always work? gist.github.com/dogbert17/cf91cd2b...60857958d9
tellable6 2021-04-15T12:45:17Z #moarvm <MasterDuke> dogbert17: ping, you're good at testing the 3rdparty bumps, looks like libatomicops is a bit out of date of upstream
sena_kun lizmat, the commit between bump works for me, the commit with the bump does not. 10:38
Oh, interesting. 10:39
So I ran it 3 times so far
Strings = cat eyes 2
Type check failed in binding to parameter '<anon>'; expected Cool but got Method (proto method fc (Coo...)
in sub uni-search at golf.raku line 35
second two runs are fine
lizmat could you check to see what happens if you change in lines 35 and 36 10:40
uniname($_) to .uniname ?
dogbert17 I get the same error as sena_kun but not always
sena_kun lizmat, I can't break it so far, alas I did just 10 iterations, cannot do 100 or something here. 10:41
lizmat ok, well: looks to me that code hyper code is a bit suspect
dogbert17 lizmat: it works for you then? 10:42
lizmat ah, no.. it fails 10:43
ok, so we have it reproed now
sena_kun yay
dogbert17 yay++
sena_kun do you folks need something from me or I can go grab some food? :)
dogbert17 get some food :) 10:44
lizmat grab food!
sena_kun yay 10:45
thanks for being patient with me. :)
lizmat sena_kun: thanks for being persistent!
ok, I think the MoarVM change uncovered a DIHWIDT bug 10:49
dogbert17 speculates (woldly) that there might possibly be some bizarre connection with github.com/rakudo/rakudo/commit/e2...f46459ea66
lizmat if you remove the hypers from that code, it all works
dogbert17: that could be, but only because they made it more likely that the hyper would be bashing the same $sieve at the same time 10:50
the code is wrong: multiple threads should *not* be writing to $sieve at the same time 10:51
dogbert17 ah
running with MVM_CROSS_THREAD_WRITE_LOG=1 seems to confirm your theory 10:54
lizmat so I would mark it as a false positive, and maybe make a PR removing the hypers 10:55
that piece of logic needs to be re-thought 10:56
dogbert17 I suspect [Coke] put them there for speed related reasons
lizmat wow, that's a lot of output 10:59
hmmm... now it also fails without the hypers? 11:01
doesn't fail if I put a dd $sieve in it 11:02
hmmm
the number of strings isn't big enough for the hyper to actually hyper, as it default batch size is 64 and there are only 2 strings 11:06
so *that* is only a potential issue 11:07
dogbert17 interesting, and if we backtrack to the bizarre theory ? 11:17
lizmat that it *is* something in moar that broke 11:22
can't get it to fail with MVM_SPESH_BLOCKING=1 11:23
dogbert17 the wild theory is that your Rakudo commit uncovered a spesh bug which MasterDuke's decont fix managed to hid/fix. How's that for a wild theory? 11:24
*hide
lizmat could be
what other MVM_SPESH options do we have again? 11:25
dogbert17 chances are quite high that it will be smashed to bits :)
the interesting ones are MVM_SPESH_INLINE_DISABLE and MVM_SPESH_OSR_DISABLE
lizmat can't replicate with MVM_SPESH_DISABLE
dogbert17 neither can I
lizmat can't replicate with MVM_SPESH_INLINE_DISABLE 11:26
dogbert17 +1
lizmat can't get it to fail with --profile either 11:27
correction: --profile also fails
profile shows that of the 1.1M calls to Str.contains, the majority is red, only the last 10% is green 11:29
which feels... odd ?
the inline log shows uniname, fc and contains all inlined 11:30
MVM_SPESH_NODELAY=1 *always* fails 11:32
also fails with MVM_JIT_DISABLE
so my guess is indeed some spesh related issue, possibly already existing, now uncovered by this code 11:33
dogbert17 where are the speshialists :)
lizmat the problem occurs in the *proto* of Cool.contains 11:34
anything on top of that in the stacktrace is just producing the error 11:36
I'm afraid I'm out of ideas at this point
MasterDuke nine sena_kun ^^
sena_kun I am surely not a speshialist, but nice to see the investigation progressing, great work! 11:37
MasterDuke i likely won't have any decent chunk of time to work on this today, but 08525be54bab1e7e9130568eda06d7c8295ac5cb is a spesh-related commit in between the two bumps 12:20
12:58 frost-lab joined
Geth MoarVM/propagate_spesh_facts_after_guard_elimination: e1d546ab54 | (Stefan Seifert)++ | src/spesh/optimize.c
Propagate spesh facts after optimizing away a guard

When we optimize a guard into a set (for in the hopes of it getting eliminated later on), we missed the opportunity to copy the facts from the source register. This lead to missed optimization opportunities like not inlining a function, because we didn't know that we actually knew the callee.		 13:02
MoarVM/propagate_spesh_facts_after_guard_elimination: dc1f710bd5 | (Stefan Seifert)++ | src/spesh/optimize.c
Propagate spesh facts after optimizing box/unbox into a set

When we optimize a box/unbox pair into a plain set, we do so knowing that the required output is exactly the input. So all facts known for the input must apply for the output as well. Copy those facts to allow for further optimizations based on them.
MoarVM/propagate_spesh_facts_after_guard_elimination: 543258ab10 | (Stefan Seifert)++ | src/spesh/optimize.c
Propagate spesh facts after eliminating unuseed log guards

When turning unused log guards into plain sets (with the goal of getting rid of them completely via set elimination) copy the input facts to the output to unlock further optimization between log guard and set elimination.
MoarVM: niner++ created pull request #1471:
Propagate spesh facts after guard elimination		 13:04
14:10 frost-lab left
jnthn nine++ 15:47
tellable6 2021-04-17T09:57:04Z #raku-dev <nine> jnthn github.com/rakudo/rakudo/pull/4331 will probably amuse you :)
jnthn nine: Fixing bugs my deleting code is always a nice thing :D 15:48
nine Taking the discussion about the clear moarvm bug back to the channel, my propagate_spesh_facts_after_guard_elimination branch actually makes the uni-search bug go away 15:53
It's quite possible though that it just hides it again.
On the topic "Type check failed in binding to parameter '$bytes'; expected Blob but got Supplier::Preserving (Supplier::Preserving...)" I've found that MVM_SPESH_OSR_DISABLE makes that go away. And spesh log shows a difference in facts that seems to be significant. 15:54
MasterDuke on moarvm master, after removing the hypers in the App::Uni test, i can consistently repro with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1. it still fails if i add MVM_SPESH_OSR_DISABLE=1 15:56
seems to pass with PEA or INLINE disabled though 15:59
nine: i don't remember, did you ever figure out/fix that SSA problem? 16:03
nine yes
That was github.com/MoarVM/MoarVM/commit/29...7fe83daea1 16:04
MasterDuke ah, right
nine Fun time over, "ab attack" training starts... 16:19
MasterDuke i'm also about to attack my abs, but with indian food 16:33
16:47 brrt joined 17:09 brrt left 17:15 lucasb joined 17:30 patrickb joined 17:36 patrickb left 17:39 domidumont left 18:51 zakharyas joined
Geth MoarVM/ryu: 5 commits pushed by (Nicholas Clark)++ 19:53
MoarVM: nwc10++ created pull request #1472:
Switch MVM_coerce_n_s to Ryū from Grisu3 with a sprintf fallback		 19:56
nwc10 and now I find *two* errors in one of the commit messages 20:07
anyway, put *that* in your CI system and smoke it. 20:08
(tomorrow I'll have a go on big endian systems, which I think feature nowhere in any CI system anyone offers online)
[Coke] japhb: [u] sure. 20:39
japhb [u]? 20:40
[Coke] gist.github.com/japhb/7b8a68da1b4b...c1269b951a 20:41
japhb Oh, the [] meant re:, got it
[Coke] I assume you were referring to updates to app::uni, sure, patches welcome
japhb throws that into his queue 20:42
MasterDuke nwc10: doesn't the OBS, which i believe nine has access to, have some big endian systems? 20:45
nwc10 OBS? Something SuSE?
I have an account on the gcc compile farm. There's lots of fun stuff, but it has to be me logging in manually 20:46
sadly the ia64 machine is no more.
MasterDuke opensuse build system i think 20:47
japhb s/system/service/ I think, but otherwise yeah 20:49
nine nwc10: OBS is the Open Build Service which is as the name says quite open :) Yes, it comes from the SUSE people. 21:07
I'm building every rakudo commit on among the usual candidates PowerPC, aarch64 and s390: build.opensuse.org/project/show/ho...rakudo-git 21:08
21:08 zakharyas left
nine And not just rakudo but a whole bunch of modules I care about. What I don't yet do is run a spectest. I figured patrickb will get to that 21:08
Oh, RISCV is also available nowadays. Wonder how'd we do there... 21:10
21:30 Kaeipi left 21:31 Kaeipi joined 22:50 Kaeipi left 23:40 japhb left 23:52 japhb joined 23:53 japhb_ joined 23:55 japhb_ left, japhb left, japhb 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!