github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:37 coverable6 left, greppable6 left, statisfiable6 left, quotable6 left, benchable6 left, unicodable6 left, committable6 left, tellable6 left, notable6 left, sourceable6 left, squashable6 left, bisectable6 left, nativecallable6 left, shareable6 left, linkable6 left, evalable6 left, bloatable6 left, releasable6 left, benchable6 joined 01:38 coverable6 joined, sourceable6 joined, unicodable6 joined, bloatable6 joined, quotable6 joined, evalable6 joined, statisfiable6 joined, tellable6 joined 01:39 nativecallable6 joined, greppable6 joined, committable6 joined, squashable6 joined, shareable6 joined 01:40 linkable6 joined, notable6 joined, bisectable6 joined, releasable6 joined 03:27 squashable6 left 03:28 squashable6 joined 04:13 Kaeipi joined 04:16 Kaiepi left 07:30 sena_kun joined 07:41 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #1331 from Kaiepi/lego-jit-rv 07:41
travis-ci.org/MoarVM/MoarVM/builds/745737411 github.com/MoarVM/MoarVM/compare/b...ce05394d8a
07:41 travis-ci left
nwc10 "There was an error in the .travis.yml file from which we could not recover." "Unfortunately, we do not know much about this error." 07:43
07:50 domidumont joined 08:11 Altai-man joined 08:13 sena_kun left 09:28 zakharyas joined
jnthn wat :) 10:26
I thought we used azure pipelines instead of travis now?
Altai-man jnthn, we are not strong enough to disable travis's life preserving system yet... 10:32
10:45 leont joined 12:12 sena_kun joined 12:14 Altai-man left
nine It's hard to let go... 12:15
12:19 zakharyas left 13:24 mtj_ joined 13:32 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 13:53 zakharyas joined 14:43 MasterDuke joined 14:54 lucasb joined 15:47 patrickb joined 16:11 Altai-man joined 16:14 sena_kun left 16:17 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 16:20 domidumont left 16:24 domidumont joined 16:54 patrickb left 17:21 domidumont left 18:13 leont left, leont joined 18:58 zakharyas left 20:12 sena_kun joined 20:13 Altai-man left 20:31 sena_kun left 20:34 patrickb joined 20:42 zakharyas joined
vrurg Can somebody help me with github.com/rakudo/rakudo/issues/4056? I'm trying to find a way to obtain the current code object or its signature instance without using getcodeobj, curcode, or any other non-inlinable. 21:03
timotimo the signature or parameter objects are not constant and known at compile time when you're in the code in question? 21:12
vrurg Not if they're generic. Then I need their instantiations. 21:13
Basically, it's the only case when I need them.
timotimo i'm not sure i follow, but could getlexperinvtype be the key here? 21:15
when the parameter is generic, only the constraint is unknown, right? 21:17
but you also only need the parameter itself to get what the constraint is?
vrurg timotimo: Not necessarily. T(Str), for example. Or with github.com/rakudo/rakudo/pull/4058 `my subset RS of T` also works. 21:18
Also, there is a problem with in-signature type captures `sub foo(::T, T $b)` which is also better be resolved via instantiating the second parameter because T could be a nominalizable, wrapped around a role parameter. 21:20
timotimo what do you mean by "instantiating"? 21:21
vrurg instantiate_generic
timotimo wouldn't we at the time of the code being called already have a fully ungenerified type in T? 21:22
oh, you can pass Literally A Type rather than an instance of a type
that's how T could end up a coercive type
vrurg Not the type captures in the signature. It would be more correct for me to say that `sub foo(::T, T:D() $b)` is the only thing which needs to be handled. 21:23
And your case too, right. Some kind of code factory would need it. 21:24
Anyway, ungenerefication is a minor problem. But handling a coercion passed in via a generic is a pure run-time thing where I need the actual Parameter instance to know the final type of it. 21:26
timotimo i still don't entirely understand what object or data you're trying to get via curcode and friends 21:27
vrurg And the only way I currently see to do it is by fetching the current code object, then signature, then pull the parameter out of the signature.
timotimo do we create new Parameter instances when a role gets instantiated with a different type parameter?
vrurg Yes. 21:28
timotimo m: role A[T] { method test(::A, A $b) { } }; class One does A[Int] { }; class Two does A[Str] { }; say .^lookup("test").signature.parameters[0].WHICH for (One, Two); 21:29
camelia 5===SORRY!5=== Error while compiling <tmp>
Invalid typename 'T' in parameter declaration.
at <tmp>:1
------> 3role A[T7ā5] { method test(::A, A $b) { } }; class
timotimo m: role A[::T] { method test(::A, A $b) { } }; class One does A[Int] { }; class Two does A[Str] { }; say .^lookup("test").signature.parameters[0].WHICH for (One, Two);
camelia No such method 'parameters' for invocant of type 'Signature'
in block <unit> at <tmp> line 1
timotimo m: role A[::T] { method test(::A, A $b) { } }; class One does A[Int] { }; class Two does A[Str] { }; say .^lookup("test").signature.params[0].WHICH for (One, Two);
camelia Parameter|60411096
Parameter|60437256
timotimo ok, i didn't know that
so when we go creating these things, couldn't we do a little bit more code-gen so we don't have to do the run-time code object lookup later on? 21:30
we're currently working on lower_signature? 21:31
vrurg I certainly do work on it. :)
timotimo does the perf regression come from lower_signature now creating lookups of parameters via getcodeobj and friends? 21:32
vrurg In first place it comes from nqp::getcodeobj(nqp::ctxcode(nqp::ctx))
Could be nqp::curcode, which I found later, but that would change nothing as it's non-inlinable too. 21:33
jnthn non-inlinable, but a lot cheaper
timotimo i could have gotten all of this by reading your comment on that one issue ...
jnthn I'm not sure I get the new problem though. A parameter holds a type, if you instantiate the parameter it's instantiating the generic type? 21:34
So you can obtain the generic type from the parameter and instantiate that?
(e.g. grab it at compile time out of Parameter)
vrurg jnthn: it does. The problem is to handle cases like `class C does R[Int(Str)]`, or even more complex cases like `subset S of Int(Str); class C does R[S:D]` 21:35
Not to mentions that role code can also play with the type parameter by defining its own nominalizables. 21:36
And then use those in signatures. 21:37
jnthn Yeah, I'd expect it to be quite hard to come up with a design to do those efficiently
timotimo at role instantiation time, build (or select) a piece of code that Does The Thing and have the generic code for the method's signature binding call into a per-role-instantiation-and-per-method stashed code object? 21:38
vrurg But since profiling done by dogbert17 shows the the biggest slowdown comes from extra context allocations, if code produced by lower_signature can be inlined the penalty for using generics could be significantly reduced.
jnthn I didn't look at how the low levels of the coercion changes we done
timotimo hm. i guess that's almost the same as grabbing the Parameter object
jnthn *were 21:39
(yet)
But my rough expectation was that we'd need a form of istype for cases where we coerce
timotimo hm. we can get the role parameter with getlexperinvtype, we can quite possibly have a very cheap check if that's a simple type or one that requires extra work, and put a call to a sub or method that handles complex stuff by getting the code object and such 21:40
jnthn Perhaps so, yes
timotimo that way the curcode call (though it'd haev to be callercode i guess) isn't in the actual code 21:41
vrurg jnthn: The case of plain coercion is as simple as `unless istype { bind( $param_var, $param_type.HOW.coerce($value) ) }`
timotimo and inlining can happen again
jnthn Only if you know it's a coercion type up front
Whereas in this case we don't really 21:42
vrurg timotimo: it's not callercode because we currently talk about current call signature binding.
jnthn But if we have `T $x` as a parameter type then we know it's a type parameter at the point we compile, and that we can look up `T` lexically and be done 21:43
timotimo well, if we want the curcode call to happen after an invocation ...
jnthn In general, we know which more complex pieces more complex types have
oops, which generic pieces
We may lack a way to query that today
But we could calculate the set of things are needed in the type environment 21:44
And look them up and form the hash
And pass it in to instantiate
vrurg jnthn: if a role defines `my subset S of T` and then `method foo(S:D $a)` ā€“ it's only a job for runtime to resolve.
jnthn What is generic here? I don't think we've ever allowed a subset to refine a generic type
vrurg T, traditionally, is the generic. 21:45
timotimo i think vrurg has a patch that makes that possible
vrurg timotimo is right, github.com/rakudo/rakudo/pull/4058 implements subsets over generics.
jnthn Right, but we've never considered soemthing being inside of a generic role as being subject to the outer genericity
It's a major design change and if we do it should not just be considered for subset types 21:46
It's probably very intimately connected to the problem of type declarations in a quasi 21:47
vrurg jnthn: Actually, the PR is more about making nominalizables more transparent at MOP level. The subset S in my example will have S.HOW.archetypes.generic set, no matter how deep the T is buried inside of. 21:48
*of it
Same about the definite, so `S:D.HOW.archetypes.generic` would also be true. 21:49
jnthn Hm, making that transitive makes some sense, but I guess then every mention of the type has to having it instantiated?
s/having/have/ 21:50
vrurg SubsetHOW now have instantiate_generic, as well as CoercionHOW and DefiniteHOW.
jnthn OK 21:51
vrurg Pardon, definite doesn't have it, but neither it needs it.
jnthn So far as the current perf problem goes, I'm afraid this is just the dispatcher thing all over again. We can't do these kinds of changes without having how to compile/run it efficiently as a design consideration. 21:52
timotimo oh, huh, does dispatcher chains have an easy solution for this? 21:53
jnthn I don't have the bandwidth to worry about this until new-disp and rakuast are done.
21:53 Geth_ left
vrurg As a matter of fact, I didn't want to go that deep initially, expecting all of it to be redone with RakuAST. But... 21:53
jnthn Maybe yes, though I was hoping to keep MOP changes implied by RakuAST minimal, because it's already a heck of a job. 21:54
vrurg Actually, to reduce the pain I caused, it feels to me that if we can inject some kind of a local-scoped variable which gets bound to the code object being invoked then the biggest problem of extra context allocations would be eliminated. 21:55
21:55 Geth joined
jnthn It may be possible to make curcode possible to inline 21:55
Which would also maybe help for now?
vrurg jnthn: My changes doesn't bind to QAST in neither way. I'm just trying to utilze them in the signature binding. 21:56
jnthn: I think, that'd be a lot of help.
Though we won't know until try.
jnthn Well yes, but signatures are only really efficient when we compile them, so alas any change to signature binding will involve twiddling with lower_signature
yeah, it looks like the current code object is even stuck in a register so we can turn it into a set when we inline. Wow. 21:57
Gotta be afk for a bit
vrurg I'm somewhat worried about the size of the code generated by lower_signature. But perhaps a method call would be cheaper than using context.
Ok, I'm need to go to. Looking forward for a verdict. :) 21:58
*go too 21:59
22:06 zakharyas left 22:20 MasterDuke left
vrurg jnthn: thanks for the curcode advise. It alone reduced the slowdown from 20-30% to 14-20%. 23:04
jnthn vrurg: Yeah, nqp::ctx is really quite costly 23:05
23:06 patrickb 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!