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.
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
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 "\%"
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
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
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
Nicholas MasterDuke: newer MIPS system has a newer gcc. It too has no __atomic_load_8 etc. 15:33
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
Geth MoarVM/C11-mimalloc-swings-and-roundabouts: 7 commits pushed by (Daniel Green)++, (Nicholas Clark)++ 21:03

Powered by Cro and the Raku® Programming Language.

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

Thank you!