00:41 jnap joined 01:30 FROGGS_ joined
TimToady if you spesh a lambda, does that spesh all versions of the lambda, or only the current clone? Seems like there's be some way of looking at the data used to create clones, and spesh some of the clones one way, and others of the clones a different way, depending on how they were generated and how they're used in a Higher Order context 03:10
(thinking about meta-functions that return list iterator lambdas implementing some set of list policies) 03:11
I suppose those would likely be different lambdas in the first place, since they're different algos 03:12
and a lazy lambda would spesh separately from an eager lambda 03:13
otoh if mapiter is returning different lambdas, but reusing those lambdas in different contexts, they might not spesh so well 03:16
well, just musings, starting to get my head around the list refactor
07:21 brrt joined
brrt \o 07:21
(appaantly, afk for more than a bit :-) 07:22
)
TimToady: in response to your question about lambda's, i /think/ (but I'm not sure) a lambda is simply a code reference that has an outer frame associated to it, and the code reference is what is speshed 07:23
so all versions of the lambda would be speshed
07:33 klaas-janstol joined 07:46 klaas-janstol joined 07:49 donaldh joined 07:56 FROGGS[mobile] joined 08:40 Ven joined
jnthn Well, at the moment spesh is always attached to the static frame (which is the set of things all closures share in common) 09:04
09:05 donaldh joined
jnthn So isn't variant on the contents of the outer scope. In fact, being used in outer scopes with quite different types will currently make it see the type there unstable and so not specialized on such a lexical access returning a consistent type of thing. 09:05
10:02 klaas-janstol joined 10:17 cognome joined
hoelzro moarning #moarvm 11:35
so I tried golfing down my segfaulty code 11:36
no luck =/
it's something like "remove a method that doesn't get called? no longer segfaults"
timotimo well, if you adhere to the rules of regular golf, that ain't gonna work
you gotta get the ball off the grass
hoelzro I understand that spesh is a complicated beast
11:39 donaldh joined
hoelzro timotimo: I should tee off with a pitching wedge, then? 11:40
timotimo i ... don't actually know any golf whatsoever 11:41
jnthn Join the club... 11:44
hoelzro: This is the one that went away by disabling OSR? 11:45
hoelzro jnthn: yes. disabling spesh helps, but OSR doesn't 11:47
buh dum tsh
jnthn Huh? 11:50
MVM_SPESH_OSR_DISABLE=1 # this helped?
hoelzro it did not 11:51
jnthn oh, I thought you'd said yesterday that it did... 11:53
hoelzro unfortunately, no =/ 11:54
but hopefully that provides some insight 11:55
12:09 klaas-janstol joined 12:22 jnap joined
FROGGS_ jnthn: when we spesh certain code we assume that some objects are of certain type, and deopt when this assumption does not hold anymore.... 12:25
12:25 brrt joined
FROGGS_ jnthn: can't we generate several assumptions / several versions of that code? and choose the one where the assumption holds? 12:26
jnthn FROGGS_: It's already a bit more involved than that. We do generate several specializations, but they are controlled by argument types. 12:27
Deopt is just if we additionally specialize on types encountered on the inside of a routine 12:28
We can't really validate those ones up front.
FROGGS_ what I am thinking of is this: sub foo($a) { if $a ~~ Str { ... } elsif $a ~~ Failure { ... } else { ... } } 12:30
do we generate optimized code where we get rid of the checks when we know it is a Str?
and another version for Failure?
jnthn In that case, you'd get different specializations by the type of $a
Well, nqp::istype(...) certainly gets optimized 12:31
timotimo are we able to inline the .ACCEPTS there?
since we have a WVal we're calling the method on .. ?
jnthn I asked if we could get a language design ruling that a ~~ LiteralTypeObject can be compiled directly to a type check
But didn't get one :(
timotimo mhm :\ 12:32
jnthn So yeah, we'd be relying on inlining there
timotimo at worst inlining at spesh-time?
but it seems like that'd be enough 12:33
jnthn Oh, it's a method call, so always
But Mu.ACCEPTS(:U) takes a huge number of different types
So spesh will struggle a bit on that anyway at present
timotimo hmm 12:34
jnthn I think if we can get it I'd prefer that we can avoid the ACCEPTS call altogether when we see a type on the RHS
timotimo can we do something like ::T: Mu \topic in the signature?
so instead of multi method ACCEPTS(Mu:U: Mu \topic) { nqp:p6bool(nqp::istype(topic, self)) }
we'd have something like nqp::istype(topic, T) 12:35
jnthn We can if you want to make everything a lot slower... :P 12:36
What're you trying to achieve?
Spesh is nothing to do with the declare signature types; it's all about what types show up at runtime.
timotimo oh 12:37
right, the signature binder wouldn't be able to do any optimizations for *methods* 12:38
12:45 brrt joined 13:25 itz joined 13:28 _sri joined 13:38 FROGGS_ joined 14:42 ggoebel1111118 joined 14:53 itz_ joined
TimToady would it make sense more sense to turn ACCEPTS into a multisub? 17:01
it sort of goes against the primacy of the RHS though
jnthn Was gonna say...
TimToady maybe we finally have a use for ;; 17:02
jnthn I'm not quite convinced
TimToady or by convention all RHSs are typed Any, or some such
er, LHSs I mean (of ~~) 17:03
the intent of making ACCEPTS a method was not to achieve late binding, but to make the RHS the decider 17:04
jnthn Right; the question is more what we're allowed to decide statically
TimToady perhaps we can achieve that by convention rather than by using method dispatch
jnthn I mean, optimizing it to a jump table means cheating too
As in, somebody potentially could go and tweak Int.ACCEPTS. 17:05
TimToady but we can enshrine useful sorts of cheating as "just the way the system works"
jnthn Yeah
In which case the ~~ SomeType one is no worse than the jump table one :) 17:06
Not to mention we already provide a correct peg to hang consistent type system hackery off
TimToady so multi ACCEPTS(Int $rhs, Int(Cool) $lhs) is kinda the normal way to write it, and the Any case just wails 17:07
possibility of even a uint8(Cool) there to pick up small jumptableables 17:08
as an alternate multi 17:09
but maybe that's stretching the semantics of coercion too much
might rather decide it as a simple conditional inside the Int(Cool) multi
well, for a given switch, you know the range of it 17:10
TimToady should drink more coffee before speculating further, or perhaps even this far :)
TimToady too often falls into the trap of saying things out loud to see if they might be meaningful :) 17:11
is there any point in keeping the method form of .ACCEPTS then? we could export them all and translate ~~ to the functional form, but maybe they just want to turn into functions, since they're really an intrinsic part of the current language design, which should scope lexically 17:14
jnthn I think some ruling on how we're allowed to cheat is going to be more valuable than making it a multi, fwiw.
diakopter coffee as meaning 17:15
TimToady no intrinsic meaning, but the end justifies the beans
jnthn :D
That's the best thing I've heard all week... :P
diakopter talk about hill-climbing the beans 17:16
TimToady you must have had a terrible week if you find that most stimulating 17:17
but why cheat if we can simply include it as part of the definition of the current language and get the same benefit. objects should not be defining language policy, and optimizability is definitely more in the realm of language design, not object behaviors 17:19
jnthn Probably 'cus I'm change-weary. OTOH, not many folks write custom ACCEPTS methods, so fallout should be small 17:20
TimToady we don't really want people abusing the ACCEPTS mechanism anyway unless they really know what they're doing
and in that case, they can stand to export it as a language feature, not have magical smartmatch distruction at a distance 17:21
this seems like a teeny change compared to the list refactor we know is coming... 17:22
jnthn True
TimToady oh wait, I was trying not to discourage you :)
17:22 brrt joined
TimToady anyway, to me, the question "can I cheat here?" is a design smell that probably means I've botched it and hung someone's coat on the wrong peg 17:23
and ACCEPTS currently feels like it's on the wrong peg to me 17:24
and you'll note that pretty much everything else that is uppercase is baked into the language lexically :)
and indeed, that was part of the motivation for making EVAL uppercase, to indicate that it has such ramifications to the code around it 17:25
it's yelling "uncheat! uncheat!"
as it were...
jnthn *nod* 17:26
TimToady or "deopt! deopt!" rather :)
jnthn It does also allow the compile-time opt to nail it more naturally
I'd rather we don't yell "deopt!" too often :)
TimToady I mean, basically the same reasoning we made subscripts lexical 17:27
jnthn *nod*
TimToady it's just too fundamental to entrust to OO
TimToady is obviously trying to say enough to get burned as an OO heretic someday... 17:28
but the fact is that our current machines do not do either FP or OO naturally, and at some level in the stack you have to abandon all hope of abstraction when you enter :) 17:31
that's why we get implementors in torment, really... 17:32
otoh, and argument against turning ACCEPTS into function is that many of them probably want private access to the innards of self 17:41
maybe multis defined in a class should automatically be trusted
or are they already trusted? 17:42
jnthn Well, they don't get easy access to the attributes if they're not methods, which is more of an issue... 17:43
TimToady see my code on #perl6 17:45
17:57 zakharyas joined
timotimo .o( haven't you heard the story of the kid who cried "deopt!"? ) 18:30
TimToady sure, but as a rancher, I try to shoot any deopt I see on my land 18:33
19:01 klaas-janstol joined 19:19 ggoebel1111119 joined 19:22 klaas-janstol joined 19:56 brrt joined 20:00 brrt left 20:16 jnap joined 20:31 mj41 joined
mj41 hi. nice presentation research.scee.net/files/presentatio...CAP_09.pdf Pitfalls of Object Oriented Programming, Tony Albrecht 20:34
20:42 klaas-janstol joined
TimToady yes, and quite germane to our optimization efforts; czech it out :) 20:52
this is essentially the same kind of thing as what we're imagining for the list refactor 20:53
only we're going about one level more meta, because we're writing something general purpose, not just a game 20:54
timotimo more meta for more bettar?
TimToady Anything you can do, I can do meta. --Annie Oakley 20:55
or maybe that was Annie Treeley 20:56
TimToady wonders if there's any way to measure cache misses in our current implementation 20:58
or missed branch predictions 21:00
21:03 colomon joined
mj41 TimToady: You are a lucky one. I just clicked on reddit link www.reddit.com/r/perl/comments/283r...rl_script/ ... gist.github.com/mj41/20c70566564283151714 21:05
But don't know if it is useful. 21:06
TimToady it's interesting anyway 21:07
but optimizing startup might be a very different beast than optimizing downstream from that 21:08
and obviously we're already doing better than P5 percentage-wise
which version of perl6 is that? 21:09
timotimo holy wow. that number ought to go down some. 21:11
mj41: can you give us your number for nqp-m -e 'say(1)', too? 21:12
TimToady can't find a version of perf that works with 3.14.1 kernel... 21:15
mj41 gist.github.com/mj41/20c70566564283151714 21:25
TimToady cool, someone should try that on perl6 after jnthn's lazy setting patch 21:29
jnthn Sadly, the lazy setting patches only helped so much... 21:30
I suspect something may be "leaking" usages still...
The fact it deserializes in such a way that it traces the object graph, otoh, may have decreased cache misses a good bit. 21:31
mj41 also see "/usr/bin/time -v" result gist.github.com/mj41/2731bd8258052ed5439c 21:32
Maximum resident set size (kbytes): 109816 vs. Maximum resident set size (kbytes): 4164 :-( ... but you probably already know guys 21:33
jnthn Yes, also that number seems to include mmap'd stuff that'd be shared between instances. 21:34
Since the number I have on Windows is over 20MB lower than that, which is about equal to the size of the bytecode files...
TimToady in general, I think batching works better for cache coherency than laziness, so you have to do a lot of lazieness to make up for that 21:35
jnthn TimToady: Well, it does an entire isolated chunk of the object graph at a time, down from the root you ask for. 21:36
So it's only so lazy.
timotimo jnthn: gist.github.com/timo/973cec2a3b14f080555c - got a hot tip how we could teach spesh about the relation between p6bool and if_o and such? 21:44
i think it'd be a worthwhile thing to teach spesh that p6bool's return values are decont'd already 21:45
oh, huh ... p6bool_discover already sets known_deconted 21:47
jnthn Do we not already do that?
So yeah, the decont should go away for sure 21:48
timotimo wait
i may be in a before-frame
yes ... 21:49
i should fix the spesh diff script ...
huh? the decont seems to be there still ...
mj41 the last update gist.github.com/mj41/20c70566564283151714 ... including while (($i = $i + 1) <= 100000000) loop .. going to bed, good night 21:53
FROGGS_ gnight mj41
jnthn o/ mj41 21:54
21:57 dalek joined
diakopter cool! that jit performance is really great. 21:57
is there a way to get the JIT to emit a disassembly of the machine code it emits?
jnthn iirc there's an env var you can set where you give a directory to dump a file in per thing it jits 21:58
And then you an view those...somehow 21:59
brrt++ can give you a proper answer :)
btyler_ MVM_JIT_LOG=<file> I think
TimToady wonders if it's possible to make EVAL non-poisonous by parameterizing it with the things it needs to keep track of
diakopter I thought that's called using macros 22:00
TimToady oh, that was a #perl6 discussion...
btyler_ irclog.perlgeek.de/moarvm/2014-08-11#i_9165257 # MVM_JIT_LOG example
TimToady diakopter: no, macros are the dual
jnthn btyler_: That's different; it doesn't spit out the machien code, just logs what it did while producing it (or trying to)
btyler_ oh apologies
jnthn Also useful, though :) 22:01
btyler_ MVM_JIT_BYTECODE_DIR then? 22:02
mentioned in docs/jit.md, at least 22:03
timotimo yeah, the jit log is very helpful for finding out when the jit bails 22:04
jnthn btyler_: yes, that one :) 22:06
btyler_ I knew I had seen it around, should have consulted the docs before the irclog 22:07
brrt++ that there are docs to consult
timotimo jnthn: is there any kind of information we could generate/use to make p6bool + if_o turn into an if_i?
because i'm not seeing anything that'd fit
jnthn timotimo: Nothing yet. I'm pondering it. Don't have a clean answer yet. 22:08
22:09 Ven joined
timotimo at least p6bool doesn't allocate, right? it just returns either an instance of True or an instance of False 22:10
so it's probably not terribly costly
jnthn Right 22:11
I'm leaning towards saying that we probably shouldn't generate such crappy code to being with... :)
timotimo well ... yeah :)
jnthn Meaning the solution lies in telling the code-gen for p6bool that it's in a boolean context. 22:12
Maybe by letting p6bool be marked as a thuthifier
istrue could be done the same
And then the code-gen that spits out the like of if_o could just say "oh, I can skip taht op and if on the thing inside of it" 22:13
So I'd probably solve it at that level rather than spesh.
timotimo gist.github.com/timo/973cec2a3b14f...tfile2-txt - okay, *this* is weird 22:14
we create a p6bool and check it against a type we get from a wval
*all* of that could become an unconditional goto, no?! 22:15
jnthn Correct...so why doesn't it, given we're meant to be putting facts on p6bool?
timotimo that's from infix:<==> 22:16
jnthn discover_crate on perl6_ops.c looks legit... 22:17
And discover_p6bool calls it
timotimo i thought so, too
jnthn So...odd
timotimo and discover_extop, too
japhb \o/ # Windows support patches from jnthn++
timotimo hm
is discover_extop looking at the right extop list?
japhb jnthn: Aside from the problem of not being able to have more than one perl5 built at a time (since from your patch it appears they all install in the same place), is perl6-bench now properly ported to Windows? 22:18
jnthn japhb: Not really; I've a couple more utter hacks I need to turn into sane patches
japhb Heh
OK, gotcha. 22:19
jnthn But that was the majority of them.
japhb I'm glad. I tried to be as minimal as possible about obvious portability issues.
timotimo gdb is weird. 22:29
"frame 0" puts me into the p6bool_discover, but list gives me code lines from the outermost frame 22:30
jnthn wtf... 22:36
4/63: Testing while_empty ...
Failed to run command: install\bin\perl6.bat --optimize=3 -e my $i = 0; while (++$i <= 262144) { }
Turns out the thing in timotimo++'s graphs is quite reproducable, given it seems to ahve happened here too 22:37
japhb Yay for reproducability! Boo for the reproducable thing being failure! 22:44
TimToady in other words, failure isn't an option :) 22:45
timotimo the graphs where the jitted perl6-moar aborts early? 22:50
jnthn yes
Did you figure anything out about it?
timotimo no, didn't investigate any further yet 22:51
japhb jnthn: Does the same command also fail when just run directly from the command line? 23:06
(aside from running it in the correct directory and quoting properly) 23:07
23:09 klaas-janstol joined
jnthn C:\consulting\rakudo>perl6-m -e "my $i = 0; while (++$i <= 262145) { }" 23:13
Invalid SC index in bytecode stream 23:14
WAT!
timotimo o_O
japhb OK, that one is straight up surprising
jnthn Goes away with MVM_JIT_DISABLE=1
japhb: Not half!
I don't even... 23:15
:)
japhb heh
jnthn I can understand various failure modes but that one is like... o.O
japhb No kidding
23:18 klaas-janstol joined
timotimo jnthn: how do you feel about me implementing a reprconv for newtype? 23:23
and jitting newtype?
hm, only 2 bails for tadziks whole log 23:24
i surely am looking forward to param_* being implemented in th ejit :P 23:25
actually, i think it's bedtime
maybe until tomorrow jnthn will have found the empty loop bugification as well as the p6bool mystery
:)
oh, huh, nativecallinvoke seems like a super simple op 23:26
it'd probably have to be marked invokish due to callbacks and such
jnthn Maybe not given it runs them in a nested runloop 23:28
It's the only place in Moar that does such horrors 23:29
diakopter why wouldn't that be implemented as a "compiler macro" (emit corresponding code as mast nodes in the qast->mast)? 23:44
(instead of nested runloop)
for speed? 23:45
jnthn It only happens when we get callbacks from C land 23:47
And so there's C callframes on the stack we know nothing about.
diakopter oh that, I thought we were back to newtype
timotimo native call invoke would want a lot of code in the jit to create tight binding between mvm and native code... but for the time being it should be enough to make it just call the invocation function from native call.c 23:51
off to sleep i go
diakopter well, one mitigation/avoidance option is to abandon the interpreted/jit callstack in the thread that contains the C frames and use OSR-type TECHNOLOGY to put them into another thread, and then launch the callback there.. and then any callbacks to C land from there would go back in the now-native-only thread 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!