github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:13 leont left 01:02 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 01:12 lucasb left 06:04 sena_kun joined 06:31 squashable6 left 06:34 squashable6 joined 06:55 raku-bridge left 07:32 domidumont joined 07:33 squashable6 left, squashable6 joined 07:34 squashable6 left 07:35 squashable6 joined 08:11 Altai-man joined 08:13 sena_kun left 09:01 zakharyas joined 09:33 MasterDuke joined
nwc10 good *, #moarvm 09:39
jnthn morning o/ 10:25
nwc10 \o
11:21 leont joined 11:42 Altai-man left 12:05 zakharyas left 12:37 domidumont left 12:41 domidumont joined 13:03 tib left 13:05 sena_kun joined 13:06 squashable6 left 13:08 squashable6 joined 13:14 zakharyas joined 13:20 tib joined 13:59 lucasb joined 14:59 linkable6 left, evalable6 left
vrurg jnthn: a note to what we discussed yesterday. Unfortunately, it turns out that handling of in-signature type captures also requires nqp::curlexpad to grab typeenv. I tried to find a workaround, but did not succeed. 15:00
15:01 linkable6 joined, evalable6 joined
jnthn That's what I was talking about yesterday with regards to being able to instead instantiate with a hash consisting of the required type variables 15:03
But yeah, that still required late-bound stuff to happen 15:04
Oh wait, it doesn't
Because we know the type variables needed 15:05
At compile time
Which is what I figured yesterday also :)
vrurg sub foo(::T) { my subset RS of T; my sub bar(::T2 $a, Str(T) $b) {...} }
jnthn That isn't going to work 15:07
vrurg I'm not sure how can this be done without instantiating T at runtim
jnthn A subset declaration happens at BEGIN time
It should be a compile-time error to try and use T there, ideally
Same goes for the inner sub, I think. I can live with role bodies containing lexical declarations that we instantiate. 15:08
Because they are arguably a BEGIN-ish context
vrurg The inner sub works if I instantiate T at the signature binding time. 15:09
jnthn But you'd need to instatiate the sub as a whole? 15:10
vrurg Haven't tried the subset, but same applies: it will work in a nested signature because it's seen as a generic and can be instantiated..
jnthn Yes, you're trying to make things work, but I'm arguing they should not. 15:11
Or at least, if they do, it's a huge departure from current behavior.
And needs considering for all kinds of types, not just making subsets magically work but not other things. 15:12
vrurg The way I have it with github.com/rakudo/rakudo/pull/4058 doesn't break spectests. And since that kind of stuff never worked before, nobody used it in the wild. So, should be nothing to break here.
jnthn I'm not saying you'll break anything, I'm saying you're introducing design inconsistencies. 15:13
We've had a quite strong idea of what is BEGIN time and what is not so far.
We can revise that, but it needs an over-arching approach, IMO. 15:16
vrurg I probably need to think of it a bit more. Too much focus on the signature distracted me from things like direct use of a type by a user. Like the subset above could be introspected directly – and it likely won't be what a users expects it to be.
jnthn Like, we could in theory say that anything that is signatured with a type parameter (be it sub or role) is template-like 15:17
And we compile it into something like a quasi and then instantiate it to fill the gaps, interning those instantiations 15:18
And so "there is no subset/inner sub" until we call it
This comes with no small number of consequences/trade-offs though 15:19
(A sub with type parameteres would have to gain the existing "you can only make lexical declarations" rule a role body has, for example, although I don't expect this to be problematic in reality)
*parameters
It'd be hugely powerful though if we did make it work :) 15:20
vrurg Also don't see a problem in requiring lexical decls. But all this not a kind of thing to be done in the current implementation anyway. 15:21
jnthn Yeah, it's hard anyway, and really really hard with the current impl
I don't want to tell folks not to do things until we have rakuast, but this is a case where the possibilities are much greater for a good solution once we do have it...
vrurg So, I'll most likely play a bit with what I currently have, but going to revert the typecapture support. 15:22
jnthn Was the perf regression tied up with the new coercion semantics?
vrurg Yes.
jnthn Because it'd be good to retain most of those and not have the regression
Even if we lose something in terms of the type capture stuff for now 15:23
vrurg Some regression is expected anyway because it's some additional work to be done at runtime. But I hope to minimize it to acceptable level.
thanks for the review! It was refreshing. :) 15:27
jnthn Good luck. And thanks for taking on the coercion things. I didn't look that closely yet but at least from the blog post it seems a nice improvement 15:28
vrurg BTW, `sub foo(::T) { my subset RS of T; my RS $x = 42; say $x.raku }; foo(Str(Int))` works with the R#4058. Heh... 15:32
linkable6 R#4058 [open]: github.com/rakudo/rakudo/pull/4058 [WIP][type captures] [WIP] Implement metmodel transparency of nominalizables
jnthn Wow :) 15:33
How does it instantiate RS? Call instantiate and binding it into the lexpad? 15:34
vrurg Frankly, I'm not sure myself for the moment. Don't see where the instantiation of RS happens. Will check it later. Anyway, RS.^refinee returns T, which is I expected and which shouldn't happen if all works as expected. 15:38
jnthn My worry is that it's relying on lexical capture but not doing any closing and so will go pretty badly if multiple threads access it 15:41
sorry, any *cloning*
vrurg I'll check it. If I forget nothing, I didn't do anything specific to handle generics in scalar declaration. So, it's a side-effect I didn't expect to see and don't know how would it affect multithreading. Will check, of course. 15:48
Yet, since instantiate_generic clones the original object, it should be no problem.
jnthn It may just be that the RS is generic and instantiation doesn't happen until the usage 15:49
I guess that works out in this case because a variable is instantiable
But it will probably break if we do $foo ~~ Rs
vrurg It reminds me that we don't cache the results of instantiation, each time a new clone is created. Also something to be fixed.
lizmat I wonder if all of this is also related to my "my int @a[1]; @a[0] for ^1000000" being 12x slower than my int @a = 0; @a[0] for ^1000000 15:52
vrurg The smartmatch is certainly broken as RS nominalizes into T. 15:54
lizmat: I guess the difference is made by @a[0] being a sparse cell? 15:58
lizmat no, the prpblem is calls to type_check 16:00
vrurg lizmat: on 2020.11 it's only 3x times slower. One of your optimizations, perhaps?
lizmat gen/moar/Metamodel.nqp:1566
vrurg: my timing is on HEAD
and I haven't touched anything there since 2020.11 16:01
vrurg: how dod you time 2020.11 ? 16:02
*did
vrurg Hm, something is going on here. :) I've merged the latest master into my branch today morning. It gives me same 1.07sec, as 2020.11 – comparing to 4sec on 2020.10. The fast code completes in 0.340sec 16:03
lizmat: time raku -e 'my int @a[1]; @a[0] for ^1000000'
raku -v: Welcome to Rakudo(tm) v2020.11. 16:04
lizmat did you deduct the base time ?
vrurg lizmat: now. Not even sure what you mean by it. Sorry... 16:05
lizmat did you deduct the time for Nil for ^1000000 ? 16:06
vrurg No, I'm just comparing the timings of the two versions. 16:07
lizmat well... that's not the difference in efficiency, as both have at least 120 msecs startup 16:09
vrurg There is almost nothing to deduct. `Nil for ...` runs for about half the time, as the fast code.
lizmat right, which doubles the factor between slow and fast code
16:11 Altai-man joined
vrurg I have made the number of reps x10 more. It's even more astonishing. 2020.10 is 43.56 vs 0.8. Nil is done in 0.34. 2020.11: 7.8 vs 0.8, Nil is 0.37 16:11
16:13 sena_kun left
vrurg Doubles or not, but 2020.10 is 5.6x slower than 2020.11. And it seems to be getting slower with the higher number of repetiions. 16:14
lizmat I did work on that area between 2020.10 and 2020.11, yes 16:15
but my point was that a shaped int array access is still very much slower than a non-shaped array access
and that's because of all the type-checking it apparently needs to do for *every* postcircumfix:<[ ]> access 16:16
type_check
gen/moar/Metamodel.nqp:1566
find_method
gen/moar/Metamodel.nqp:1469
those two are responsible for 50% of CPU usage
and if you look at type_check, it will tell you that the class is somehow "not composed" yet 16:17
vrurg I need to go now. Not sure how is this related to coercions, but that's definitely something to look at. 16:19
lizmat well, it has to do with typing :-) 16:20
culater
18:02 zakharyas left 18:10 MasterDuke left 18:26 domidumont left 19:01 domidumont joined, domidumont left 19:52 MasterDuke joined 20:12 sena_kun joined 20:13 Altai-man left 21:21 zakharyas joined
MasterDuke c question. this github.com/MoarVM/MoarVM/blob/mast...ay.c#L1379 `offsetof(MVMArray, body.elems);` is a compile error when i make body a pointer '‘0->body’ is a pointer; did you mean to use ‘->’'. if i change it to `body->elems`, it's also a compile error 'cannot apply ‘offsetof’ to a non constant address' 21:31
i'd never seen/used offsetof before, so i just did some googling and it seems like maybe there is no good replacement? they all use possibly-undefined behavior 21:33
but i'd be happy to be proven wrong 21:34
21:41 sena_kun left 21:47 zakharyas left
timotimo it is impossible 22:24
you'd have to generate different operations to get at the body array 22:25
er, the count i mean, in this case
MVM_op_sp_get_i64 is basically you have a pointer to something in a register (so it's an obj register or perhaps a string register i guess) and you want to get a 64bit integer from its body 22:26
it just takes an offset, and the offset is baked into the bytecode you're generating
if there's an op that does the equivalent of "follow a pointer", that could go in front of the sp_get_i64, then the offset would just be from "what the pointer points at" to the field you're interested in 22:27
22:33 MasterDuke left 23:08 MasterDuke joined
MasterDuke timotimo: that's annoying. but why isn't the offset a constant compile-time value? elems is the first thing in the body struct 23:09
timotimo because the pointer may point at any location in memory 23:10
MasterDuke hm. do we have this follow-a-pointer op already? 23:15
for the problem of just getting moarvm to build i'll comment out the MV_OP_elems case for now. but will have to figure something out 23:17
timotimo yeah, just leave it for later 23:22
MasterDuke well, made the trivial changes so moarvm compiles, but building nqp dies almost instantly (to no surprise). a problem for another day 23:26
timotimo meanwhile i'm finally working on something kinda nice again 23:30

Powered by Cro and the Raku® Programming Language.

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

Thank you!