Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-08-04

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

All times shown according to UTC.

Time Nick Message
01:47 colomon joined #moarvm
06:43 FROGGS joined #moarvm
06:53 nebuchadnezzar \o
06:55 nwc10 o/
07:09 rurban_ joined #moarvm
07:10 nebuchadnezzar the NQP .moarvm files are installed under /usr/share/nqp/lib/, so they are architecture independant files? I should have the same .moarvm files if I build nqp from amd64, i386 or armhf, right?
07:11 JimmyZ yes
07:13 nebuchadnezzar So I need to split the NQP Debian packaging more, with the .moarvm files and .jar in their own packages
07:20 nwc10 the files are architecture independant and the file reader in MoarVM is backwards compatible
07:20 nwc10 so unlike what Parrot ended up with, newer MoarVM will (or it's a bug) run older files
07:21 nwc10 (and newer NQP will build existing Rakudo. Unless there are real flag day changes, but that feels it would be a problem post Alpha)
07:21 nwc10 IIRC packages for parrot, nqp and rakudo had to be in lockstep, with exact versions matching
07:21 nwc10 certaily, moarvm is designed to be only a miminum version requirement
07:22 nebuchadnezzar thanks for the explanations, actually, it looks like any new NQP requires the latest MoarVM
07:22 nwc10 yes, that's usual
07:22 nwc10 I meant the other way round
07:22 nwc10 (sorry, wasn't clear)
07:23 nwc10 with parrot, at least at one point
07:23 nwc10 NQP 2014.03 would require parrot 2014.03
07:23 nwc10 and parrot 2014.04 wouldn't load .pbc files written by parrot 2014.03
07:23 nwc10 so if you upgraded parrot, you had to rebuild nqp
07:23 nwc10 I don't know if that got fixed/improved later on
07:23 nwc10 but there was certainly a time in the middle where it was that way, and annoying
07:24 brrt joined #moarvm
07:24 nwc10 what I meant was, next month or 3 months from now, you can upgrade the MoarVM package
07:24 nwc10 and the existing, built, NQP and Rakudo will be happy
07:24 nwc10 (and if not, that's a bug that we'll address)
07:25 nebuchadnezzar ok, I understood the other way ;-)
07:26 zakharyas joined #moarvm
07:28 brrt good *
07:49 brrt timotimo: that's ok, it's not your job after all :-)
08:13 zakharyas joined #moarvm
08:16 zakharyas joined #moarvm
08:36 dalek MoarVM/even-moar-jit: 50279e7 | brrt++ | src/jit/ (3 files):
08:36 dalek MoarVM/even-moar-jit: Implement initial tiler
08:36 dalek MoarVM/even-moar-jit:
08:36 dalek MoarVM/even-moar-jit: Tiling is probably seperate from emitting code.
08:36 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/50279e7b95
08:37 [Coke] joined #moarvm
08:37 Util joined #moarvm
08:37 japhb joined #moarvm
10:49 colomon_ joined #moarvm
10:49 timotimo brrt, but i've offered to do it and i'd be happy to see the jit advance more quickly ... :|
10:53 colomon joined #moarvm
11:38 timotimo well, i parse op_to_func properly now, it seems
11:39 jnthn .oO( parse that right now, the func op brother )
11:40 timotimo tee hee
11:43 timotimo pancakes!
11:43 jnthn envy!
11:55 arnsholt Indeed. I almost asked if they were the French kind or the American kind, but realized it doesn't really matter
12:12 brrt joined #moarvm
12:13 brrt hai
12:15 brrt what's the difference between french and american pancakes
12:15 brrt timotimo++
12:15 timotimo american pancakes are much thicker and fluffy
12:15 * brrt just cleaned up his apartment and recieved a new desk
12:16 timotimo oooh, a new desk
12:16 brrt as in, i got to use a desk that was unusable before
12:16 timotimo i just arranged getting new monitors
12:16 timotimo one of my current monitors is beginning to die
12:16 brrt also very nice
12:16 brrt so you got a few to replace them?
12:17 brrt i use only one monitor and find myself following the cursor by head movement, so i'm not sure i'd need multiple
12:18 timotimo "a few"? no, just two
12:18 timotimo two before, two after
12:19 timotimo i really appreciate having, for example, vim open on one monitor and some terminals on the other
12:19 timotimo and on my first workspace, i usually have a browser on the left screen and irc and IM on the other one
12:20 brrt HMM
12:20 brrt oh oops caps
12:21 timotimo brrt: how would you represent the fact that we can only devirtualize reprops if a given fact is present for a given argument?
12:21 brrt not yet there
12:21 timotimo that won't fit into the file parse_jit_graph.p6 will generate, right?
12:21 brrt no, and it doesn't matter
12:21 timotimo good
12:22 brrt in fact, you can skip reprops as far as i care
12:22 brrt or, maybe not
12:22 brrt that makes it more difficult for you
12:22 brrt no, my hypothesis was this
12:22 brrt first generate the repr call as the full virtual call template
12:23 brrt then, *if* you know off the type fact, you can replace the virtual-call-address-loading to a constant function pointer
12:23 brrt in  an optimization pass
12:23 timotimo ah, so instead of refering to the reprconv functions, we'll fully generate the *contents* of the reprconv functions
12:23 timotimo that'll make it totally amendable to constant folding
12:23 brrt aye
12:23 timotimo good
12:24 brrt constant folding is exactly what i mean
12:24 timotimo perfect
12:25 brrt although honesty forces me to declare that i'll probably only implement the skeleton of an optimizer for the JIT
12:26 timotimo that's no problem at all
12:26 timotimo that seems to be the kind of thing i enjoy doing :)
12:26 timotimo no guarantees, though
12:26 brrt oh, i know soo many things one can do
12:27 timotimo the infinities are possible!
12:29 brrt :-)
12:29 brrt are you planning to go to yapc::eu this september?
12:29 timotimo no, i'll only attend SPW
12:31 brrt which i won't attend... shame
12:31 timotimo damn :|
12:32 brrt yeah
12:33 timotimo maybe i'll stay interested in perl6 even after its "public release"
12:33 timotimo and perhaps you will, as well
12:33 timotimo and then ... maybe ... one day
12:33 timotimo we'll meet
12:33 brrt :-)
12:37 brrt it should be possible
12:38 timotimo do you suggest i immediately emit the full reprconv-inlined-tree format from jgb_consume_reprop? or should i start with emitting calls to the regular reprconv functions unconditionally for the time being?
12:38 timotimo reprops aren't really rare in jit code
12:38 brrt preferably the first, but i could imagine that to be hard
12:39 timotimo it would be sad if such common ops would cut up the optree-based jit pieces so regularly that the optree can't generate terribly good code
12:39 timotimo i can do it, but it may be super nice if you could at some point provide a template for the reprconv functions
12:39 timotimo in fact, if you could provide only two or three templates i can cargocult the rest of them
12:40 brrt well, for that case, i want to have a jit op for the type to generate a exprtree segment, or maybe just an exprtree template
12:40 brrt oh, templates for reprconv virtual calls?
12:41 brrt i was talking about directly inlining e.g. array access
12:41 brrt which is possible, damnit
12:41 brrt virtualized hardcoded jit templates
12:41 brrt yes, i'll make one for you
12:41 brrt which one do you want
12:42 timotimo let's see
12:42 brrt google calendar sends me to the mobile page with epiphany... many wow
12:43 timotimo give me MVM_repr_exists_pos, MVM_repr_at_pos_o, MVM_repr_bind_key_i and _n, MVM_repr_exists_key
12:43 timotimo that should get me very far
12:44 timotimo hm, the _attr_ functions will be interesting, too, but i suppose they can wait a little bit
12:44 timotimo since we turn attribute access into spesh'd direct access often-ish anyway
12:45 brrt aue
12:45 brrt aye
12:45 brrt ok, let me see
12:47 timotimo if the template looks the same as these functions with regards to their arguments, i'll be able to re-use the latter half of consume_reprop and just "call" the template instead of the reprconv function
12:47 brrt aye
13:03 jnthn Isn't the answer to "what's the difference between X and american Y" always "american Y are bigger"? :)
13:03 brrt huh, yeah
13:04 timotimo what's the difference between music and american music"? :)
13:05 nwc10 what's the difference between pints and American pints?
13:05 nwc10 (also)
13:05 nwc10 and I'm not convinced that the answer holds universally for "Beer" either
13:06 brrt american pints have high fructose corn syrup as their main ingredient
13:07 brrt (if you want to make something evil in american, just add 'big' before it)
13:08 nwc10 big hug!
13:08 * brrt fears
13:08 brrt :-P
13:23 brrt damnit
13:23 brrt repr ops assume memory-to-memory
13:23 brrt that's not compatible with my register-to-register model
13:23 timotimo ah, damn
13:25 [Coke] my favorite bartender always used to ask me if I wanted a 16 oz pint or a 20oz pint. :P
13:25 zakharyas joined #moarvm
13:25 [Coke] (sad story - he semi-retired, opened a bar in our shared home town, which closed over a year ago, and he just died, apparently)
13:25 brrt i'm incapable of saying enough things to deter the use of imperial units
13:26 brrt imperial units are a blight upon my working, or at least studying, existence
13:26 brrt with the top of these all, the british thermal unit
13:26 brrt what the hell
13:26 brrt (that is a sad story, though :-o)
13:27 timotimo yeah :(
13:27 timotimo argh
13:28 timotimo all i want to do is swallow up some potentially curly blocks properly ...
13:28 timotimo |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  curly_block
13:28 timotimo something says me i'm doing it wrong somehow
13:37 dalek MoarVM/even-moar-jit: 8904fef | brrt++ | src/jit/ (2 files):
13:37 dalek MoarVM/even-moar-jit: Add elems reprop as an example for timotimo+
13:37 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/8904fef6c0
13:38 brrt ok, i can add the address of a writeable register as a parameter by default, or specially if it's a repr op
13:38 brrt but at any rate it requires some special handling
13:43 timotimo that doesn't look terribly hard
13:43 timotimo but i agree the memort-to-memory vs register-to-register thing could be solved better :\
13:43 timotimo or "could be a problem"
13:44 brrt not hard, but i don't like special cases
13:44 brrt huh
13:44 brrt i think i know how to generic-case this
13:44 brrt let me think about that a bit
13:45 brrt bbiab
13:45 timotimo how will the jit learn about/discover functions supplied by a repr?
13:46 timotimo like, if there's a jit optree alternative for a REPR's elems function, for example
13:47 brrt by means of the example for spesh (src/6model/6model.h:593)
13:47 brrt known type? known type can jit? get that template instead of the generic one
13:47 timotimo oh
13:47 timotimo fair enough
13:48 timotimo in that case we can't just rely on constant folding any more, though
13:48 timotimo for the reprop thing, i mean
13:48 timotimo if the reprop wants to supply a optree based version
13:56 zakharyas joined #moarvm
14:00 dalek MoarVM: ef22a17 | timotimo++ | src/jit/graph.c:
14:00 dalek MoarVM: this default case isn't supposed to be reachable
14:00 dalek MoarVM:
14:00 dalek MoarVM: but in case it does get reached at some point, properly
14:00 dalek MoarVM: bail out of everything.
14:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ef22a179ea
14:00 dalek MoarVM: e313294 | timotimo++ | tools/parse_jitgraph.p6:
14:00 dalek MoarVM: WIP on parsing jit/graph.c for conversion to optree
14:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e31329459c
14:21 brrt no, but these cases are supplementary
14:21 timotimo fair enough i suppose?
14:23 brrt either you constant-fold the repr func to devirtualize, or you implement a repr-specific template
14:23 brrt both are better than the naive case
14:23 timotimo mhm
14:25 timotimo i think i'm going to take some kind of break and look at the parsing stuff with a fresh set of eyes and brain :P
14:25 timotimo maybe i'll make the curly block skipping much dumber, so that it won't understand } inside /* */ or after //
14:31 brrt makes sense, yes
14:31 brrt ok, let me specify the generic case
14:32 brrt i can add a sigil of sorts, maybe !, to signify that 'this template includes a store'
14:34 brrt if i do that, then i do *not* define the value there, it does not enter the tree as such
14:34 brrt wait, wht
14:34 brrt what
14:35 brrt but i actually do not think that is a good generic case
14:35 brrt better then to use the reprconv function and add it to the tree
14:50 dalek MoarVM: cf06824 | brrt++ | src/jit/graph.c:
14:50 dalek MoarVM: Rethrow does not have a writeable register
14:50 dalek MoarVM:
14:50 dalek MoarVM: And it's object is read from variable zero
14:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cf06824324
14:50 brrt dinner &
15:04 timotimo time to golf
15:08 lizmat joined #moarvm
16:11 timotimo my code is somewhat unhappy. i'll just make it much more simple and just require that no { } appear inside comments.
16:11 timotimo since i'm in full control of the source data anyway, that seems acceptable
16:23 rurban_ joined #moarvm
16:28 timotimo i killed moar, but control isn't coming back to my shell :|
16:30 timotimo oh, it was merely waiting for input and didn't display the prompt promperly
17:03 lizmat joined #moarvm
17:49 FROGGS joined #moarvm
18:11 colomon joined #moarvm
18:41 lizmat joined #moarvm
19:02 timotimo before i dig back into the parsing thing, i'll have a quick look at the code gen thing you mentioned
19:07 timotimo ok 94 - Array elements have new values after assignment (2)
19:07 timotimo Cannot assign to a readonly variable or a value
19:07 timotimo jnthn:  ^- this is expected and it's just a TODO on your list?
19:08 timotimo hm, that seems quite a bit earlier than potentially intended
19:09 colomon joined #moarvm
19:09 jnthn Oh...I have a local patch to Rakudo to fix a place it was inconsistent with JVM...
19:09 jnthn Forgot about that...
19:09 timotimo ah, i see
19:09 jnthn haha, that means you're probably the first person to run the gist :)
19:09 timotimo ;(
19:10 timotimo sad-haha, in that case
19:10 jnthn .oO( Did jnthn forget...OR WAS HE SNEAKY??? )
19:12 timotimo could ust as well be the case that everyone just ran the benchmark
19:12 jnthn That's also true
19:12 jnthn Or they noticed but didn't want to bother me :)
19:14 timotimo will the benchmark flush pull-one into my spesh log?
19:14 jnthn Sure
19:15 jnthn But
19:15 jnthn If you grab the one benchmark we lose and put it into the profile target
19:15 jnthn Then you can run just that
19:15 timotimo fair enough
19:20 timotimo oh, you told me to find the iterator of GLRmap, but the benchmark we're losing on is for GLRfor
19:21 jnthn I think that for does a map though?
19:23 timotimo it just grabs the iterable it's passed, which is an xx in this case
19:23 timotimo did i put the wrong piece of code into the profile sub?
19:31 timotimo well, the code tests properly now
19:38 colomon joined #moarvm
19:43 timotimo so ... which pull-one exactly am i supposed to look out for? :S
19:45 jnthn timotimo: oh damn, yes...
19:49 jnthn timotimo: Actually one of the other benchmarks that does map is good
19:49 jnthn Even the simplest one
19:49 jnthn GLRfor(('beer' GLRxx 100000).GLRmap(*.uc), -> $beer { })
19:49 colomon joined #moarvm
19:49 timotimo good
19:50 jnthn We do win that benchmark but...you can see in the profile we've room to win by a good bit more
19:51 timotimo i'll have a look at the profiler output, too
19:54 timotimo oops
19:54 timotimo i accidentally pasted the before rather than the after ...
19:55 jnthn "oh no, did jnthn REALLY have a long-running method called reify again?!" :)
19:56 timotimo more like "how the F did we end up with so many things from CORE.setting?!?"
19:57 timotimo but i can see how you'd say we have room for improvement
19:57 timotimo what with find-method
19:57 timotimo i seem tor ecall you were going "wtf, how do we find-method so much?!" recently
19:59 jnthn yeah
19:59 jnthn I didn't work that out yet
20:05 timotimo could it be the find-meth for sink?
20:06 timotimo that's the only one that could potentially surprise you :)
20:07 timotimo that frame has multiple findmeth of course. let's look in the post-spesh to see how many of them are still findmeth
20:07 timotimo and not sp_findmeth
20:08 timotimo yeah, the sink findmeth remains in the post-spesh code
20:09 jnthn I wonder what it's trying to sink...
20:09 jnthn That lacks a method cache
20:09 timotimo i'll have a closer look
20:11 timotimo it's $storage
20:11 jnthn o.O
20:11 timotimo i don't find any mention of '$!storage' or even 'storage' in the code
20:12 timotimo no, wait
20:12 timotimo this is about a hash
20:12 jnthn A...a hash?!
20:13 timotimo yeah
20:13 timotimo an nqp::hash gets created and assigned to something's $!storage
20:13 timotimo probably a high level hash in that case
20:13 timotimo then it tries to sink that
20:14 timotimo um
20:14 timotimo ... sorry
20:14 timotimo i slipped into the totally wrong code object, it seems
20:15 timotimo excuse the noise
20:15 zakharyas joined #moarvm
20:20 timotimo but the sink that goes on there is probably BS, too :P
20:21 timotimo seems to be $redo perhaps
20:21 timotimo more precisely:
20:21 timotimo getlexref gives us the lexicalref
20:22 timotimo later in the code, we try to sink the lexicalref
20:22 jnthn ouch
20:24 timotimo could the lexicalref be sufficiently dumb that we don't have a method cache published or something?
20:25 timotimo this could also be leading to lots and lots of things having a sink block generated for them all over the place?
20:25 timotimo i shall have a look at the code that decides whether or not to emit a .sink
20:25 timotimo and perhaps teach it about lexicalrefs
20:25 timotimo hm, there's a nosink annotation
20:27 jnthn I think p6sink is handled as a QAST -> MAST thing
20:27 jnthn And we could look there if it's a lexicalref
20:27 jnthn It'll be in, iirc, src/vm/moar/Perl6/Ops.nqp
20:29 timotimo hmm, okay
20:30 timotimo so something like if nqp::istype($op[0], QAST::Var) && $op[0].scope eq 'lexicalref'?
20:31 timotimo we have lexicalrefs of type object, too, and those will want sinking ... how do i best reach the variable it refers to to check what getlexref_* type is the right one?
20:32 timotimo i can't walk outward in the qast tree to find the block that holds the definitions
20:35 timotimo the $qastcomp likely knows
20:36 timotimo oh, perhaps $*BLOCK is set at that position and i can ask it
20:39 * timotimo compiles a first attempt
20:41 timotimo it did compile, but it doesn't seem to reduce the amount of find_method happening
20:53 timotimo maybe there's a hllize op in between
20:53 timotimo ===SORRY!===
20:53 timotimo Invalid frame outer index; cannot fixup
20:53 timotimo well, that's great!
20:53 timotimo (while building NativeCall)
20:56 timotimo i'm not readily stumbling over the p6sink that'd cause this problem :|
21:00 timotimo perhaps i've been barking up the wrong tree and this findmethod isn't related to the sink method call
21:08 * timotimo just puts a note into find_method so that it spits out what methods it's looking fo
21:10 timotimo yeah, it does spam "sink" all over my screen for about a bazillion pages
21:13 timotimo jnthn: since the spesh output is ending up with the whole "if isconcrete + can 'sink' + callmethod 'sink'" dance, it's pretty much impossible that this is not going through p6sink, right?
21:15 jnthn timotimo: p6sink desugars into those instructions
21:15 timotimo yeah
21:15 jnthn timotimo: It's not a vM-level op
21:15 jnthn Oh, wait, I missed the "not" in "not going through" :)
21:15 timotimo and the other kind of sink is just 'put a method call for sink into the resulting code'?
21:15 timotimo :)
21:15 jnthn That changes everything!
21:15 jnthn Yeah
21:16 timotimo it's just that i put a $op[0].dump at the beginning of p6sink and i couldn't find anything that'd obviously cause $redo as a lexref to be sinken
21:16 timotimo have i looked wrong? pretty possible!
21:17 jnthn It maches the symptoms though...hmm
21:18 timotimo let me look again
21:18 timotimo yup, i put in an inc_i op that does nothing at all, and it shows up
21:19 timotimo and somehow the $sinkee_res must contain the getlexref_i thing
21:23 timotimo the word 'redo' doesn't appear in the output at all, but to be fair ,it crashes before it compiles all of the program
21:23 timotimo that could be it, though
21:23 timotimo must, actually
21:24 timotimo much better.
21:27 timotimo the only thing that p6sinks $redo is the while loop itself
21:28 timotimo - QAST::Op(while)
21:28 timotimo - QAST::Var(lexicalref $redo :decl()) $redo
21:28 timotimo while doesn't return the first child, right?
21:28 jnthn Um...forget what it returns
21:29 jnthn I think it has some logic to return something
21:29 jnthn But I don't think it's to spec
21:30 timotimo all we care about in this context is the QAST's returnchild or something?
21:31 jnthn Well, I think we do try and take care of returning something from while
21:31 jnthn but we should probably rip that stuff out
21:31 jnthn And have it return nqp::null
21:31 jnthn And maybe give it a :result option like the :nohandler one for HLLs to choose
21:33 timotimo ah, i see where that is
21:33 timotimo push_op(@loop_il, 'set', $res_reg, @comp_ops[0].result_reg);
21:33 timotimo in the "repeat" version, we set the $res_reg to a fitting variation of null
21:34 timotimo in the loop version, not so much
21:35 timotimo let's see ...
21:35 timotimo if the current return value of while is not to spec, and it's supposed to be null or 0 instead
21:35 timotimo maybe with that change in nqp spec tests will still pass?
21:37 jnthn Worth a try
21:37 jnthn And if they don't...we should look at those tests
21:37 timotimo do you want to hear a progress report?
21:38 jnthn Sure :)
21:38 timotimo how does "find_method is now only called 31 times in total" sound to you?
21:38 timotimo and pull-one is now at 48% exclusive time
21:40 timotimo anon at line 900 - the first inner block of GLRFor, the one with &block.count == 1 - is in second place with 25% exclusive time
21:41 timotimo https://gist.github.com/timo/647bba53b9820268558c - my benchmark results
21:41 timotimo time for that spec test
21:44 jnthn timotimo: Wow, nice :)
21:45 timotimo how much better are these benchmark results? i don't remember the previous ones
21:45 jnthn m: say 3.7 / 0.2
21:45 camelia rakudo-moar 5da323: OUTPUT«18.5␤»
21:45 jnthn m: say 3.7 / 0.21
21:45 camelia rakudo-moar 5da323: OUTPUT«17.619048␤»
21:45 jnthn That ratio is way better
21:45 jnthn I'll run mine
21:45 timotimo 18.5 is way better than 17.6, yeah
21:45 jnthn uh, no, those are both yours
21:46 timotimo oh
21:46 jnthn I wasn't fair in the first one, I didn't use same number of sig figs :)
21:46 timotimo ah, ok
21:46 jnthn m: say 4.3 / 0.62
21:46 camelia rakudo-moar 5da323: OUTPUT«6.935484␤»
21:46 jnthn That's before
21:46 timotimo are you serious.
21:46 jnthn So yeah, we're 17 times faster instead of 7 times faster thanks to your changes
21:46 jnthn Yes.
21:46 timotimo that's quite good
21:46 jnthn I knew that was going to be darn costly.
21:46 jnthn When I saw the profile
21:46 jnthn timotimo++
21:47 TimToady \o/
21:47 timotimo spec tests aren't all that happy all in all
21:47 timotimo but i think it's all known problems
21:47 timotimo it'll be finished soon
21:48 jnthn wonder how you helped the others... :)
21:48 jnthn m: say 3.7 / 0.39
21:48 camelia rakudo-moar 5da323: OUTPUT«9.487179␤»
21:49 jnthn m: say 4.3 / 0.90
21:49 camelia rakudo-moar 5da323: OUTPUT«4.777778␤»
21:49 timotimo lock, start and io-socket-async are unhappy here
21:49 jnthn OK, so second to last one from 5 times faster to nearly 10 times
21:49 timotimo probably not because of while changing its return value semantics
21:49 jnthn No, those are flappy
21:49 timotimo cool, i'll clean up the patch and push
21:50 jnthn m: say 3.7 / 0.61
21:50 camelia rakudo-moar 5da323: OUTPUT«6.065574␤»
21:50 jnthn m: say 4.3 / 1.2
21:50 camelia rakudo-moar 5da323: OUTPUT«3.583333␤»
21:50 jnthn And that's improvement on the final one.
21:50 jnthn Nice! :)
21:51 timotimo how do i set an instruction list to have no return value?
21:51 timotimo or should i actually spit out the code to null a register that gets returned?
21:52 timotimo um ... there's an if $*IMM_ARG thing in there
21:52 timotimo i was pretty sure my patch would break it, but that's not what's used for while (^10).pick -> $a { ... }
21:54 timotimo it seems like a fossil
21:55 jnthn Right, the $*IMM_ARG is for ->
21:55 jnthn I think the thing you removed is fossil
21:57 timotimo i'm not so sure about that
21:57 timotimo #push_op(@loop_il, 'set', $res_reg, @comp_ops[0].result_reg);
21:57 timotimo this should be responsible for making the value "the right value" in front of the IMM_ARG thing
21:58 timotimo it used to $*IMM_ARG($res_reg), which is the register i just nulled prior to that
21:58 TEttinger joined #moarvm
22:02 timotimo jnthn: IMM_ARG isn't mentioned in rakudo at all and in nqp there's only a single spot that actually does set it and it's in vm/parrot
22:03 jnthn timotimo: It's only set/used in the code-gen itself
22:03 jnthn timotimo: I'm surprised it leaks out of QAST -> POST tbh
22:04 jnthn (That is, that it shows up in Rakudo at all)
22:04 timotimo um, we might be thinking of different things right now
22:04 timotimo i'm talking about the implementation of nqp::while
22:05 timotimo it doesn't show up in rakudo at all, not even mentioned a single time in its whole source tree
22:05 jnthn I thought you were talking about the IMM_ARG thing?
22:06 timotimo yeah
22:06 timotimo well, look, there's another block at the top that seems to handle "needs_cond_passed" for @children[1]
22:06 timotimo that's completely separate from IMM_ARG
22:06 timotimo what i'm saying is, that the IMM_ARG mechanism in nqp's implementation of nqp::while probably hasn't been used for a while
22:07 jnthn oh, wow
22:07 jnthn Yeah, I see what you mean :)
22:07 jnthn Yes, that one mention looks fossil
22:07 timotimo phew
22:07 timotimo i thought i was going insane :)
22:07 jnthn timotimo++ # persistence :)
22:08 jnthn Sorry, I'm really tired...
22:08 timotimo so, currently our while loop implementation can handle returning "null-ish" values of all four kinds
22:08 timotimo apparently that comes from the condition
22:09 timotimo i'll kick out tthat part of the logic and just unconditionally return an object register that's nulled
22:09 jnthn Leave in the logic that doesn't do it if we want void, though. :)
22:10 timotimo if we wanted void so far, we'd've gotten an integer register instead
22:10 timotimo how can i find out if "the outside" wanted a void register?
22:10 timotimo likely some method on $qastcomp?
22:11 timotimo perhaps a dynamic variable like $*WANT?
22:11 timotimo right, that's it
22:11 jnthn See if/unless
22:11 jnthn It does
22:11 jnthn my $is_void := nqp::defined($*WANT) && $*WANT == $MVM_reg_void;
22:11 timotimo very good
22:14 jnthn timotimo++ # optimization through cruft removal :)
22:14 jnthn Sleepy time; night o/
22:15 timotimo :)
22:15 timotimo good night, jnthn
22:51 timotimo jnthn: this is my experiment with checking candidate size for inlining (rather than original bytecode size): https://gist.github.com/timo/83455292fe1f61a75fea
22:52 dalek MoarVM: fc18ccc | timotimo++ | src/spesh/inline.c:
22:52 dalek MoarVM: spesh inline: check candidate size, not original size
22:52 dalek MoarVM:
22:52 dalek MoarVM: oftentimes, small-ish pieces of code that are just above
22:52 dalek MoarVM: the max inline size before spesh become small enough to
22:52 dalek MoarVM: be inlined; a very short survey of example code reveals
22:52 dalek MoarVM: that an improvement in size of 2x isn't rare.
22:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fc18ccc8dd
22:52 dalek MoarVM: 853b08e | timotimo++ | tools/parse_jitgraph.p6:
22:52 dalek MoarVM: more work on the jitgraph parser
22:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/853b08ee98
22:52 timotimo darn, didn't mean to push the second WIP commit
22:52 timotimo oh well.
22:53 timotimo that change sadly doesn't cause &infix:«<» to be inlined in the beginning of pull-one :|
23:03 timotimo https://gist.github.com/timo/11512a307d720dd182e4 - with this patch applied, &infix:* doesn't show up at all :(
23:04 timotimo but interestingly, lots of places apparently try to inline a .new method into a .new method
23:06 timotimo potentially because we have no candidate that takes an obj first, then a native int register
23:06 timotimo (because our number $i is kept around as a lexref_i)
23:09 lizmat joined #moarvm
23:09 timotimo and we're initializing the int $i with 0 before we grab $!i

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