Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-05-10

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

All times shown according to UTC.

Time Nick Message
01:30 FROGGS joined #moarvm
02:14 btyler joined #moarvm
04:08 btyler joined #moarvm
07:51 tadzik g'night
07:52 FROGGS gnight?
07:53 FROGGS don't tell me you are in Old Europe™ and still awake since yesterday :o)
07:53 nwc10 I hate all operating systems. Drink!
07:53 FROGGS nwc10: I only hate openbsd atm
07:57 nwc10 I'm only trying to get sane answers from uname
08:04 FROGGS and I only want to load a dynamic library :/
08:12 nwc10 could you tell me the output of uname -m and uname -p on OpenBSD?
08:13 FROGGS sure... hold on
08:15 FROGGS both is either amd64 or i386
08:15 FROGGS tested on openbsd 5.4 and 5.5
08:16 nwc10 just to check, both uname -m and uname -p return 'amd64' on th x86_64 machine?
08:16 FROGGS exactly
08:17 nwc10 thanks. that's consistent with FreeBSD, but not NetBSD
08:17 nwc10 on NetBSD, uname -m is amd64, uname -p is x86_64, on the machine I have access to
08:23 * FROGGS starts his NetBSD 5.1.3
08:24 FROGGS ohh, that is only i386 and both -m and -p report that
08:29 flussence joined #moarvm
08:29 _sri joined #moarvm
08:34 FROGGS nwc10: I've got something for you :o)
08:34 FROGGS uname -a # OpenBSD openbsd47.localdomain 4.7 GENERIC#558 i386
08:34 FROGGS uname -m # i386
08:34 FROGGS uname -p # Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz ("GenuineIntel" 686-class)
08:37 nwc10 thanks. I'd elected to go for -m on *BSD
08:38 nwc10 that's insane
08:38 nwc10 actually, maybe it's technically not insane
08:44 lizmat .oO( sanity is in the eye of the beholder )
08:59 FROGGS ~> uname -a # Haiku shredder 1 42211 Jun 18 2011 08:26:42 BePC Haiku
08:59 FROGGS ~> uname -m # BePC
08:59 FROGGS ~> uname -p # unknown
08:59 FROGGS though, I don't think that matters much :o)
08:59 nwc10 does libuv work on Haiku yet?
08:59 FROGGS I have no idea
08:59 nwc10 Me neither, but I'm going to guess no
09:00 FROGGS that is a good bet I think...
09:00 FROGGS I'll set up smokers once we have a place we can send reports to (cpantesters)
09:02 nwc10 smokers would be really useful
09:03 FROGGS yeah...
09:03 FROGGS I mean, colomon++ does that, but only he sees the results
09:04 FROGGS imagine you'd only smoke P5's module tests right before a (dev-)release... that'd be insane :o)
09:04 FROGGS though, normal for us :(
09:05 FROGGS I hope ANDK++ has time for me this weekend, because the indexer is the very first thing that needs to work
09:17 lizmat FROGGS: why would we need CPAN's indexer for Perl 6 modules again?
09:17 FROGGS lizmat: to have a list of dists for panda to choose from
09:17 FROGGS and to have proper release we can smoke
09:17 FROGGS releases*
09:18 lizmat so a de-factor recommendation manager ?
09:18 lizmat *de-facto
09:18 FROGGS no
09:18 FROGGS there is no recommendation yet
09:18 lizmat ok, just listing
09:19 FROGGS there can only be recommendations on like 10 Foos when we have a list of Foos
09:19 lizmat indeed
09:19 lizmat ok  :-)
09:19 FROGGS so that would be a step after we have our p6-modules.json
09:20 FROGGS or p6-dists.json or what it is called
09:20 lizmat indeed....
09:22 FROGGS and for the meantime panda would ask the user to choose the Foo from a list of auths until we have the recommendations
09:22 FROGGS and this meantime can happily last a year without anybody complaining I think
09:24 lizmat yup
09:24 lizmat FROGGS++
09:24 FROGGS but having proper releases and test results would be like quality**gazillian
09:26 FROGGS I pinged ANDK a minute ago... hopefully he can have a look at my proposal for 3 database tables and the jobs that create json blobs (for panda)
09:27 nwc10 lizmat:
09:27 nwc10 lizmat: are you able to build Rakudo on MoarVM on OS X?
09:27 lizmat yes, I *only* do MoarVM lately
09:28 nwc10 OK, odd, I get a SEGV
09:28 nwc10 #0  0x00000001015f8a44 in p6captureouters () from /Volumes/Stuff/Perl/rakudo/dynext/libperl6_ops_moar.dylib
09:28 lizmat is this about "make install" ?
09:28 nwc10 during setting compilation
09:28 nwc10 too much ohter stuff going on, so not going to try to debug that
09:28 nwc10 as
09:28 nwc10 a) I don't seem to have debugging symbols
09:29 nwc10 b) I have no good idea how to bisect MoarVM/NQP/Rakudo
09:30 * lizmat neither :(
09:36 flussence joined #moarvm
09:36 _sri joined #moarvm
09:38 tadzik aaargh :|
09:38 tadzik is there a way to turn off spesh with an arg or so?
09:38 tadzik or an env var?
09:39 tadzik oh, nevermind
09:45 FROGGS env, yeah :o)
09:46 tadzik how do you do that?
09:47 FROGGS tadzik: MVM_SPESH_DISABLE=1
09:47 tadzik thanks :)
09:55 jnthn tadzik: You're not meant to be able to notice the difference besides a performance boost. What's happening?
09:55 tadzik jnthn: you said yesterday that you found the transformation which causes the nativecall bug
09:55 tadzik so I thought if I turn it off I can continue development :)
09:55 tadzik I read "transformation" as "spesh magic"
10:01 jnthn tadzik: Oh, no...I was working on the bug in the spesh_trace branch. Sorry for confusion.
10:01 tadzik ah
10:53 jnthn aww crap
10:54 jnthn I think I may know what's going on
10:55 jnthn ah, no...
10:57 jnthn grr
11:05 flussence joined #moarvm
11:05 _sri joined #moarvm
11:40 jnthn oh hmmm
11:40 jnthn It's something to do with deopt.
11:40 jnthn Of note, deopt_all
11:46 FROGGS jnthn: I am doing this now in _is_same_label, and it seems to work :o)  tc.curFrame.curHandler = outerHandler
11:46 FROGGS right before emitting the throw
11:48 jnthn ooh
11:48 jnthn Yeah
11:48 jnthn That...uh...might just be a hack, but. :)
11:48 FROGGS jnthn: well, that is what delimit_handler does, so...
11:49 FROGGS and I can't move my stuff to delimit_handler because it needs to stay in catch
11:57 jnthn FROGGS: OK, let's go with it provided it doesn't cause any other fallout.
11:57 jnthn Meanwhile, I think I may have an idea what's going on with the deopt issue.
11:57 * jnthn spent all last night's searching not knowing it was a deopt issue :/
11:58 FROGGS yeah, I will test nqp, then build rakudo on top of that and spectest it, before I try to get labels into perl6-j
11:58 FROGGS jnthn: yeah, I've seen your messages :/
12:04 jnthn And it looks like it might be a one line addition to fix it.
12:04 jnthn This'll go down as the longest one-line patch in a while.
12:05 FROGGS *g*
12:14 dalek MoarVM/spesh_trace: 6a2a829 | jnthn++ | src/spesh/deopt.c:
12:14 dalek MoarVM/spesh_trace: Don't deopt frames that are just logging.
12:14 dalek MoarVM/spesh_trace:
12:14 dalek MoarVM/spesh_trace: They didn't make any assumptions that could be broken, and this just
12:14 dalek MoarVM/spesh_trace: prevents us logging as much as we might.
12:14 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/6a2a829c84
12:14 dalek MoarVM/spesh_trace: f57f1ea | jnthn++ | src/spesh/manipulate.c:
12:14 dalek MoarVM/spesh_trace: Don't lose deopt annotations when deleting sp_log.
12:14 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/f57f1eabcf
12:14 dalek MoarVM/spesh_trace: e0b3806 | jnthn++ | src/spesh/codegen.c:
12:14 dalek MoarVM/spesh_trace: Pre-invalidate all deopt target addresses.
12:14 dalek MoarVM/spesh_trace:
12:14 dalek MoarVM/spesh_trace: This prevents us accidentally having them match up. This can happen if
12:14 dalek MoarVM/spesh_trace: we set them when producing the logging bytecode, but then toss chunks
12:15 jnthn Much of the reason it was hard to find was that deopt basically ended up putting the interpreter at an arbitrary instruction
12:15 jnthn But a valid one, still.
12:15 vendethiel dalekd died through ?
12:16 jnthn But having it do so required an offset in the logging bytecode to align with an offset in the optimized bytecode
12:16 jnthn So the bug was actually nothing to do with the particular transformation that I narrowed it down to
12:17 jnthn It's just that making that transformation caused the two sets of bytecode to align in such a way that we hit the now-bogus deopt table entry.
12:18 jnthn It's also a fairly extreme action at a distance: the deopt was triggered about 20 frames deeper than the pblock call that got deoptimized, meaning it was a long, long time until we ended up back in it again.
12:20 jnthn Anyway, I think I'll find something to eat, and then will look at the other opts I was wanting to work on, now the bug is out of the way...
12:20 FROGGS jnthn++
12:27 dalek MoarVM/loop_labels: d6a554f | (Timo Paulssen)++ | src/spesh/facts.h:
12:27 dalek MoarVM/loop_labels: remove duplicate words from from comments
12:27 dalek MoarVM/loop_labels: review: https://github.com/MoarVM/MoarVM/commit/d6a554f2cc
12:27 dalek MoarVM/loop_labels: 26ecc5d | (Tobias Leich)++ | src/spesh/facts.h:
12:27 dalek MoarVM/loop_labels: Merge branch 'master' of github.com:MoarVM/MoarVM into loop_labels
12:27 dalek MoarVM/loop_labels: review: https://github.com/MoarVM/MoarVM/commit/26ecc5d18e
14:08 timotimo it seems like i can now build a moarvm with -O3 and now i'm trying to add -flto to that
14:09 benabik joined #moarvm
14:10 jnthn Well, building a MoarVM with -O3 ain't the issue; it's building everything else atop of it that's been problematic...
14:10 timotimo i know
14:10 timotimo i'm in the setttings compilation right now
14:10 timotimo used to blow up much earlier, iirc
14:17 jnthn ooh
14:40 retupmoca jnthn: https://github.com/MoarVM/MoarVM/pull/95 doesn't seem to break anything, and it fixes a precomp issue with File::Find::Duplicates
14:40 retupmoca (and possibly others)
14:40 retupmoca if it looks sane, I'll add the WB to jvm as well
14:47 jnthn retupmoca: That seems...odd
14:48 jnthn I mean, in theory that's a no-op...
14:55 retupmoca before I put that in, I was getting "No object at index 469" after precomp
14:57 FROGGS retupmoca: can you comment it out and try again? perhaps applying this fix had side effects...
14:59 jnthn Hm, it looks a bit like something is just shoving an object into an SC regardless of if it already lives in one.
15:00 jnthn I think making scsetobj explode if the object you're trying to set an SC on is already in one may be a better route
15:00 jnthn And then find out which bit of code is doing that.
15:00 jnthn And fix it to be more careful.
15:01 retupmoca ok
15:05 retupmoca is there an easy way to do that lookup?
15:06 retupmoca it looks like MVM_sc_set_object doesn't touch the object at all, it just stores a pointer to it in the sc
15:06 jnthn MVM_sc_get_obj_sc(tc, obj)
15:06 jnthn Yeah, actually the issue is if it adds an object that already belongs to another C
15:06 jnthn *SC
15:07 jnthn I mean, I can see now why the WB helps
15:07 jnthn But still it seems like something, somewhere, is being careless
15:07 timotimo an overwhelming amount of ok-ing spectests with -O3 -flto
15:09 jnthn Sounds promising
15:09 * jnthn wonders if it's faster
15:10 timotimo https://gist.github.com/timo/29ad10576efde56946cf - these are the results
15:10 timotimo the timing is probably not very precise, as i've been using the computer for other things, too
15:13 jnthn yeah...a p6bench run is probably more indicative.
15:13 timotimo one where i don't run other things ;)
15:14 FROGGS hmmm, that S02 and S12 is weird...
15:14 timotimo probably the is rw things that happened
15:14 FROGGS the rest is kinda expected
15:14 timotimo it's not a fresh rakudo checkout
15:14 FROGGS ahh, okay
15:31 retupmoca jnthn: ignore my PR - I think it was just some kind of corruption in my local environment
15:31 retupmoca since it seems to be OK now
15:41 dalek MoarVM/spesh_trace: bc8c6c7 | jnthn++ | src/spesh/optimize.c:
15:41 dalek MoarVM/spesh_trace: Add call opt infrastructe; optimize simple calls.
15:41 dalek MoarVM/spesh_trace:
15:41 dalek MoarVM/spesh_trace: This adds callsite and args tracking, and optimization of single
15:41 dalek MoarVM/spesh_trace: dispatch cases when we know where we're going at specialize time.
15:41 dalek MoarVM/spesh_trace: In this case, we can extract the code object from its HLL wrapper
15:41 dalek MoarVM/spesh_trace: at spesh time rather than per call, which will be a slight saving.
15:41 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/bc8c6c7b57
15:42 dalek MoarVM/spesh_trace: 5cc5349 | jnthn++ | src/spesh/optimize.c:
15:42 dalek MoarVM/spesh_trace: Add statically resolved method to facts.
15:42 dalek MoarVM/spesh_trace:
15:42 dalek MoarVM/spesh_trace: This means that its visible to the various invocation optimizations.
15:42 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/5cc53490be
16:37 flussence joined #moarvm
16:37 _sri joined #moarvm
16:41 dalek MoarVM/spesh_trace: 6766b91 | jnthn++ | src/spesh/optimize.c:
16:41 dalek MoarVM/spesh_trace: Store facts for compile-time-resolved lexicals.
16:41 dalek MoarVM/spesh_trace:
16:41 dalek MoarVM/spesh_trace: Enables other optimizations to apply.
16:41 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/6766b911ad
16:41 dalek MoarVM/spesh_trace: 0ad1bb0 | jnthn++ | src/ (5 files):
16:41 dalek MoarVM/spesh_trace: Resolve multi-dispatch at spesh time if possible.
16:41 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/0ad1bb094b
16:41 jnthn m: say 5.05 / 5.84
16:41 camelia rakudo-moar c5ac80: OUTPUT«0.864726␤»
16:44 nwc10 this is a good number?
16:45 jnthn Well, it means spesh now makes a given benchmark run in 86% of the time it takes without it.
16:49 nwc10 that would be a good thing? :-)
16:50 nwc10 OK, so if I try to malloc() and copy the bytecode, as a proof of concept for Big Endian games
16:50 nwc10 I fall foul of a check at line 226 of frame.c:
16:50 nwc10 outer->static_info->body.bytecode == static_frame_body->outer->body.bytecode
16:50 nwc10 because I've cheated, and replaced body.bytecode with my copy
16:50 jnthn Ah
16:50 jnthn Yeah, it's using bytecode as an identity check there...
16:50 zakharyas joined #moarvm
16:51 nwc10 I'm wondering if I should simply add a second pointer, one is the original, one is the possible copy
16:51 nwc10 the original is the identity check
16:51 jnthn That was what I was about to suggest.
16:51 nwc10 and if they differ, that's the signal to free the other one
16:51 jnthn +1
16:52 nwc10 OK, by the magic of git, I'm going to fix up my previous commit, which put an enum for NOOP/free/munmap in moar.h
16:52 nwc10 which clearly doesn't need to be anywhere as common now
16:52 nwc10 as it's only going to be in one place now
16:52 nwc10 not the two I had thought
16:52 nwc10 much rattling from swap
16:52 nwc10 there was this nice five minutes when it was very quiet
16:53 nwc10 and about 98% CPU was user
16:53 nwc10 but that time has passed
16:54 * jnthn wonders if simple OSR would really be so hard to implement...
16:54 nwc10 OSR?
16:54 jnthn On Stack Replacement
16:55 jnthn Basically, noticing the current frame is a hot loop and replacing the bytecode with an optimized version of itself
17:11 nwc10 thanks for the reminder. You'd told me, and I'd forgotten
17:11 nwc10 glossary time?
17:11 nwc10 also, I like ASAN. It's fast enough to use as the default dev build
17:12 nwc10 and it blows up spectacularly early for a bunch of PEBKAC errors
17:17 brrt joined #moarvm
17:27 btyler joined #moarvm
17:39 nwc10 jnthn: is the MOARVM stream 2 byte aligned? Or 1?
17:39 nwc10 In that MVM_operand_int8 suggests that it's 1
17:41 jnthn There's nothing smaller than a short in it.
17:42 jnthn Don't think MVM_operand_int8 is used anywhere; it's more intended for putting on a local
17:42 jnthn Hm, there's one single mention of int8 in oplist
17:42 jnthn On an op I'm sure we dont' use
17:42 btyler_ joined #moarvm
17:42 nwc10 const_i8?
17:42 jnthn Yeah
17:42 nwc10 unimplemented
17:43 jnthn And if we do implement it, I'm happy enough to say that it must be emitted with a padding byte
17:44 jnthn So in answer, yes it's 2-byte aligned, and yes we can keep it that way for the long term.
17:46 timotimo has somebody already volunteered to implement the "automatically use smaller integer constant instructions if available" stuff?
17:46 brrt joined #moarvm
17:46 jnthn Not yet
17:46 nwc10 timotimo: I didn't. I noticed it, but decided that I'd rather do some other stuff
17:47 jnthn Also we need a const_i64 variant that loads into a 64-bit register, but reads a 16-bit or 32-bit number to do it.
17:48 nwc10 jnthn: I looked at the interp.c code and thought "mmm, blocks inside switch blocks. Ugly, but must be legal, because of Duff's Device"
17:48 nwc10 as in, we're not doing it, but we'd avoid code duplication with that bit of local ugly
17:51 timotimo jnthn: these would be different opcodes altogether, aye?
17:57 jnthn timotimo: aye
17:58 timotimo that side of the implementation seems rather simple
17:58 nwc10 Stage mast       : 19777.336
17:58 timotimo did we decide on where the decision to put one of these instructions should be made?
17:58 nwc10 Stage mbc        : 405.653
17:58 nwc10 a setting is mine. All mine
17:59 jnthn \o/
18:00 jnthn timotimo: I think in src/mast/compiler.c
18:00 nwc10 jnthn: nothing actually calls unread_op() in validation.c currently
18:00 jnthn nwc10: yay!
18:00 nwc10 I put in abort() in it
18:00 jnthn OK :)
18:00 jnthn dinner, bbiab
18:00 flussence nwc10++ # amazing patience
18:01 nwc10 flussence: oh, well, the trick was to lie in the hammock, walk the dogs, and a bunch of other things
18:01 nwc10 including hack on something else
18:06 brrt left #moarvm
18:07 timotimo jnthn: what branch should i base my stuff off of?
18:08 timotimo (since i'll be adding opcodes)
18:11 timotimo jnthn: if i implement this, we can push the stage0 update for nqp-m a bit further and have smaller constant integers all over :)
18:13 timotimo jnthn: do we ever use 32bit integer registers, btw?
18:13 timotimo apparently only in the extend ops :P
18:27 jnthn Not yet, but we don't support int8, int16, etc lexicals yet
18:27 timotimo ah
18:28 timotimo are const_i8_64 through const_i32_64 acceptable names?
18:28 timotimo or should i swap the numbers?
18:29 jnthn keep prefix as const_i64
18:29 timotimo OK
18:29 jnthn keep prefix as const_i64_16, const_i64_32 work for me
18:30 * FROGGS .oO( const_i64_XXXII )
18:30 timotimo :D
18:30 FROGGS 64 would be MXIV?
18:31 jnthn wtf... :)
18:31 FROGGS I think it was <I V M C L ...> but not sure :P
18:32 timotimo and GET_I32(cur_op, 2) and friends should work, right?
18:32 jnthn aye
18:32 timotimo ok, and the 8 variant will += 3, the 16 will += 4 and the 32 will += 6?
18:33 jnthn Uh, we don't want an 8 variant
18:33 timotimo oh, ok
18:33 jnthn Since the bytecode stream is 16-bit aligned anyway
18:33 timotimo ah!
18:33 timotimo of course.
18:33 jnthn ooh, I see patches
18:33 timotimo we could have a "load these two 8 bit integers into the register and its next register :P
18:34 nwc10 jnthn: you got a bcc on the most recent message as it's not sent from the usual place, and I don't know if that will spook the list moderation
18:34 timotimo oooh, or an 8bit number and a shift :D
18:34 nwc10 the usual place has been down for 8 hours
18:38 timotimo jnthn: src/mast/compiler.c doesn't know anything about the const_i64 operation itself; i'm not sure if special-casing it would be a good choice
18:46 timotimo in theory it could go here: https://github.com/MoarVM/MoarVM/blob/master/src/mast/compiler.c#L566
18:48 jnthn timotimo: oh, I think it'll have to be a special case on that instruction.
18:48 timotimo oh, i ought to have looked a bit lower down there
18:48 jnthn Well, I think you're in about the right place
18:49 timotimo the constants are not ops :)
18:49 timotimo oh, wrong again
18:50 jnthn const_i64 is an op
18:52 timotimo yup
18:52 timotimo i thought i saw an if istype "local"
18:52 timotimo but it was really "label"
19:07 flussence joined #moarvm
19:07 _sri joined #moarvm
19:12 timotimo jnthn: would you rather i factor out the "write a 16 or 32 bit integer operand to the stream" and re-use that or manipulate the operation before writing it out?
19:22 jnthn timotimo: Manipulating the operation is probably evil
19:24 timotimo aye
19:27 timotimo is ((MVMint32) iv->value == iv->value) good enough?
19:32 flussence joined #moarvm
19:32 _sri joined #moarvm
19:36 timotimo the code i'm writing right now is properly terrible
19:44 timotimo Error while compiling op ifnull (source text: "nqp::ifnull($!nominal, 0)"): P6opaque: no such attribute '$!result_reg'
19:44 timotimo how did i get that error o_O
19:44 TimToady just as long as it's not terribly proper
19:45 timotimo ah
19:45 timotimo the error is there even without my modifications
19:45 timotimo so that's a good start
19:49 jnthn timotimo: That sounds like you're working on spesh_trace and didn't update your NQP to use the lexopt branch
19:49 jnthn (Yes, it's a messy arrangement. That's what branches are for. :P)
19:50 timotimo aye.
19:50 timotimo huh. i'm getting a segfault from one of my _16 instructions
19:51 timotimo (gdb) print cur_op
19:51 timotimo $1 = (MVMuint8 *) 0x7fbcc8a8c5d0 <Address 0x7fbcc8a8c5d0 out of bounds>
19:51 timotimo ?!
19:54 flussence joined #moarvm
19:54 _sri joined #moarvm
19:55 timotimo cur_op = 0x7f44459c25d0 <Address 0x7f44459c25d0 out of bounds>
19:55 timotimo bytecode_start = 0x7f44459c2418 <Address 0x7f44459c2418 out of bounds>
19:55 timotimo ????
19:56 timotimo setting spesh_disable doesn't fix it :\
19:56 jnthn Well yeah, you can't just blame spesh for your own bugs :P
19:57 timotimo yeah, apparently
19:57 jnthn You did change the increment to be correct after reading it, yes?
19:58 timotimo ... reading?
19:59 timotimo i'm confused
19:59 jnthn in interp.c
19:59 jnthn the cur_op += thingy
19:59 timotimo hahahahaha
19:59 timotimo forgot to goto next :D
20:00 timotimo yeah, that works better now :D
20:02 timotimo goes from 3.9mb to 3.8mb for the stage0 files
20:03 timotimo 3940total -> 3868total
20:04 timotimo so that's not the drastic win i was hoping for :Ä
20:04 timotimo :P
20:05 nwc10 timotimo: it will still be very useful on platforms that can't do 32 or 64 bit unaligned reads
20:05 timotimo oh, huh.
20:05 timotimo it doesn't seem like these made it into the output at all
20:06 jnthn Aye, unaligned reads cost an ARM and a leg in some places...
20:06 timotimo oh, duh
20:06 timotimo i reset the source for measuring purposes.
20:07 timotimo yup, that does look like it works.
20:08 timotimo would you accept my i64_* work into the spesh_trace branch right now, and squashing a new stage0 onto the lexopts branch of nqp?
20:09 jnthn Can I see the diff?
20:09 timotimo sure
20:10 timotimo https://gist.github.com/timo/00aac0df68b1e0afaae1
20:22 timotimo i hope you didn't fall over backwards when you saw how i did it %)
20:22 jnthn no no no
20:22 jnthn spesh ops must come last
20:22 timotimo oh
20:22 * jnthn thought he noted that at the top of oplist
20:22 timotimo in the interp.c switch or oplist.txt?
20:22 timotimo oh!
20:22 timotimo yeah, i can easily fix that, hold on.
20:23 jnthn well, both
20:23 jnthn interp suould follow oplist order
20:23 jnthn Rationale for this is that you can't write spesh ops in bytecode
20:24 nwc10 $ ./perl6-m -e 'shell("uname -a")'                     Linux gcc1-power7.osuosl.org 3.8.8-202.fc18.ppc64p7 #1 SMP Thu Apr 18 14:11:12 MST 2013 ppc64 ppc64 ppc64 GNU/Linux
20:24 jnthn So those don't need to have stable numbers
20:24 timotimo yes, of course
20:24 nwc10 gah, got nommed
20:24 timotimo i brainfarted that fact for a second there :)
20:24 nwc10 $ ./perl6-m -e 'shell("uname -a")'
20:24 nwc10 Linux gcc1-power7.osuosl.org 3.8.8-202.fc18.ppc64p7 #1 SMP Thu Apr 18 14:11:12 MST 2013 ppc64 ppc64 ppc64 GNU/Linux
20:24 jnthn omg ppc64 too \o/
20:24 jnthn nwc10++
20:24 nwc10 yes, OM${expletive}G
20:24 nwc10 it was surprisingly easy
20:24 timotimo not bad!
20:25 jnthn :)
20:25 nwc10 although the nativecall test might be trivial, or impossible without assembler knowledge
20:25 jnthn Depends what state dyncall is in on ppc I guess
20:25 nwc10 it was actually faster that the $other-expletive stuff to get uname probing was
20:25 jnthn I *thought* it was in good shape
20:25 nwc10 jnthn: it seems to want to be ppc32
20:25 nwc10 so it might just be configure
20:25 nwc10 what's wierd is that the atomic ops stuff worked
20:26 timotimo okay, the changes are in there now. i could still build an nqp with it
20:26 _sri joined #moarvm
20:26 nwc10 whereas IIRC when I was playing with AIX a couple of months back, it wasn't implemented
20:26 flussence joined #moarvm
20:26 nwc10 and the two machines have the same CPUs
20:26 timotimo whereas a rakudo build gives me Stage parse      : Internal error: invalid thread ID in GC work pass
20:27 timotimo which i believe is known
20:27 timotimo jnthn: should i update the gist for you?
20:27 nwc10 sparc is hating me:
20:27 nwc10 Updating submodules .................................... FAIL git error: fatal: Needed a single revision
20:27 nwc10 Unable to find current revision in submodule path '3rdparty/dyncall'
20:28 nwc10 aha, it's git 1.5
20:28 nwc10 maybe that's the Yak to shave
20:29 jnthn timotimo: I didn't know that one on Rakudo build..
20:30 timotimo oh?
20:30 jnthn timotimo: It's been working fine for me on spesh_trace fwiw
20:30 timotimo with SPESH_DISABLE set it works
20:30 timotimo only Stage mast       : Error while compiling op execname: No registered operation handler for 'execname'
20:30 timotimo which is not surprised
20:30 timotimo surprising
20:30 timotimo huh.
20:32 jnthn timotimo: Yes, can do an updated gist
20:33 timotimo ~on an older rakudo i can build with spesh disabled
20:34 timotimo updated
20:34 timotimo oh
20:35 timotimo now i could get through the setting even without disabling spesh
20:35 timotimo so it may even be spurious if we're very lucky
20:35 jnthn if ((MVMint16) iv->value == iv->value) {
20:35 timotimo i asked you if that sounds sane :)
20:35 jnthn I'm...not sure that's too robust...
20:36 jnthn I think it's probably better to compare it with the max/min allowable values
20:36 timotimo OK
20:39 FROGGS jnthn: is there an optimization about exception handlers going on?
20:39 jnthn No
20:39 FROGGS hmmm
20:40 FROGGS I have a weird problem and it does not make sense at all
20:40 jnthn Not in spesh, anyway
20:40 jnthn All it does is make sure it rewrites a new set of handlers at code-gen time with the right addresses for the new bytecode.
20:40 FROGGS this does print twenty times 1: perl6-m -e 'my $y; my $x; FOO: while $x++ < 10 { say($x); last if $y++ > 20; redo }'
20:40 FROGGS this does print 1 to 10: perl6-m -e 'my $y; my $x; FOO: while $x++ < 10 { say($x); last if $y++ > 20; redo FOO }'
20:41 FROGGS and in the first example it does not search for the handler for some reason
20:43 timotimo now i use INT16_MIN and INT32_MIN and _MAX from stdint.h
20:44 FROGGS eww, rakudo's optimizer does something strange
20:45 timotimo oh no!
20:45 timotimo probably my fault :(
20:46 FROGGS https://gist.github.com/FROGGS/bc7635a8a9a1087601b4
20:46 FROGGS the results depends on the phase of the moon
20:46 FROGGS I run it through valgrind
20:46 FROGGS I'll*
20:46 timotimo well. now i got a segfault
20:46 timotimo that's not much better
20:47 FROGGS ahh okay, my fault
20:49 timotimo gc work pass thingiemajig
20:50 timotimo i don't understand why that happens
21:05 jnthn m: say 4 / 4.87 # spesh helps once Rakudo's optimizer knows the %_ opt
21:05 camelia rakudo-moar aff2a6: OUTPUT«0.821355␤»
21:05 FROGGS OHH MY GOD I AM SOO STUPID!!!111
21:06 FROGGS I copy+pasted this to class Label.next/.red/.last:
21:06 FROGGS #?if !parrot
21:06 FROGGS nqp::setextype($ex, nqp::const::CONTROL_NEXT + nqp::const::CONTROL_LABELED);
21:06 FROGGS #?endif
21:06 FROGGS unmodified!
21:06 FROGGS >.<
21:07 FROGGS lost an hour due such a thingy :(
21:07 FROGGS to*
21:07 jnthn :(
21:08 timotimo our internet compiler is going to drop now.
21:08 timotimo er..
21:08 timotimo connection
21:08 FROGGS ewww
21:08 FROGGS but anyway, I am happy that I found it
21:08 dalek MoarVM/small_const_i64: 736a9f5 | (Timo Paulssen)++ | / (7 files):
21:08 dalek MoarVM/small_const_i64: write small const integers as 16 or 32 bit insts
21:08 dalek MoarVM/small_const_i64: review: https://github.com/MoarVM/MoarVM/commit/736a9f51a7
21:08 timotimo so i pushed my changes
21:09 timotimo FROGGS: i'm glad you were able to find it
21:09 FROGGS yeah
21:09 timotimo these kinds of problems usually drive me totally crazy, too
21:10 dalek MoarVM/loop_labels: 4d4841a | (Tobias Leich)++ | src/ (2 files):
21:10 dalek MoarVM/loop_labels: do not read uninitialized memory
21:10 dalek MoarVM/loop_labels: review: https://github.com/MoarVM/MoarVM/commit/4d4841ab58
21:10 colomon joined #moarvm
21:11 timotimo i'll have to teach spesh about these new const instructions, too
21:11 timotimo but that's easy
21:11 timotimo i'll do it while the 'net connection is gone
21:11 FROGGS timotimo++
21:12 dalek MoarVM/spesh_trace: abaec70 | jnthn++ | src/core/op (2 files):
21:12 dalek MoarVM/spesh_trace: Add some missing :pure markers on some spesh ops.
21:12 dalek MoarVM/spesh_trace:
21:12 dalek MoarVM/spesh_trace: Means we can optimize out some more dead instructions.
21:12 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/abaec70c9a
21:16 dalek MoarVM/small_const_i64: 25da6d1 | (Timo Paulssen)++ | src/spesh/facts.c:
21:16 dalek MoarVM/small_const_i64: introduce the const_i64_* ops to spesh.
21:16 dalek MoarVM/small_const_i64:
21:16 dalek MoarVM/small_const_i64: also, switch/case is a bit nicer to look at.
21:16 dalek MoarVM/small_const_i64: review: https://github.com/MoarVM/MoarVM/commit/25da6d1d49
21:30 ChanServ joined #moarvm
21:40 jnthn ChanServ: Nice vacation?
21:40 jnthn :)
21:40 FROGGS :o)
21:43 timotimo jnthn: would you like me to merge that branch somewhere? or wait until spesh_trace is in master?
21:46 jnthn timotimo: Well, maybe it's nice if spesh_trace can get some testing without that, on something other than Windows...
21:48 timotimo OK
21:58 TimToady who is doing that?
21:59 jnthn Whoever volunteers
21:59 jnthn I should really update lexopts in NQP to ahve stuff from master to make it easier...
22:00 jnthn And similarly get master updated with spesh_trace
22:00 * jnthn does it
22:00 jnthn eeks, conflcits
22:05 jnthn Testing merges here
22:07 jnthn uh
22:07 jnthn post merge we get busted bootstrap...
22:09 jnthn ah...
22:11 jnthn yeah, mis-merged.
22:12 dalek MoarVM/spesh_trace: 61f9cdb | (Tobias Leich)++ | / (10 files):
22:12 dalek MoarVM/spesh_trace: implement op execname, which stores the path of the runner
22:12 dalek MoarVM/spesh_trace:
22:12 dalek MoarVM/spesh_trace: We can set the path to the runner in the runner scripts itself, store that information
22:12 dalek MoarVM/spesh_trace: and retrieve that later through nqp::execname. moritz++
22:12 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/61f9cdb8b6
22:12 dalek MoarVM/spesh_trace: d6a554f | (Timo Paulssen)++ | src/spesh/facts.h:
22:12 dalek MoarVM/spesh_trace: remove duplicate words from from comments
22:12 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/d6a554f2cc
22:12 dalek MoarVM/spesh_trace: 29c5c9d | jnthn++ | / (11 files):
22:12 dalek MoarVM/spesh_trace: Merge remote-tracking branch 'origin/master' into spesh_trace
22:12 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/29c5c9d925
22:17 dalek joined #moarvm
22:18 jnthn ok, spesh_trace + lexopts + nom ready for testing by others
22:25 * retupmoca builds
22:29 retupmoca Stage parse      : make: *** [CORE.setting.moarvm] Segmentation fault
22:29 retupmoca o.O
22:29 retupmoca (linux on x86_64, gcc 4.8.1)
22:29 retupmoca jnthn: ^
22:30 jnthn ah shit
22:30 jnthn Works fine on Windows :/
22:30 jnthn Any chance you can do a debug build and get a backtrace?
22:31 retupmoca this is moar 29c5c9d925614b002ae2ce3e7c51523a0ce0b53f, nqp 7d6bcb28ce053be71de7bd643c3336eaa2ca5732, rakudo b2b6b19ac74509ff30aee7ef74a1ca142bfe5a81
22:31 retupmoca that correct?
22:31 * retupmoca starts up a debug build
22:34 jnthn yes, those match what I have
22:34 timotimo will try it soon-ish
22:38 jnthn Seems I have a working decontrv improvement patch also
22:40 timotimo neato
22:40 timotimo that will remove decontrv at spesh time if we know it's fine without?
22:40 jnthn No, just done the opt patch at the moment
22:40 jnthn Will go for the spesh one later
22:41 timotimo compiles for me
22:41 retupmoca mine is sporadic
22:44 retupmoca hah! got a core dump
22:45 retupmoca jnthn: c-level backtrace: https://gist.github.com/retupmoca/86d58d4d8d707f26b980
22:46 jnthn Hmm, which is when we mark spesh slots
22:48 retupmoca also, it refuses to die when I'm running it under gdb
22:51 jnthn zombie moar
22:52 retupmoca oh
22:52 retupmoca this might be my system again
22:53 retupmoca This is nqp version 2014.04-48-g7d6bcb2 built on MoarVM version 2014.04-97-g29c5c9d
22:53 retupmoca which is not the version I typed make install on :/
22:53 * retupmoca blows away everything
22:55 jnthn retupmoca: Please can you try with this patch: https://gist.github.com/jnthn/9ea815130e5d361c5e62
23:02 retupmoca jnthn: how do I apply that?
23:03 retupmoca git apply says it's corrupt
23:03 retupmoca oh wait, I think I killed the whitespace...
23:03 retupmoca that's better
23:03 jnthn Then, probably by using git apply without destorying the whitespace :P
23:05 retupmoca still segfaults (although I didn't rebuild nqp yet)
23:06 jnthn hm
23:06 jnthn so it's not that
23:13 retupmoca jnthn: I added a bunch of gdb print statements in https://gist.github.com/retupmoca/86d58d4d8d707f26b980
23:13 retupmoca &body->spesh_candidates[0].spesh_slots[5] looks like the bad one
23:14 jnthn What is num_spesh_slots?
23:15 retupmoca (gdb) p *(&body->spesh_candidates[0].num_spesh_slots)
23:15 retupmoca $18 = 111
23:15 jnthn That's a lot of slots... :)
23:16 jnthn If you probe body->name you can also find out which static frame it is
23:17 jnthn Or cuuid
23:17 jnthn It's a MoarVM string, so it'll need a little digging
23:17 jnthn But if I have that, then I can look at a spesh_log and figure out what kind of opt is using slot 5.
23:18 retupmoca Can I treat MVMString->body.storage as a char* ?
23:20 jnthn no, it's basically a bunch of int32s
23:20 jnthn If you can call functions you can pass the string to MVM_string_utf8_encode_C_string
23:20 jnthn And that will give you a char *
23:21 retupmoca core dump, so I can't call anything
23:23 jnthn ah, too bad
23:23 jnthn If you can view a region of memory then you can do it
23:23 jnthn Otherwise it's just picking through the int32s one at a time...
23:28 retupmoca jnthn: body->name looks like 'container_type_info' ?
23:29 jnthn Thanks.
23:29 jnthn I'm getting a bit tired now, but I can investigate that tomorrow.
23:31 jnthn Though if you did have inclination to dig further, set MVM_SPESH_LOG=spesh_log or so in your env var
23:31 retupmoca k
23:31 jnthn uh, in your env
23:31 retupmoca ooh, I'll do that
23:31 jnthn spesh_log is just a file name
23:31 jnthn YOu can search for container_type_info in that
23:31 jnthn You might look for slot 5 in there
23:32 jnthn sp_getspeshslot ops can be interesting
23:32 jnthn Though a few other ops do them too
23:32 jnthn Of note sp_findmethod or so
23:32 jnthn On the interesting one you've see a liti16(5) or so
23:33 jnthn Note, it's a lot of output :)
23:33 retupmoca 1.5 million lines, I see
23:34 jnthn Also you'll find 3 entries: one "before"/"after" pair which is when it inserts the sp_log things, which isn't so interesting probably, and then one headed "Finished specialization" which is the interesting one.
23:35 timotimo retupmoca: figure out how to use my moarvm gdb plugin :)
23:35 timotimo it says how in the top of the file
23:35 jnthn Basically what you're looking at in that file is a control flow graph
23:37 jnthn Just looking at this file can be a bit interesting from an opt perspective...
23:38 jnthn existspos r26(9), r22(13), r26(8)
23:38 jnthn p6box_i r30(1), r26(9)
23:38 jnthn set r27(7), r30(1)
23:38 jnthn if_i r26(9), BB(18)
23:38 jnthn That's from assign_pos
23:39 jnthn That boxing is not a good thing...
23:39 jnthn And explains the C-level profile showing p6box_i up in a benchmark that shouldn't really have any...
23:40 timotimo well, depends on what the r27(7) is used for afterwards
23:42 jnthn *nod*
23:42 jnthn Well, that's worth looking into at some point, anyways.
23:42 jnthn Anyway, 'night
23:42 timotimo gnite jnthn!
23:44 retupmoca jnthn, timotimo: my spesh_log for a segfaulting run is at https://drive.google.com/file/d/0B2NGpceqEjj3dHlKMmpvVXA5RW8/edit?usp=sharing
23:44 timotimo did you check out the spesh_diff.p6 script? :)
23:45 timotimo (as well as the python plugin for gdb)
23:47 retupmoca ooh, I like that gdb plugin
23:47 timotimo yw :)
23:48 timotimo make: *** [lib/Test.moarvm] Segmentation fault (core dumped)
23:48 timotimo not as happy öbout this :(
23:48 timotimo gc_mark of MVMStaticFrame i think
23:49 timotimo but i have --optimize=3, which may be a source of instability
23:51 timotimo Internal error: invalid thread ID in GC work pass - getting that now
23:52 retupmoca yeah, that's what I'm getting (sporadically)
23:52 retupmoca while compiling the setting with spesh_trace/lexopts/nom
23:53 timotimo yeah
23:56 timotimo time to valgrind? %)
23:56 timotimo now i got a compilation through
23:57 timotimo but the perl6-m can't run my spesh_diff script
23:58 timotimo i get either a segfault or the illegal thread id thing

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