Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-15

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary