Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-08-27

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

All times shown according to UTC.

Time Nick Message
03:07 orbus joined #moarvm
05:47 brrt joined #moarvm
05:50 brrt good *
05:50 brrt but mostly morning
06:08 timotimo hey brrt!
06:08 brrt hey timotimo :-)
06:08 brrt i've seen you've been busy
06:08 brrt oh yes, i wanted to tell you
06:09 brrt don't worry about doint sp_guardconc just yet
06:09 timotimo "oh btw you've been doing i tall wrong!"? :)
06:09 timotimo ah, ok
06:09 brrt nooooo that's not what i mean
06:09 timotimo :)
06:09 brrt do i come over often like that?
06:09 timotimo nope
06:09 timotimo not at all
06:09 timotimo early morning humor isn't exactly my specialty
06:09 brrt :-)
06:10 timotimo i was just suggesting these because they cause a crapton of bails
06:10 brrt yeah, i feel a bit guilty for making you do so much work
06:10 brrt yes, well, the solution for that is actually simpler
06:10 timotimo haha
06:10 timotimo have you seen the bail statistics for a full nqp compilation?
06:11 brrt just make the tree a bit smalller and continue with the rest on the old-fashioned way
06:11 brrt for example, the whole prepargs-to-invoke sequence
06:11 brrt there is probably very little gain in making that exprtree
06:12 brrt so when we see prepargs, we can just consnume the invoke, and when done with that, we continue to try and make a tree
06:12 brrt (yes, i did see it)
06:12 timotimo hm, because invoke spills all registers anyway?
06:12 brrt how do you collect the logs of the whole thing
06:12 brrt aye
06:12 brrt and then jumps out, no less
06:13 timotimo i just set the jitlog to stderr and redirect the stderr output of the whole make process to a single file
06:13 brrt so even nonvolatilve callee-saved registers wouldnt help you
06:13 timotimo so there's a bit of redundant data for every single startup in there
06:13 brrt aha... clever
06:13 brrt yeah
06:13 timotimo time for a shower
06:14 timotimo gt_i, lt_i, eq_i, ... these all want the flag-to-value node, right?
06:14 timotimo but other than that, i won't need to write a tile for them?
06:14 * timotimo disappears right after writing a question
06:18 brrt they need new and  fashionable tile implementations
06:18 brrt other than that you're good
06:27 brrt pypy got SIMD, many nice: http://pypyvecopt.blogspot.nl/2015/08/the-end-of-summer-pypy-simd.html
06:27 brrt (when will we get SIMD? some day, m'boy)
06:31 JimmyZ Christmas :P
06:33 brrt that is soon, in my opinion
06:34 brrt ah, it uses numpy arrays to optimize
06:34 brrt that is... hmm
06:37 brrt still a pretty cool result
06:44 timotimo cool, simd
06:51 brrt breakfast &
06:53 zakharyas joined #moarvm
07:11 brrt joined #moarvm
07:49 lizmat joined #moarvm
07:53 FROGGS joined #moarvm
07:58 hoelzro moarning
08:01 nwc10 good *, hoelzro
08:01 hoelzro o/ nwc10
08:05 timotimo o/
08:10 brrt good moarning, hoelzro
08:10 hoelzro o/ timotimo, brrt
08:18 timotimo o/ brrt hoelzro nwc10
08:37 tadzik hello hackathon! \o/
08:38 masak hello hello hello \o/
08:39 hoelzro ahoy tadzik
08:50 zakharyas joined #moarvm
09:07 brrt joined #moarvm
09:09 colomon joined #moarvm
09:22 donaldh joined #moarvm
09:34 Ven joined #moarvm
10:15 Ven joined #moarvm
11:05 Ven joined #moarvm
11:13 colomon joined #moarvm
11:22 Ven joined #moarvm
11:48 moritz hi all
11:48 moritz anybody want to d a MoarVM release?
11:49 moritz would help me with my rakudo + nqp release
11:52 brrt joined #moarvm
11:53 dalek MoarVM: e5753cc | moritz++ | docs/ChangeLog:
11:53 dalek MoarVM: Add a Changelog entry
11:53 dalek MoarVM:
11:53 dalek MoarVM: I am not qualified to infer any other user-visible, noteworthy changes
11:53 dalek MoarVM: from `git log`. Help would be appreciated :-)
11:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e5753cc0b6
11:59 Ven joined #moarvm
12:17 rarara joined #moarvm
12:52 dalek MoarVM/even-moar-jit: 82bff79 | brrt++ | src/jit/ (8 files):
12:52 dalek MoarVM/even-moar-jit: Fix spilling, IF assignment, and other things
12:52 dalek MoarVM/even-moar-jit:
12:52 dalek MoarVM/even-moar-jit: Crash somewhere anyway
12:52 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/82bff791f7
12:56 timotimo hey brrt
12:56 timotimo how good are you with the GC and roots and such?
12:56 timotimo i may need your help :|
12:56 timotimo because this problem is driving me mad
12:57 timotimo hold on, i'll push a branch
12:58 brrt hey timo
12:58 brrt not.. terribly good
12:58 brrt but i'll look, sure
12:59 timotimo thank you so much :)
13:00 brrt yw
13:00 brrt of course :-)
13:01 dalek MoarVM/nfa_to_statelist: 061b0e0 | timotimo++ | / (8 files):
13:01 dalek MoarVM/nfa_to_statelist: implement nfatostatelist
13:01 dalek MoarVM/nfa_to_statelist:
13:01 dalek MoarVM/nfa_to_statelist: isn't correct yet; something about temp roots is wrong
13:01 dalek MoarVM/nfa_to_statelist: review: https://github.com/MoarVM/MoarVM/commit/061b0e0233
13:02 timotimo there's an nqp branch to go with that
13:03 timotimo when building nqp, we'll reach a place where we segfault because one of the MVMCollectable **'s in the temp rootlist points at a bogus address
13:03 timotimo and for the life of me i can't figure out the problem; it may be staring me right in the face, though
13:05 brrt wait a minute, i'll be back
13:23 timotimo i've tried to figure out which exact root it is that breaks, but it didn't help make more sense out of it (even after interpreting the stack both forwards and backwards)
13:24 jnthn timotimo: Um
13:24 jnthn +    MVM_gc_root_temp_push(tc, nfa_obj);
13:24 jnthn That needs to be &nfa_obj, iirc
13:26 JimmyZ timotimo: MVM_repr_push_o(tc, edgelist, MVM_repr_box_int(tc, MVM_hll_current(tc)->int_box_type, act)); # you can't box here after push edgelist to the stack
13:31 timotimo jnthn: oh! is that what i'm doing wrong?
13:31 timotimo translating from the macro to macroless ... of course i forgot to put the & in there, too
13:31 jnthn Well, and what JimmyZ said to :)
13:32 timotimo JimmyZ: please elaborate
13:33 jnthn timotimo: edgelist will be on the C stack and MoarVM doesn't know about that, so if box_int allocates then edgelist will be out of date
13:33 timotimo right, but i put edgelist onto the temporary stack right before that
13:34 timotimo right after allocating it i pushed it onto the stack
13:34 JimmyZ the gc will update the pointer of edgelist if  it moves
13:35 timotimo yeah
13:35 timotimo that's my expectation
13:35 JimmyZ thus it will be out of date
13:36 timotimo but i've rooted "&edgelist" before i did that allocation
13:36 timotimo so the gc will update the value on the stack for me
13:36 JimmyZ the c stack means it on the reg of cpu
13:36 JimmyZ and if gc update the memory , the reg is out of date
13:36 timotimo fortunately i've passed the address of the value to some other place and such
13:37 timotimo the compiler mustn't hold the thing just in a register
13:37 timotimo and if the gc has run in the mean time, that's a whole bunch of frames on the stack that've probably overwritten the registers anyway, no?
13:38 timotimo hm
13:38 timotimo i think i see what you mean, though
13:38 timotimo because the return value of the allocation immediately gets used and perhaps the c compiler doesn't properly restore the value?
13:40 timotimo the only thing to "fix" it that i can think of is putting the allocation a line before that and assign the result into a var
13:41 timotimo but that'd be the very same as far as the compiler's concerned
13:41 timotimo anyway, i make it through a full rakudo build with this
13:42 timotimo now i'll just have to ask jnthn how exactly we can use the nfa_to_statelist instead of deserializing the statelist arrays
13:48 dalek MoarVM: 59ee270 | (Ben Tyler)++ | src/math/bigintops.c:
13:48 dalek MoarVM: Fix memory leak in MVM_bigint_mod.
13:48 dalek MoarVM:
13:48 dalek MoarVM: The temporary bigints created by forcibly upgrading to bigint should always be
13:48 dalek MoarVM: cleared, rather than only in case of div zero.
13:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/59ee270730
13:48 dalek MoarVM: fed17a3 | lizmat++ | src/math/bigintops.c:
13:48 dalek MoarVM: Merge pull request #235 from kanatohodets/master
13:48 dalek MoarVM:
13:48 dalek MoarVM: Fix memory leak in MVM_bigint_mod.
13:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fed17a3d61
13:48 JimmyZ timotimo: re 'fix' ,yes
13:56 FROGGS btyler_++
13:57 timotimo JimmyZ: will it actually make any difference at all? os was the yes for "that'd be the very same"?
14:01 [Coke] btyler++
14:08 JimmyZ timotimo: it is different
14:24 hoelzro btyler++ # num_leaks--
14:34 timotimo JimmyZ: if it's actually wrong, neither the build nor the spec tests provoke a crash from that
14:41 JimmyZ timotimo: it won't crash if the allocation doesn't  trigger the gc
14:42 timotimo that's why i run a whole spectest
14:42 timotimo to provoke a gc trigger in the middle of that
14:42 timotimo i could just do it 10000 times in a loop
14:43 timotimo then it's bound to hit every allocation in there at some point :P
14:46 jnthn timotimo: You can also make the nursery tiny
14:47 timotimo doing it 100k times every time a nfa gets initialized and it's taking its sweet time, but it's not crashing
14:59 Ven joined #moarvm
15:03 JimmyZ timotimo: looks like you could use MVM_repr_push_i for from_to by allocate intarray
15:04 timotimo does it automatically box the int for me?
15:05 JimmyZ I think intarray could avoid box the int .
15:06 JimmyZ if it use intarray type
15:06 timotimo oh, we can do that, but only for from_to
15:06 timotimo that'd be acceptable
15:06 JimmyZ yes
15:07 timotimo i'll have a look at that later; right now i'm trying to patch NQP a bit
15:07 JimmyZ and save size
15:07 timotimo aye
15:07 timotimo and less indirection
15:21 brrt joined #moarvm
15:54 brrt ok, i have ugly news
15:54 brrt hmm
15:54 brrt not terribly ugly, now that i think of it
15:54 brrt the mem abstraction has to go
15:56 brrt also, i have an ugly double free in dasm, and i'm not sure how it happens
15:57 [Coke] m: sub foo($alpha: $beta) { say "$alpha: $beta" }; foo 42, "OH HAI"
15:57 camelia rakudo-moar 47ddca: OUTPUT«Cannot bind to non-existing object lexical 'self'␤  in sub foo at /tmp/KjmNYqPisE:1␤  in block <unit> at /tmp/KjmNYqPisE:1␤␤»
16:01 timotimo i don't think i know what you mean by mem abstraction
16:04 brrt basically, it was the idea that rather than have 2 different tiles per memory access mode, i'd use just one for loading-from-memory
16:04 brrt that doesn't work out, at all
16:04 timotimo oh
16:04 timotimo isn't that what we wanted register selection for in the first place?
16:05 timotimo or is that only "if you use the register-form of this x86 opcode, the register can come from a variable"?
16:05 [Coke] m: say (^10).map: { $^n * 2 + 1 }.perl
16:05 camelia rakudo-moar 47ddca: OUTPUT«Cannot call map(Int: Int, Int, Int, Int, Int, Int, Int, Int, Int, Str); none of these signatures match:␤    ($: Whatever, *%_)␤    ($: &block, :$label, *%_)␤  in block <unit> at /tmp/8ntmTxcOZ8:1␤␤»
16:06 [Coke] whoops, wrong window.
16:22 timotimo brrt: so we need to duplicate almost every tile now?
16:27 brrt nah, only the tiles that have mem refs
16:28 brrt and what is more, these have already been written, they only need to be split apart
16:28 timotimo ah
16:28 timotimo that doesn't sound so doom-ish, gloom-ish
16:28 brrt no
16:28 timotimo cool
16:28 brrt but it requires a bit of a value structure rethink
16:28 brrt and i'm hoping the tile table doesn't explode
16:28 brrt in size
16:28 timotimo mhh
16:29 timotimo also, i'm still supposed to write new tiles for eq_i, ne_i, lt_i and friends if i understood correctly
16:30 brrt well, that's not your job, you know :-P
16:30 brrt but if you want them, then yes
16:32 timotimo well, now i want the jit to get to a good place faster :P
16:33 timotimo and my other task is pretty frustrating and i'm not making progress at all
16:33 brrt ok, well, i'll try to explain it as quickly as possible, as i'm due to have dinner in < 10m
16:34 timotimo oh, cool
16:34 brrt tiles are declared in src/jit/$platform/tiles.list
16:34 timotimo mhm, i've got that open now
16:34 brrt the tile code is declared in src/jit/$platform/tiles.dasc
16:34 brrt which is dutifully included from emit.dasc
16:35 brrt also, tile names are predeclared in src/jit/$platform/tile_decl.h
16:35 brrt tiles are simply declared with s-expresion synatx
16:35 timotimo ah
16:36 brrt first word is tile; second word is name of tile rule function; third is a list that is matched, fourth the terminal that is yielded, fifth an approximation of the costs
16:36 brrt i have to revisit cost calculation someday, so don't worry about that
16:36 brrt the key is, i think, the terminal
16:36 brrt reg should be used for those things that yield a register
16:37 brrt the eq,ne, lt, etc nodes do not yield a register
16:37 brrt instead, they yield a flag
16:38 brrt a condition code on which you can jump, or which you can convert into a byte value
16:38 brrt (the last using the setCC instructions)
16:38 timotimo ah, ok
16:38 brrt setnz, setne, setl, setge, etc
16:38 timotimo right
16:39 brrt declaring a tile is the simple bit
16:39 brrt for e.g. the equal operation:
16:39 timotimo would i build lt_mem and lt_reg? or lt_mem_mem, lt_mem_reg, lt_reg_reg?
16:39 brrt (tile: equal (eq reg reg) flag 2)
16:39 brrt forget about mem
16:39 brrt :-)
16:39 timotimo OK
16:41 brrt if you wished, you could do (tile: equal_addr (eq reg (load (addr reg)))
16:41 brrt but, not important
16:41 brrt the important bit is implementing tiles in tiles.dasc
16:42 brrt because the tile rule declaration is quite long, it's easiest to use the MVM_JIT_TILE_DECL(tile_name) macro
16:42 timotimo i did that
16:42 brrt you have access to the compiler, the tree, the node, the node arguments, and most importantly the *values array
16:43 timotimo right; does the values also include the thing i'm supposed to write to?
16:43 brrt this values array refers to the MVMJitExprValue associated with all nonterminals in your tile
16:43 timotimo because zr_reg for example accesses values[1]->u.reg.num
16:43 brrt yes, that's actually in values[0]
16:43 timotimo k
16:43 timotimo but since i emit a flag, i ignore values[0]
16:43 brrt except, in this case, since you're writing a flag, your not writing to that
16:43 brrt writing a tile that yields a flag
16:44 brrt yes
16:44 timotimo do i need to have a 2x2 switch for sizes of both registers? o_O
16:45 brrt how would you compare the equality of one size with another?
16:45 timotimo right
16:45 timotimo how bothersome :)
16:45 brrt values[0] holds the size of the comparison :-)
16:45 brrt values[0]->size
16:45 timotimo um, wha?
16:45 timotimo the size of the target register?
16:45 timotimo but that's supposed to be the flag?
16:46 brrt size of the computation, i'd.. think... but i'm not sure
16:46 timotimo oh, is it guaranteed both operands are the same size?
16:47 brrt damnit, i know what i did wrong
16:47 brrt no, actually not
16:47 brrt but they should be, and if not i should error out
16:47 timotimo ah, ok
16:48 timotimo so none of my bizniz
16:48 * brrt afk for now
16:49 timotimo kthx!
16:49 timotimo hm, except ... test sets the flag, all i can do for equal is ask for a specific condition to be put into a register value, no?
16:50 timotimo i mean, there's one branch operation for every variant: equal, not equal, greater than, greater/equal, ...
16:50 timotimo so my tile would have to also match a following branching op, or alternatively return a register
16:51 [Coke] nqp::shell complains it requires 7 operands. Not in the docs. :P
16:52 [Coke] ww.
16:52 FROGGS ups, I forgot to update its docs :S
17:43 Peter_R joined #moarvm
18:33 arnsholt joined #moarvm
18:47 Peter_R joined #moarvm
19:06 Peter_R joined #moarvm
19:11 timotimo brrt had a very long dinner so far
19:14 Ven joined #moarvm
19:53 Peter_R joined #moarvm
20:14 brrt joined #moarvm
20:14 * brrt back
20:14 brrt yeah, it's not really fair of me to dump that in your hands
20:15 brrt the template for eq_i and friend basically looks like (flagval (eq $1 $2))
20:15 brrt maybe even
20:15 brrt (convert (flagval (eq $1 $2)) 1 reg_sz)
20:15 timotimo hah
20:15 brrt or
20:16 nebuchadnezzar joined #moarvm
20:16 brrt (flagval (eq $1 $2) reg_sz)
20:16 brrt something like that
20:16 brrt i don't know yet
20:16 timotimo am i mistaken that the only comparison op that generates a flag on x86 is "test"?
20:16 brrt yes, your are mistaken
20:16 brrt *you
20:16 timotimo aha!
20:16 brrt the other one is cmp
20:16 timotimo oh
20:16 brrt test is boolean and -> flags
20:17 brrt cmp is integer sub -> flags
20:17 brrt make sense?
20:17 timotimo right
20:17 timotimo but how do i create eq and friends from that?
20:17 timotimo and reg_sz is just the size a register has?
20:18 brrt yes
20:18 brrt but keep in mind i haven't actually gotten that far :-)
20:22 timotimo AFAIK, i set the flag register with test and then i use different operators to turn flag into bytes and depending on *that* operator i get the difference between eq, ne, lt, gt, le, ge
20:22 timotimo so if i'm not mistaken, the tile for eq and friends has to actually generate a register, not a flag
20:24 brrt well, that would be a logical thought, but no
20:24 brrt it's more convoluted than that :-)
20:25 brrt basically, if you check out MVM_jit_emit_conditional_jump, you see what i'm trying to do there
20:26 brrt the basic rule is; the flaggy tiles generate a condition-code, and jumpy or flagval tiles use that condition code, and dispatch on the basis of the operand that generated the tile
20:26 brrt this is feasible only because there are only a few tiles
20:26 brrt eh, nodes, that generate flaggy conditions
20:29 timotimo why don't it logic!
20:29 timotimo but i understand very well why you make that design
20:29 timotimo otherwise it'd have to test -> to byte -> to flag -> to branch
20:29 timotimo that'd suck
20:30 timotimo would that mean eq, ne, lt, le, gt, ge would all have the exact same implementation for the tile itself?
20:31 brrt aye
20:32 brrt thats exactly what that means
20:32 timotimo then i'll make it a macro :P
20:32 brrt no
20:32 brrt :-P
20:32 timotimo why not?
20:32 timotimo oh
20:32 timotimo i meant a #define
20:33 TEttinger joined #moarvm
20:34 timotimo you meant MVM_jit_emit_conditional_branch btw :)
20:34 brrt yeah, i understood you meant a #define. wouldn't work because dynasm runs before the c preprocessor
20:35 brrt actually
20:35 brrt you could do a #define in this case
20:35 timotimo :D
20:36 timotimo how does it map my tiles to the flag values from that enum?
20:41 brrt the node name? the answer is prosaic
20:42 brrt we read it directly from the tree
20:44 timotimo … yeah, but how do i bring my tile and MVM_JIT_LT to coincide to the same value?
20:47 brrt not sure what you mean now
20:47 brrt or, what do you want to achieve :-)
20:54 timotimo well, when i implement the tile for eq
20:54 timotimo how does the code that emits the conditional branch
20:54 timotimo how does it know that my tile for eq is the tile for eq?
20:54 brrt well, it takes the value of it's first child node
20:55 brrt and switches on that
20:55 brrt it's easier if i implement it myself
20:55 brrt :-)
20:55 timotimo i think so, too x_X
20:55 timotimo because what is that value it switches on? the estimated cost value?
20:55 dalek MoarVM: a2e4c65 | paultcochrane++ | src/core/interp.c:
20:55 dalek MoarVM: Remove unused assignment
20:55 dalek MoarVM:
20:55 dalek MoarVM: clang's `scan-build` noted that the value of `orig` returned from the call
20:55 dalek MoarVM: to `MVM_frame_dec_ref()` wasn't used after the assignment.  This change
20:56 timotimo i'll head over to the hotel
20:56 timotimo i'm quite tired
20:56 timotimo and i'm not being productive at all over the last hours :(
20:56 dalek joined #moarvm
20:56 brrt see also the when_branch tile
20:56 brrt sleep well :-)
20:56 timotimo yes, i see that
20:56 brrt dude, it's, nearly 23:00. you've helped a lot :-)
20:56 timotimo but still
20:57 timotimo where does the value "MVM_JIT_LT" come from when i build the tile?
20:57 timotimo that's been my question all this time
20:57 timotimo i have to somehow put that into my tile
20:57 colomon joined #moarvm
20:57 brrt no, i don't think you do :-)
20:58 brrt see the tile tree *matches* the lt, or eq, or whatever
20:58 timotimo in that case, there must be some magic that i haven.t been able to see
20:58 timotimo oh!
20:58 timotimo OH!
20:58 brrt it implmeents a rule that executes cmp foo, bar
20:58 timotimo so the lt has already been put in there by a template or a macro
20:58 brrt yes
20:59 timotimo my lord. i'm dense
20:59 timotimo off to bed i go
20:59 timotimo tomorrow i might try again. or find something else to do
20:59 brrt the template insert the eq/lt/gt etc. the tile matches it. the flagval dispatches and stores the right cc
20:59 timotimo like zmq binding and then ipython/jupyter kernel implementation
20:59 timotimo gnite and good luck!
20:59 brrt who cares about these things :-P
20:59 brrt yes, you too
21:00 timotimo ptc does :)
21:04 brrt fair enough
21:04 brrt there is a weird, weird mov in my code
21:05 brrt i wonder where it comes from
21:08 dalek MoarVM/even-moar-jit: 3f55d74 | brrt++ | src/jit/ (2 files):
21:08 dalek MoarVM/even-moar-jit: Negative offsets mean jump out
21:08 dalek MoarVM/even-moar-jit:
21:08 dalek MoarVM/even-moar-jit: If you pass a negative offset to the dynamic label facility,
21:08 dalek MoarVM/even-moar-jit: dynasm will crash with a malloc corruption error. As it should.
21:08 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3f55d744c0
21:10 colomon joined #moarvm
21:12 FROGGS joined #moarvm

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