Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-18

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

All times shown according to UTC.

Time Nick Message
01:24 FROGGS_ joined #moarvm
02:06 [Coke] joined #moarvm
02:10 dalek joined #moarvm
02:10 sergot joined #moarvm
02:10 synopsebot joined #moarvm
02:21 sergot joined #moarvm
02:39 dalek joined #moarvm
02:39 synopsebot joined #moarvm
02:47 dalek joined #moarvm
03:07 d4l3k_ joined #moarvm
03:09 sergot joined #moarvm
03:14 sergot joined #moarvm
03:17 [Coke]_ joined #moarvm
03:17 synopsebot joined #moarvm
03:23 synopsebot joined #moarvm
03:30 dalek joined #moarvm
03:54 synopsebot joined #moarvm
04:01 dalek joined #moarvm
04:07 d4l3k_ joined #moarvm
04:27 dalek joined #moarvm
04:46 dalek joined #moarvm
04:51 dalek joined #moarvm
04:58 sergot joined #moarvm
05:08 dalek joined #moarvm
05:46 lizmat_ joined #moarvm
05:54 lizmat joined #moarvm
05:58 woolfy joined #moarvm
06:02 lizmat joined #moarvm
06:48 sergot o/
07:09 zakharyas joined #moarvm
08:43 ren1us should moar be regularly running at ~99% CPU?
10:14 nwc10 I guess "that depends" - what are you doing with it?
10:28 brrt joined #moarvm
10:38 jnthn Was gonna say...depends how many cores you have and what workload you put on it.
10:41 nwc10 jnthn: fresh SAN barf http://paste.scsys.co.uk/408725
10:41 nwc10 master/master/nom
10:42 nwc10 need to go for lunch
10:42 nwc10 can't do more
10:42 brrt \o
10:42 jnthn timotimo: ^^ may relate to your recent spesh work; probably a missing NULL check
10:42 jnthn o/ brrt
10:43 brrt how's things :-)
10:44 jnthn Not bad. Got a friend visiting for the weekend, so will be playing tour guide a bit :)
10:44 brrt nice
10:44 brrt (why off all frames that had to fail, did it have to be one of 49 basic blocks?)
10:44 brrt 24 basic blocks
10:45 * jnthn has had to debug stuff in a frame with 200 before
10:45 jnthn It's..."fun"...
10:45 brrt 'challenging'
10:51 brrt anyway, i see two things that i've been finding difficult to test
10:51 brrt decont on one hand, getlex with viv on the other
11:06 jnthn Both will only show up a lot in Rakudo
11:06 jnthn You may want to try disabling JIT for the build, getting a Rakudo, then running stuff with it
11:08 brrt joined #moarvm
11:40 jnthn afk for a while
11:40 FROGGS have fun
11:45 nwc10 timotimo: ^^ 1869baf6cd92f1149ed5838ecfa3e566a09ab66c is the first bad commit
11:46 timotimo thank you, i'll have a look in a few
11:51 btyler joined #moarvm
11:54 brrt joined #moarvm
11:59 timotimo can the boolification spec ever be null?
12:09 jnap joined #moarvm
12:14 brrt yes
12:14 brrt afaik
12:15 timotimo oh, that'd explain the problem :)
12:15 timotimo how do we boolify something that doesn't have a boolification spec set?
12:17 timotimo just use the default, which is check if the object is concrete?
12:17 brrt let me see
12:17 brrt see MVM_coerce_istrue, src/core/coerce.c, l32
12:18 brrt basically, no boolifciation spec means MVM_BOOL_MODE_NOT_TYPE_OBJECT, which is indeed IS_CONCRETE
12:18 timotimo ah, right
12:18 brrt so no boolification spec and known type can be converted to sp_guardconc and set
12:18 brrt (it would seem)
12:19 timotimo well, i turn it into an isconcrete and defer to the isconcrete optimization
12:19 timotimo i suppose the isconcrete optimization does the guardconc piece?
12:27 dalek MoarVM: 9a0099d | (Timo Paulssen)++ | src/spesh/optimize.c:
12:27 dalek MoarVM: boolification spec may be null, which means "not type object"
12:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9a0099dc85
12:30 timotimo isconcrete may want to flag any given guardconc as "used" when it turns that into a const_i
12:30 brrt well then, you can swap an const_i and an if_i into a goto :-)
12:31 timotimo well, the isconcrete opt already turns an isconcrete and a "known to be concrete" into a const, and the if would remove the usages of that const and turn into a goto (or rather: should)
12:49 btyler_ joined #moarvm
12:50 nwc10 timotimo: pass
12:50 timotimo thank you!
12:50 nwc10 thank you for the quick fix
12:51 timotimo you made it easy :)
12:53 brrt getlex with autoviv isn't hit on rakudo build
12:55 brrt ... hit_wb is hit
12:55 brrt yes
12:58 brrt (it is in fact hit in a relevant code path, it seems)
12:59 timotimo is that the code you spiked with a little abort()?
13:00 brrt other code that i spiked
13:01 timotimo ah
13:04 brrt the good thing is that it blows up in approximately the right frame
13:04 timotimo AFK for a bit ...
13:05 brrt see you :-0
13:05 brrt :-)
13:17 brrt if i have an MVMObject in the debugger, how can i figure out what type it is?
13:17 brrt oh, it's VMArray
13:25 woolfy joined #moarvm
13:26 lizmat joined #moarvm
13:30 brrt it seems a GC bug
13:30 jnap joined #moarvm
13:30 brrt (that's not quite right. it seems a bug in jit related to gc)
13:33 * brrt afk
13:50 timotimo that sounds like a nasty kind of problem
14:07 woolfy1 joined #moarvm
14:35 jnthn Need to be rather careful in the JIT not to have something sat in a register then do a call that may allocate.
14:35 nwc10 is it possible to add optional assertion code that spots if that is happening?
14:56 jnap joined #moarvm
15:05 jnthn nwc10: Hmm...could try emitting a sanity check of the current frame between instructions...
15:05 jnthn Not srue that's enough though
15:05 jnthn Best bet is the usual "make the nursery tiny" trick
15:10 FROGGS jnthn: I know you have no time, but this is on topic: https://github.com/MoarVM/MoarVM/issues/114
15:10 FROGGS do you have any pointers?
15:11 jnthn *foo, **bar
15:12 jnthn On "Is it related to spesh/inlining?" - set MVM_SPESH_DISABLE=1 for no spesh
15:12 jnthn And MVM_SPESH_INLINE_DISABLE=1 just for disabling inlining.
15:17 FROGGS &baz
15:23 FROGGS if I disable one of them then it infiniloops, probably again in libuv waiting for data
15:27 jnthn Which one?
15:27 FROGGS that example here: https://gist.github.com/FROGGS/be23c4bcdca366a0ddab
15:29 jnthn no, which flag...
15:29 jnthn Anyway, heading out &
15:30 FROGGS both MVM_SPESH_DISABLE=1 and MVM_SPESH_INLINE_DISABLE=1
15:30 jnthn The first subsumes the second
15:31 FROGGS yes, sure
15:31 jnthn OK, so could be inlining related
16:04 cognominal joined #moarvm
16:08 cognominal joined #moarvm
16:55 vendethiel joined #moarvm
18:26 cognominal joined #moarvm
18:47 lizmat joined #moarvm
18:48 woolfy joined #moarvm
19:07 brrt joined #moarvm
19:07 brrt left #moarvm
19:07 brrt joined #moarvm
19:08 brrt \o
19:09 brrt ok, i have no good evidence of jit-relatedness, but i have this
19:09 brrt ehm, gc-related-jit-bugs, i mean
19:09 brrt and fwiw, our main interface with the GC is hitting write barriers
19:10 brrt which i suspected of not being tested very well, but nevertheless
19:11 brrt hmm
19:11 brrt maybe that's wrong
19:11 woolfy joined #moarvm
19:17 woolfy joined #moarvm
19:26 brrt can i influence when GC is run?
19:30 [Coke] ISTR jnthn & nwc10 have a way to make it run more frequently. I don't know if you can kick off a run from a particular line of code.
19:31 brrt hmm i might need that way
19:33 FROGGS brrt: you can adjust these values:
19:33 FROGGS /home/froggs/dev/MoarVM/src/gc/collect.h:4:#define MVM_NURSERY_SIZE 4194304
19:33 FROGGS /home/froggs/dev/MoarVM/src/gc/collect.h:9:#define MVM_GC_GEN2_RATIO 25
19:33 brrt ah, ok
19:34 brrt awesome
19:34 brrt that should help
19:34 FROGGS make the first smaller (like 5000 or so)
19:34 FROGGS but the gc is only triggered when an allocation happens, so you cannot trigger it at another moment
19:35 brrt that's ok, i already know that the gc is triggered just twice before the 'funky' stuff happens
19:35 brrt i.e. a REPR that can't be invoked because it is (probably) VMNull
19:37 brrt hmmmm
19:38 brrt ok, very interesting, i get troubles invoking but the invoked code is VMNull
19:38 brrt it is exactly the same object
19:45 brrt shame i can't get at the actual object since it's been optimized out
19:48 brrt it's a P6Opaque
19:49 brrt but P6Opaque should be able to look stuff up, shouldn't it?
19:50 FROGGS 'look stuff up'?
19:54 brrt support atkey_o
19:55 btyler joined #moarvm
19:55 carlin joined #moarvm
20:06 * brrt off
20:06 brrt left #moarvm
22:24 itz__ what version of nqp should I use with moar-jit?
22:24 FROGGS latest I guess
22:25 itz__ master seems to depend on a newer moar version
22:25 FROGGS yes, moar master might need to be merged into moar-jit
22:28 FROGGS so, take a look when moar master was merged into moar-jit the last time, and pick an nqp from the same time
22:31 itz__ I'll try that
23:35 timotimo merging moar-jit into master should be mostly clean, though
23:40 carlin is jit being merged before the next release?

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