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:07 reportable6 left 01:07 linkable6 left, evalable6 left, bisectable6 left 01:10 reportable6 joined, bisectable6 joined 02:08 evalable6 joined 03:41 frost joined 06:07 reportable6 left 06:10 linkable6 joined 07:10 linkable6 left, bisectable6 left, sourceable6 left, greppable6 left, nativecallable6 left, releasable6 left, notable6 left, unicodable6 left, shareable6 left, committable6 left, tellable6 left, coverable6 left, evalable6 left, squashable6 left, benchable6 left, statisfiable6 left, bloatable6 left, quotable6 left 07:11 benchable6 joined, greppable6 joined, linkable6 joined 07:12 tellable6 joined, bisectable6 joined, bloatable6 joined 07:13 notable6 joined, shareable6 joined, sourceable6 joined 07:14 unicodable6 joined 08:08 reportable6 joined 08:11 squashable6 joined, statisfiable6 joined 08:13 releasable6 joined, evalable6 joined, nativecallable6 joined
MasterDuke m: dd Array[Str]("a", "b", "c") 08:44
camelia Array[Str].new("a", "b", "c")
MasterDuke jnthnwrthngtn: why/how does ^^^ work? to me it looks like either a C-style cast or a Python-ish object instantiation 08:45
timo MasterDuke: coverage log says it goes via List.pm6's method CALL-ME, which calles self.new on the argument capture 08:48
MasterDuke huh. do we have a lot of other types that do that? 08:50
timo what exactly, like Int(99)? 08:51
m: say Int(99.0)
camelia 99
timo m: say Int(99.1)
camelia 99
timo m: dd Str(123)
camelia "123"
timo m: dd Hash("a", "b", "c", "d")
camelia Has % = {:a("b"), :c("d")}
timo "Has" :D 08:52
nine MasterDuke: github.com/rakudo/rakudo/commit/90...8e259306a0
MasterDuke huh
i don't know if it's because i haven't finished my first cup of coffee yet, but i'm still surprised 08:53
nine same here, despite the coffee
MasterDuke m: dd Array("a", "b"); dd Hash("a", "b")  #  lizmat two oddities. github.com/rakudo/rakudo/commit/49...0503e2d3e2 caused the "Has", but i'm not sure why the Array one has 'element' instead of '@' 09:03
camelia Array element = ["a", "b"]
Has % = {:a("b")}
MasterDuke 'element' comes from here maybe github.com/rakudo/rakudo/blob/mast...1870-L1874 09:06
09:11 committable6 joined 09:12 coverable6 joined 09:13 quotable6 joined
MasterDuke in the end, getting mimalloc integrated wasn't too terrible. anybody have any thoughts on github.com/MoarVM/MoarVM/pull/1634 ? 09:41
moon-child MasterDuke: might be good to make MVM_strdup instead of going to mi_ versions, so any future changes don't have to track down where those are used 09:44
(and for those, would maybe straight str(n)len -> mvm_malloc+memcpy rather than calling mi_strdup, to further reduce cognitive overhead of a future change. That's not going to be any different from how mi implements it anyway) 09:46
MasterDuke hm, but future changes should be easier, since e.g., switching away from mimalloc would show up the use of mi_* as a compile-time error
moon-child good point
but still requires effort at all, vs _just_ swapping out malloc/calloc/realloc/free
nine Yeah, we may as well go all the way and wrap all mimalloc functions 09:50
Or #define it in that case
MasterDuke simple enough 09:52
nine What triggered the bool -> _Bool change? 09:53
MasterDuke i think it was a type redeclaration 09:55
don't have the error in my scrollback anymore
i could try undoing those now that i'm just including the single static file 09:56
nine Could take the opportunity and #include <stdbool.h> and get bool as it's intended to be
timo ok everybody, turn up your music, because without dB, that's just "stool.h" 09:57
moon-child ugh 10:03
:)
lizmat m: dd [1,2].VAR.name # MasterDuke the origin of "element" 10:15
camelia "element"
lizmat m: dd {:a,:b}.VAR.name # the origin of % 10:16
camelia "\%"
10:20 discord-raku-bot left, discord-raku-bot joined 10:23 Geth__ joined 10:25 Geth left
MasterDuke there are some differences between the implementation of at least .name() and .of() between Array and Hash. i have no idea if those differences are required 10:25
lizmat MasterDuke: github.com/rakudo/rakudo/commit/59929f0a23 10:41
workaround for now
MasterDuke cool. wonder if github.com/rakudo/rakudo/commit/39...5ae8c3f964 can be done for Array also? 10:44
lizmat m: use nqp; dd nqp::getattr([1],Array,q/$!descriptor/).name 10:46
camelia "element"
lizmat I guess it could, let's see
MasterDuke m: use nqp; dd nqp::getattr(Map.new.Hash,Hash,q/$!descriptor/).name 10:50
camelia Use of Nil in string context
in block <unit> at <tmp> line 1
"element"
jnthnwrthngtn Array[Int](1,2,3) is a coercion 10:51
Or at least, that's how I'd expect it to work
MasterDuke m: dd 1 10:52
camelia Use of Nil in string context
in block <unit> at <tmp> line 1
1
MasterDuke lizmat: looks like that 'Use of Nil <...>' warning always happens now 10:53
lizmat yeah, looking at that
MasterDuke github.com/rakudo/rakudo/blob/mast...ap.pm6#L35 where my Map.new.Hash example gets it's 'element' from
*its 10:54
11:01 Geth__ left, Geth joined
MasterDuke jnthnwrthngtn: if i look at the ast of e.g., `sub foo(Int() $a) { say $a };` i see a `Perl6::Metamodel::CoercionHOW`, but the ast of `say Array[Str]("a", "b", "c")` doesn't have any 11:02
jnthnwrthngtn MasterDuke: Possibly raku-call takes care of mapping to any coercion logic 11:03
MasterDuke well, timo was correct that it goes through List's CALL-ME (i added a print in there and it gets triggered) 11:07
jnthnwrthngtn That may be sorta-legacy or at least pre-date when we had more proper coercion stuff 11:08
MasterDuke yeah, the commit nine found introducing it was from 2015 iirc
github.com/rakudo/rakudo/commit/90...8e259306a0 11:09
github.com/rakudo/rakudo/blame/mas...#L913-L916 essentially unchanged since then 11:10
jnthnwrthngtn Correct results by dubious means, I guess... :) 11:12
(Although at the time it was probably the only way)
MasterDuke huh. entirely removing CALL-ME from List still give the same output 11:17
jnthnwrthngtn Cool, so then everything involving the coercion protocol is wired up already :)
iirc, a CALL-ME takes precedence 11:18
If there's not one, the dispatcher looks if it's a type object and if it can do the coercion
nine Removed code is debugged code!
MasterDuke no `Perl6::Metamodel::CoercionHOW` in the new ast though
timo and smaller core setting and less ram and ...
that wouldn't show up in the ast anyway, though?
nine No, it's a runtime thing 11:19
MasterDuke it does for a sub with a coersion parameter, but yeah, that's really not quite the same thing
nine Int() in a place where we expect a type is an object of a CoercionHOW meta class. It's for talking about a specific coercion type. Coercion by itself doesn't actually have much to do with CoercionHOW, its more of an abstract concept. 11:20
MasterDuke cool, spectest passed. guess i should try removing some of those other CALL-MEs to see if it's the same for them 11:24
11:50 Altai-man joined 12:07 reportable6 left 13:10 reportable6 joined 13:59 Geth left, Geth joined 14:10 frost left
MasterDuke wow, there are two new sets of warnings when building moarvm in our CI, but they don't seem to be about any newly added/modified code 14:30
dev.azure.com/MoarVM/MoarVM/_build...&l=240 14:31
dev.azure.com/MoarVM/MoarVM/_build...&l=217
dev.azure.com/MoarVM/MoarVM/_build...&l=216 14:32
dev.azure.com/MoarVM/MoarVM/_build...&l=268 14:33
oops, four new sets
vrurg Looking for an advise. I'm considering splitting Junction into subclasses – one for each kind of junction. This would allow to shrink methods like Bool and ACCEPTS to a couple of ops possibly improving their inlinability. Does it make sense to play with this? 15:00
[Coke] Would that break any spectests? 15:04
if it can be hidden as an implementation detail, seems reasonable.
vrurg [Coke]: I don't know if it would break anything. That's why it's going to be an experiment. 15:05
But if the methods currently fit into inline limits nicely then there might be no reason to waste time on this. 15:06
MasterDuke do you have some benchmarks you've looked at spesh logs of? or maybe MVM_SPESH_INLINE_LOG will give more useful data 15:08
vrurg MasterDuke: never done it before. Looks like it is the time to start. :) 15:09
15:29 Geth left, reportable6 left, discord-raku-bot left, quotable6 left, coverable6 left, committable6 left, nativecallable6 left, evalable6 left, releasable6 left, statisfiable6 left, squashable6 left, unicodable6 left, sourceable6 left, shareable6 left, notable6 left, bloatable6 left, bisectable6 left, tellable6 left, linkable6 left, greppable6 left, benchable6 left, sena_kun left, [Coke] left, MasterDuke left, bartolin left, Kaiepi left, leedo left, ugexe left, camelia left, dogbert11 left, moon-child left, SmokeMachine left, nebuchadnezzar left, leont left, jnthnwrthngtn left, rba left, JRaspass left, jdv left, Altai-man left, kjp left, Voldenet left, gfldex left, psydroid left, TempIRCLogger left, ilogger2 left, nine left, vrurg left, Nicholas left, samcv left, timo left, rypervenche left, tbrowder left, Util_ left, codesections left, harrow left, samebchase left, japhb left, lizmat left 15:32 timo joined, samcv joined, vrurg joined, Nicholas joined, nine joined, ilogger2 joined, codesections joined, Util_ joined, tbrowder joined, rypervenche joined, rba joined, jnthnwrthngtn joined, leont joined, camelia joined, nebuchadnezzar joined, SmokeMachine joined, moon-child joined, ugexe joined, dogbert11 joined, MasterDuke joined, leedo joined, Kaiepi joined, bartolin joined, [Coke] joined, sena_kun joined, benchable6 joined, greppable6 joined, linkable6 joined, tellable6 joined, bisectable6 joined, bloatable6 joined, notable6 joined, shareable6 joined, sourceable6 joined, unicodable6 joined, squashable6 joined, statisfiable6 joined, releasable6 joined, evalable6 joined, nativecallable6 joined, committable6 joined, coverable6 joined, quotable6 joined, discord-raku-bot joined, reportable6 joined, Geth joined, harrow joined, samebchase joined, JRaspass joined, jdv joined, TempIRCLogger joined, AlexDaniel left 15:33 japhb joined, lizmat joined
Nicholas MasterDuke: newer MIPS system has a newer gcc. It too has no __atomic_load_8 etc. 15:33
15:33 Altai-man joined, kjp joined, Voldenet joined, gfldex joined
Nicholas one needs to add -latomic to the link command line 15:33
for moar. for nqm-m. and I guess for rakudo-m
but meanwhile, on arm32 15:34
Thread 1 "moar" received signal SIGSEGV, Segmentation fault.
deserialize_callsites (rs=0xb6388680, cu=0x1, tc=0xb6010080) at src/core/bytecode.c:900
900 if (!callsites[i]->is_interned) {
(gdb) p callsites[i]
$2 = (MVMCallsite *) 0x0
so, that's a bug of some sort.
vrurg NQP and Rakudo puck up their compile options from moar backend config. 15:35
MasterDuke huh. thanks for checking
Nicholas ah OK, so it could be fixed in one place
vrurg I hope so.
Nicholas anyway, sparc64 builds OK
everything else fails early in some way currently
everything else tried taht is 15:36
need to go AFK
will try aarch64 linux later. And the M1 Mac. To see what 64 bit ARMs think 15:37
MasterDuke so it looks like there's a combination of: actual bug (maybe upstream), build options we need to (and most likely can) set, and build problems we can't work around but are potentially fixable if one is willing and able to upgrade packages on the system 15:38
i would say the first two definitely need to be addressed. personally i'm ok with the third 15:41
lizmat vrurg: In the past I tried playing with Junctions like that, it did not end well 15:44
but things have changed since then, so more power to you if you get that working
nine Nicholas: that cu=0x1 looks fishy already. That's supposed to be a MVMCompUnit* 15:45
vrurg lizmat: won't be asking what went wrong for you as to not get biased from the start. :) 15:47
lizmat vrurg: if it fails, it's probably in a different way than then anyway :-) 15:48
MasterDuke looks like cpython is experimenting with mimalloc also. maybe we can steal something from them github.com/python/cpython/pull/29123 15:49
lizmat if I recall correctly, the main failure mode was a lot of places where expecting nqp::eqaddr((1|2).WHAT,Junction) to be True
jnthnwrthngtn If it's just about opt, then probably it's possible to write a dispatcher that guards on the type attribute inside of the Junction object 15:50
vrurg Dispatcher would limit it to moar only. Though if JVM doesn't inline then it probably doesn't worth trying. 15:56
MasterDuke Nicholas: `3rdparty/mimalloc/include/mimalloc-types.h:42:#define MI_SECURE 0` do you mind trying with that set to 4 instead? 15:58
vrurg I also have a guess that guarding on a type object is slightly faster than guarding on an attribute value. 16:02
jnthnwrthngtn After JIT/spesh maybe not all that much 16:03
Also note that a type explosion will potentially turn monomorphic callsites (just Junction) polymorphic too, which also prevents inlining 16:05
vrurg This is certainly the last nail into coffin. 16:07
Will refocus on dispatchers. I wanted to have smartmatch optimizations based on dispatchers anyway. 16:09
jnthnwrthngtn: One last request. If you get some spare time for github.com/Raku/problem-solving/is...-912087363 (just that comment only) and tell if it makes sense to you. 16:10
Any time. It's no rush at all.
jnthnwrthngtn OK. Alas, maybe not this week if it needs much thinking, I'm buried in $other-job this week still :( 16:11
vrurg As I said, no rush. It's waiting since Sep anyway. The related PR is at low risk of merge conflicts because barely anybody else works with pseudostashes. 16:13
16:20 discord-raku-bot left 16:21 discord-raku-bot joined 16:37 discord-raku-bot left 16:38 discord-raku-bot joined 17:26 AlexDaniel joined 18:06 linkable6 left, reportable6 left 18:08 reportable6 joined, linkable6 joined 18:40 Altai-man left 18:41 squashable6 left 18:44 squashable6 joined 20:19 linkable6 left
Geth MoarVM/C11-mimalloc-swings-and-roundabouts: 7 commits pushed by (Daniel Green)++, (Nicholas Clark)++ 21:03
21:03 psydroid joined
22:33 Geth left 22:34 Geth__ joined 22:49 sena_kun left 22:51 sena_kun joined 23:19 Geth__ left, Geth joined 23:20 RakuIRCLogger__ 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!