Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-06

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

All times shown according to UTC.

Time Nick Message
00:10 timotimo (well, the first 2 gc runs actually left 17% in there and the third one left 10% in there, but that was probably due to stuff being compiled and stuff)
00:12 ventica joined #moarvm
00:50 japhb I think you're basically confirming that our allocation and lifetime patterns match the generational hypothesis.  :-)
01:02 timotimo yup.
01:13 dalek MoarVM: f4536ef | TimToady++ | src/ (3 files):
01:13 dalek MoarVM: instrument dynvar lookup for logging
01:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f4536ef3c0
01:16 TimToady initial analysis of dynvars: https://gist.github.com/anonymous/ea75f8c3c12022fd9c39
01:16 TimToady first section is with no caching, second section is jnthn's current code
01:17 TimToady a large part of the problem currently is collisions with other names, since we populate the cache too much
01:18 TimToady so for instance, while $*W has an average frame depth of 44 without the cache, the cache only cuts that down to 29 on average
01:18 TimToady so yeah, I think we can do much better
01:20 dalek MoarVM: 4151c4f | TimToady++ | tools/dynvarcost:
01:20 dalek MoarVM: add dynvarcost script
01:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4151c4f4ad
01:20 japhb * Only Sept 16-18 have scheduled activities, 15th and 19th are dedicated for travel
01:20 japhb * Only non-stop flights are on Aer Lingus, SFO ↔︎ DUB
01:20 japhb * Not all days are available
01:20 japhb * Best I found was leave SFO Sunday the 14th, return Friday the 19th, $1412 round trip
01:20 japhb D'oh
01:21 japhb Damn paste buffer
01:21 TimToady irssi can stop that...
01:22 timotimo as can weechat
01:22 TimToady dinner &
01:23 timotimo japhb: i'm yearning for some feature that'll show me what checkouts have commits from what date, or at least sort by commit date or something
01:23 timotimo (for perl6-bench)
01:24 japhb History view already sorts by commit date, but I'm guessing you mean for compare view?
01:25 timotimo more like for "list" view
01:25 timotimo right now i'm unsure what commit to include between the current nqp head and 2014.07
01:26 japhb Isn't there a `bench list-tags` with dates?  I thought I did that.
01:26 timotimo oh?
01:26 timotimo yikes!
01:26 timotimo this command is *very* unhappy :)
01:27 japhb Oh dear.  I'll take a look on the bus.
01:27 timotimo fatal: ambiguous argument 'MadMongers^{commit}': unknown revision or path not in the working tree.
01:27 timotimo Use '--' to separate paths from revisions, like this:
01:27 timotimo 'git <command> [<revision>...] -- [<file>...]'
01:27 timotimo 1970-01-01   MadMongers
01:27 japhb japhb.move-to($bus-stop);
01:27 timotimo it outputs this for every single commit of everything forever
01:28 timotimo i guess i want list-checkouts to also show the date of the revision
01:35 japhb timotimo: What version of git do you have?
01:36 timotimo git version 1.9.3
01:36 timotimo this is what i ended up doing btw: for path in *; cd $path; git lg | head -1; cd ..; end
01:36 timotimo https://gist.github.com/timo/b733145ba7e73ef0d2b8
01:38 FROGGS__ joined #moarvm
01:38 timotimo http://t.h8.lv/p6bench/2014-08-06-with_new_match.html - jnthn, this compares a revision before and after the new implementation for nqp Match object creation and the latest release
01:38 timotimo only the json benchmarks are very interesting, i'd thinsk
01:40 japhb timotimo: What is 'git lg'?  I'm assuming it's an alias, but defined as what?
01:40 timotimo `git lg' is aliased to `log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %Cblue<%an>%Creset' --abbrev-commit --date=relative'
01:41 timotimo i wish i remembered where i picked up this beauty
01:45 japhb Oh now that is nice.
01:45 timotimo aye
01:45 japhb And here's a very simple bash helper I like: gpr () { cur=`git rev-parse HEAD`; git pull; git log -p --reverse $cur...; }
01:45 japhb gpr here standing for 'Git Pull and Review'
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:47 timotimo in case you don't get mails delivered to your bus, i opened a few issues on perl6-bench to track my feature requests
01:47 timotimo o/
02:03 ventica joined #moarvm
02:03 japhb timotimo: Hmm, my git is a 2.0; perhaps ^{commit} only came in the 2.0 series?
02:04 japhb If so, I'd like to find a backwards-compatible variant.
03:11 cognome joined #moarvm
03:35 egrep joined #moarvm
03:38 * egrep wonders if this is an error given by moarvm... http://sprunge.us/OOdK
03:54 egrep I actually have a lot more output, though, if it helps: https://gist.github.com/egrepnix/ecf20c44365e26afbf2e and https://gist.github.com/egrepnix/a90a9a29040f2c8bd5a9
05:57 ventica joined #moarvm
06:23 sergot o/
06:25 brrt joined #moarvm
06:40 ventica joined #moarvm
07:22 brrt \o
07:27 brrt ok, i've inspectedthe use of MMV_args_get_pos_*
07:27 brrt and there are two things people want from that function
07:28 brrt functions
07:28 brrt a): the value b): the existence
07:29 brrt mostly the value, though
07:32 btyler joined #moarvm
07:43 cognome joined #moarvm
07:53 dalek MoarVM: 37d4ac6 | TimToady++ | src/core/frame.c:
07:53 dalek MoarVM: use better dynvar cache
07:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/37d4ac6e6c
07:53 TimToady that saves nearly another second
07:54 brrt \o/
07:59 TimToady latest dynvar stats at: https://gist.github.com/anonymous/8db7bdfb5f3ac4c79bd3
07:59 btyler joined #moarvm
08:00 TimToady gets the average search down from 11 frames to 5 frames (no cache was 17 frames average)
08:03 nwc10 brrt: ASAN gets SEGV on setting build
08:03 synopsebot joined #moarvm
08:03 nwc10 #0 0x7f6d1a6bf2da in MVM_coerce_istrue src/core/coerce.c:43
08:03 brrt ASAN knows why?
08:03 brrt hmmm
08:03 nwc10 ==20917==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x7f6d1a6bf2db sp 0x7fffe83f9650 bp 0x7fffe83f96b0 T0)
08:03 nwc10 that would look like a NULL pointer deference
08:03 brrt very much
08:03 brrt question
08:04 TimToady could be my fault
08:04 brrt why's that a NULL pointer
08:04 brrt unlikely TimToady, unless you work on moar-jit :-)
08:04 nwc10 TimToady: I'm not sure because ... what he said
08:05 dalek MoarVM: 4ed81a1 | TimToady++ | src/core/frame.c:
08:05 dalek MoarVM: make sure 'from' isn't null
08:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4ed81a1d76
08:05 TimToady okay, well, just fixed my potential problem anyway
08:13 daxim_ joined #moarvm
08:22 dalek MoarVM: a86dd6a | TimToady++ | src/core/frame.c:
08:22 dalek MoarVM: be slightly more desperate on high icost
08:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a86dd6a4e9
08:30 TimToady zzz &
08:31 jnthn TimToady++
08:37 brrt sleep well TimToady
08:37 brrt ++ indeed
08:38 brrt bbiab
08:50 dalek MoarVM: 24fab9a | jnthn++ | src/core/frame.c:
08:50 dalek MoarVM: Tabs -> spaces, for consistency.
08:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/24fab9ae5a
08:50 dalek MoarVM: 3ddf3ce | jnthn++ | src/core/frame.c:
08:50 dalek MoarVM: Re-ordering to fix MSVC build.
08:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3ddf3ce655
08:52 ggoebel1111110 joined #moarvm
08:53 btyler joined #moarvm
08:54 sergot joined #moarvm
08:54 ashleydev joined #moarvm
08:55 lue joined #moarvm
09:00 * jnthn gets his first Rakudo build in under 65s, and first NQP build in under 35s, with the TimToady++ patch
09:09 brrt joined #moarvm
09:10 brrt back
09:12 jnthn morrning, brrt
09:12 brrt morning jnthn :-)
09:12 jnthn So, what's the latest explosion status? :)
09:13 brrt still exploding
09:13 brrt depends on decont, findmeth, box_s, elemt, getattr_i, , bind_pos_i
09:13 brrt still no idea why :-(
09:13 brrt i'm also at some point of frustration with regards to the args refactor thingy
09:14 jnthn args refactor?
09:14 brrt i.e. returning structs as MVM_args_get_(pos|named)_(int|str|num|obj) is not really well specified, and rather depends on the size of the struct, the compiler, and the phase of the moon
09:15 brrt sometimes they're returned using a passed-pointer to pre-allocated stack space
09:15 brrt sometimes they're returned in two registers
09:15 brrt ABI specs don't really tell which
09:15 brrt so, i really need only two things: the value of the arg, and the existence
09:16 jnthn ah
09:16 jnthn Might be better switching to two out parameters...
09:16 brrt hmm
09:17 brrt that'd be ok, i guess
09:19 jnthn Seems the JIT gets a decent bit further into CORE.setting now...
09:19 * jnthn is waiting for it to explode
09:19 brrt really?
09:19 brrt :-o
09:19 * brrt doesn't believe it
09:19 jnthn uh. It failed to explode here.
09:20 jnthn Like, it completed a CORE.setting build
09:20 brrt ok, what
09:20 brrt do you have findmeth commented
09:21 jnthn oh, I'm just at HEAD on moar-jit
09:21 jnthn I thought we uncommented it after the last fix?
09:22 brrt no, haven't
09:22 brrt sorry about that
09:22 jnthn findmeth and findmeth_s don't seem commented in jraph.c
09:22 jnthn *graph
09:22 jnthn And I've no local diffs
09:23 jnthn Oh, but sp_findmeth is commented still
09:23 nwc10 Stage parse      : 189.589
09:23 nwc10 that's with ASAN
09:23 nwc10 I've not seen it that low before
09:23 jnthn Setting limbo!
09:24 * masak .oO( how lo' can you go )
09:24 jnthn Exactly :P
09:26 brrt :-)
09:26 brrt bbiab
09:26 jnthn brrt: Evening uncommetning sp_findmeth in graph.c doesn't get me any errors
09:26 nwc10 that may well mean now that MoarVM built with debug + ASAN is as fast as optimised parrot
09:32 jnthn Now building with moar-jit and a 32kb nursery to try and hit a GC issue
09:32 jnthn Failed so far :(
09:42 jnthn It's in stage mast and failed to fail. Hmm.
09:45 jnthn Yup, completed.
09:58 brrt joined #moarvm
09:59 brrt :-o jnthn your computer must be broken
09:59 brrt or, you don't have JIT enabled?
10:00 jnthn I'm fairly sure I did...
10:00 jnthn I checked MVM_JIT_DISABLE was cleared in my env too
10:00 brrt i'm building from clean scratch now
10:00 brrt ok
10:00 brrt MVM_JIT_LOG gives you a real log file even?
10:01 jnthn I didn't try that
10:01 jnthn And I'm working back in another branch now...
10:01 brrt well, i'm retrying anyway
10:01 brrt :-)
10:01 FROGGS[mobile] joined #moarvm
10:03 brrt still blows up for me
10:04 jnthn You agree HEAD has findmeth and findmeth_s uncommented, though?
10:04 jnthn So it's just sp_findmeth that is commented?
10:05 brrt i agree
10:05 jnthn OK
10:05 jnthn And it's sp_findmeth that breaks things nowadays?
10:05 brrt no
10:05 brrt it's still breaks with only findmeth and findmeth_s for me :-(
10:10 brrt but, maybe it breaks differently?
10:10 nwc10 m: say  5.7776e+01/5.8165e+01; say  5.7776e+01/6.597e+01
10:10 camelia rakudo-moar 3f3abe: OUTPUT«0.993312129287372␤0.875792026678793␤»
10:10 nwc10 so a bit faster still since the last time that I measured it, and quite a lot faster than the first time I remembered to measure it
10:11 nwc10 (and also ASAN is happy)
10:12 brrt exact same crash as yesterday
10:12 brrt in the decont of some value
10:15 brrt $*LEFTSIGIL, how is that looked up?
10:15 jnthn getlexdyn
10:15 jnthn or getdynlex
10:15 jnthn can never remember which way around it goes :)
10:16 brrt hmm
10:16 brrt getdynlex isn't quite implemented
10:16 brrt also
10:16 brrt MVM_SPESH_DISABLE_INLINE=1 .... fixes my problems
10:16 brrt fuuuuuu
10:19 jnthn That may be because without inlining you don't JIT certain frames?
10:20 jnthn Also it's MVM_SPESH_INLINE_DISABLE ?
10:20 jimmyz_ joined #moarvm
10:20 jnthn Also it's MVM_SPESH_OSR_DISABLE ?
10:20 jnthn opos
10:20 jnthn d/Also it's/Did you try/
10:20 jimmyz_ Stage parse      :  33.332, before ~34.3s,                   Stage mast       :  10.960, before ~12.3s
10:21 jimmyz_ since yesterday
10:21 brrt OSR_DISABLE makes no difference
10:21 brrt very nice
10:21 brrt and yeah, i did INLINE_DISABLE
10:22 brrt possible, but weird, and unexpected; inlining would make frames bigger, thus less likely to be compiled
10:25 jnthn True
11:13 brrt it's very likely one of those Very Big Frames
11:35 brrt but, i've some good news as well i think
11:36 brrt there are only five of these
11:36 brrt so what i can do is pinpoint-disable them by inserting an unjittable op (callercode or something weird like that)
11:36 brrt and... see what that does
11:38 jnthn Sounds good
11:46 brrt ok, disabling MARKER in nqp/src/HLL/Grammar.nqp has sufficient effect
11:46 brrt i'm wondering if my isnull check is correct
11:52 jnthn That wouldn't easily explain junk...
11:52 brrt no
11:54 brrt and... disabling _ws /also/ makes it work
11:59 brrt wow, disabling any of them makes it work
11:59 brrt :-(
12:12 brrt oh, my bad
12:18 cognome joined #moarvm
12:36 jnthn grr, I musta done something wrong when I built this morning
12:36 * jnthn gets NQP fine but a JIT setting build crash now too
12:43 jnap joined #moarvm
12:47 jnthn wtf...if I turn on MVM_JIT_LOG it fails to crash?!
13:06 brrt joined #moarvm
13:07 brrt what
13:09 jnthn yes, my thought exactly
13:09 brrt :-(
13:10 jnthn If I try to dereference the thing in getdynlex it does crash there
13:11 jnthn is bindlexdyn JITted?
13:14 jnthn Seems not
13:21 jnthn brrt: Update:
13:22 jnthn If it is $*LEFTSIGIL then we can look at what binds it that we could JIT
13:22 brrt bindlexdyn is not JITted
13:22 jnthn And there's only one place that accesses it directly as a lexical
13:22 jnthn Right, I found that
13:22 brrt and that is?
13:22 jnthn method EXPR in src/Perl6/Grammar.pm
13:22 jnthn We never JIT that
13:23 jnthn However, it gets inlined.
13:23 brrt yes
13:23 brrt in modifier_expr
13:23 jnthn And arglist
13:23 brrt which is the /single/ frame that i can conclusively show to break
13:24 brrt arglist i cannot
13:26 woolfy left #moarvm
13:30 brrt https://gist.github.com/bdw/3bd68be793514c2f7ddb is the breaking frame
13:30 jnthn Concur it seems to be modifier_expr
13:30 jnthn Oh...darn.
13:31 jnthn How do I check if we're in JITted code in an MVMFrame?
13:31 brrt if you disable it in src/Perl6/Grammar.nqp:1578 by adding an effectless line to nqp::callercode(), and it unbreaks
13:31 brrt :-)
13:31 jnthn Or, were before we left it?
13:31 jnthn oh, I guess spesh_cand and jitcode are set...
13:31 brrt basically, if we've been invoked from a JITted frame, somewhere along the caller chaing, spesh_cand and jitcode should be said
13:32 brrt i've not had great effect with that, but it's possible
13:32 brrt s/said/set/
13:33 brrt if we've returned a value from the jitcode, you're out of luck
13:33 jnthn ->return_address is not valid when we're called from jitted code?
13:35 brrt it should be valid, yes
13:35 brrt but it should always refer to the MAGIC_BYTECODE variable
13:38 jnthn Certainly can reproduce modifer_expr issue
13:39 brrt \o/
13:39 brrt that's something
13:40 brrt the only good bugs are reproducable and isolated :-)
13:40 * brrt bbiab :-)
13:43 jnthn The code I think is guilty is in MVM_frame_find_contextual_by_name
13:43 jnthn Of note, the inlines searching bit
14:19 dalek MoarVM/moar-jit: dded577 | jnthn++ | src/jit/emit_win32_x64.c:
14:19 dalek MoarVM/moar-jit: Updated win32 JIT emitter.
14:19 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/dded577464
14:19 dalek MoarVM/moar-jit: 02e2e41 | jnthn++ | src/core/frame.c:
14:19 dalek MoarVM/moar-jit: NULL the return_address in new frames.
14:19 dalek MoarVM/moar-jit:
14:19 dalek MoarVM/moar-jit: Otherwise, we might invalidly end up considering us inside of some
14:19 dalek MoarVM/moar-jit: kind of inline because we see a return address from a prior use of
14:19 dalek MoarVM/moar-jit: the frame.
14:19 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/02e2e41311
14:19 dalek MoarVM/moar-jit: 5595f46 | jnthn++ | src/core/frame.c:
14:19 dalek MoarVM/moar-jit: Disable dynlex-in-inline caching for now.
14:19 dalek MoarVM/moar-jit:
14:19 dalek MoarVM/moar-jit: See comment in code for why; exposes something that needs changes for
14:19 dalek MoarVM/moar-jit: JIT. (The same issue exists for deopt_all, and the same solution can
14:19 dalek MoarVM/moar-jit: cover both of these: building JITted extent lists of machine code
14:19 dalek MoarVM/moar-jit: addresses for the inlines. Very similar to what's needed for the
14:19 dalek MoarVM/moar-jit: exception handler regions too.)
14:19 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/5595f4626f
14:20 jnthn brrt: No SEGV, no cry...
14:20 timotimo how far do we get now? sanity tests and spectests?
14:20 jnthn Sanity tests pass
14:21 * jnthn kicks off a spectest run
14:21 timotimo nice! :)
14:21 jnthn Into S03 with no fails so far
14:23 timotimo without latest master merged in, we ought to expect a segfault in the threads.t thingie
14:27 jnthn spectest looks pretty good
14:27 jnthn Bunch of thread fails that are likely due to the thing you jsut mentioned
14:27 timotimo that sounds very good
14:29 jnthn aye
14:29 timotimo i'm glad
14:29 timotimo does that mean we have all the ops uncommented now?
14:30 jnthn I didn't uncomment sp_findmeth
14:30 jnthn But it likely can be.
14:47 brrt joined #moarvm
14:51 ventica joined #moarvm
14:53 ventica2 joined #moarvm
14:55 brrt :-o jnthn++ very much
14:55 * brrt is now testing on his own system
14:58 brrt omg it works!
14:59 brrt ok, so the main thing to do, it seems, is to compute the 'machine code borders' of the inline?
15:00 brrt and i suppose the deopt_point_inline annotation determines where that border is?
15:00 jnthn Yes
15:00 jnthn It's basically the same problem as for exception hander regions
15:01 jnthn Those too being marked out by annotations
15:01 brrt very well
15:02 brrt i'll argue that exception handlers are a wee bit more complex
15:02 brrt because you also have a 'exception handler goto point'
15:02 brrt and.. i suppose that's just the point you jump to after you've 'caught' a handler between two borders?
15:03 jnthn Yes, you're right
15:03 brrt ok.. so how is a single handler constructed?
15:03 brrt sp_findmeth basically passes with colours
15:04 timotimo our bytecode has colors?
15:04 jnthn Well, handlers are kinda interesting
15:05 brrt do tell :-)
15:05 jnthn The key is .action
15:05 jnthn Some handlers simply one you to goto a certain position. Those are the easy ones.
15:05 jnthn The other case is that they want to invoke a block
15:06 jnthn And the block then does the handling
15:06 jnthn The block runs on the stack top before any kind of unwinding.
15:06 brrt ok
15:06 jnthn But that's basically invokey behavior
15:07 jnthn Just need to be aware that there'll be an unwind afterwards unless it does a resume.
15:07 timotimo i wonder what kind of introspecty things we could offer to users of MVM-based languages
15:07 timotimo like, can we offer a function that'd make mvm dump the bytecode of a given callable, for exampae?
15:08 jnthn So I think you don't need to do too much special for the invokey handlers.
15:08 timotimo from within a repl session, for example
15:08 jnthn Though the unwind after them is more interesting
15:08 jnthn So in that case goto is still interesting
15:08 jnthn But "afterwards"
15:10 brrt hmm
15:14 brrt ok, i'll read though the source and determine a course of action
15:14 brrt much jnthn++ by the way for resolving the bug :-)
15:17 jnthn np :)
15:17 jnthn BTW, given --enable-jit is needed to actually enable a build with JIT, and that things do basically work now, we may want to consider the merge to master.
15:18 timotimo i would like that
15:18 timotimo it would make running stuff with the perl6-bench tools easier
15:18 jnthn It's nice to have it done ahead of the soft pencils down date, I think. :)
15:18 brrt yes, i agree
15:19 timotimo aye, they recommend to do things like documentation between soft and hard pencils down
15:19 brrt we have something, if not everything, now
15:19 brrt bugfixes are allowed, too :-)
15:19 timotimo right
15:19 timotimo you can even do more stuff, but it won't be considered for the gsoc, right?
15:20 brrt hmmm.... that depends on who judges, i think
15:20 brrt and i have no idea of that
15:21 brrt who judges the code or on what criteria
15:22 brrt i'm off preparing dinner
15:22 brrt (i seem to live two hours earlier than the rest of you, even though we're in the same time zone. weird)
15:23 timotimo heh. :)
15:23 brrt left #moarvm
15:26 nwc10 JIT still gets to the end of spectest with ASAN
15:26 jnthn nwc10: You are configuring the build with --enable-jit ?
15:26 nwc10 t/spec/S32-str/encode.rakudo.moar still fails, but that's a #perl6
15:26 jnthn The encode.rakudo.moar is a Moar regression actually :(
15:26 nwc10 yes. More importantly, I'm then using that moarvm, and not a JIT-free one :-)
15:27 jnthn OK :)
15:27 nwc10 This is MoarVM version 2014.07-301-g5595f46
15:27 timotimo is that the "iteration past end of grapheme iterator" explosion?
15:27 jnthn No
15:27 jnthn It's an icky fallout of the lazy deserialization stuff
15:28 timotimo OK
15:28 jnthn It has a subtle reliance on deserializing everything in the order it showed up in the SC.
15:28 jnthn Which we no longer do.
15:29 timotimo oh, that's not good
16:18 timotimo who knew i never knew how to mvm :)
16:18 timotimo i have to root root!
16:19 timotimo tbh, i never grokked how the parameters to MVM_ASSIGN_REF work ...
16:25 timotimo how come i see no MVMROOT usages in other initialize methods?
16:25 jnthn They don't allocate?
16:25 jnthn Except KnowHOWREPR maybe
16:25 timotimo knowhowrepr pushes the root temporarily
16:25 timotimo so i guess that's all right
16:25 jnthn Yeah
16:25 jnthn MVMROOT is sugar for that
16:25 jnthn It came later
16:26 timotimo righto
16:27 timotimo jnthn: do we already do something in spesh for the action methods when parsing stuff?
16:27 timotimo since the action class is unlikely to be switched out in the middle?
16:31 dalek MoarVM: 7cb553a | (Timo Paulssen)++ | src/6model/reprs/MVMCompUnit.c:
16:31 dalek MoarVM: need to root root and assign ref in MVMCompUnit::initialize
16:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7cb553a668
16:38 jnthn timotimo: No, 'cus the action methods aren't, sadly, called directly from the rules
16:39 FROGGS[mobile] joined #moarvm
16:40 itz joined #moarvm
17:10 dalek MoarVM: 5fc5a59 | jnthn++ | / (8 files):
17:10 dalek MoarVM: Stub async process control ops.
17:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5fc5a591fa
17:36 dalek MoarVM/moar-jit: 0e369b3 | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
17:36 dalek MoarVM/moar-jit: Simplified some ops implementations
17:36 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/0e369b3a31
17:36 dalek MoarVM/moar-jit: 99f3c37 | (Bart Wiegmans)++ | src/jit/graph.c:
17:36 dalek MoarVM/moar-jit: Re-enable sp_findmeth
17:36 dalek MoarVM/moar-jit:
17:36 dalek MoarVM/moar-jit: jnthn++'s change fixed the problems for sp_findmeth as
17:36 dalek MoarVM/moar-jit: well as the regular findmeth.
17:36 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/99f3c37dc7
17:36 brrt joined #moarvm
17:36 brrt \o
17:36 * brrt is excited about renewing progress
17:38 brrt for those who are interested, i'm building moar without gcc optimizations - this moves the time for building core.setting up to 50 s - but JIT with sp_findmeth reduces that to 46 s
17:41 brrt can we implement getdynlex, or will that pose a problem?
17:42 brrt oh, i think it will
17:46 brrt for the same reasons as before
17:46 brrt :-)
17:49 jnthn I think the inliner refuses to directly inline getdynlex
17:49 jnthn The bug isn't about getdynlex itself, it occurs when the lexicals are declared in frames that get inlined.
17:49 jnthn So I don't think it'll be a problem, off hand.
17:50 jnthn brrt: Any objections to me having a crack at extops JIT this evening?
17:50 brrt no, not at all
17:50 brrt :-)
17:50 jnthn OK. Fine if I merge latest master in too?
17:50 brrt sure
17:51 brrt i'm not sure how you would want to do it, but i would have started with adding a special node
17:51 brrt that node would contain the function pointer, the ins info (invokish etc), and the argument array
17:52 brrt the argument array.. i was hoping we could let the spesh codegen do most of that - i.e. i see little reason to replicate it in jit/graph.c or something lik ethat
17:53 brrt and what i was hoping even more is to simply use the encoded arguments of the spesh cand's bytecode, i.e. take a pointer into that array
17:53 brrt then, assuming the speshed bytecode won't move afterwards, you can embed the pointer directly
17:54 brrt otherwise, you'd need to manage an array of encoded arguments in the JitCode and JitGraph structures, and i hardly feel for that
17:55 brrt anyway, it's up to you, i'll probably be busy dealing with handlers and afterwards with dynlex
17:58 brrt one more thing that you've probably already seen but is relevant anyway: if you're storing pointers directly, beware that - because of dynasm function signatures - they are passed in two pieces (upper and lower 32 bits), so you'll have to use the special mov64 opcode and cast the pointer to an integer type of sorts
17:59 nwc10 brrt: JIT build fail
17:59 nwc10 Too many positional parameters passed; got 2 but expected 1 at gen/moar/stage1/NQPHLL.nqp:2072  (gen/moar/stage1/NQPHLL.moarvm::107)
18:00 brrt what
18:00 brrt oh
18:00 brrt hmm
18:01 brrt ..... fuuuu
18:02 brrt that's with sp_findmeth only, right?
18:02 nwc10 yes, that most recent commit
18:02 nwc10 clean build
18:03 brrt bloody...
18:06 jnthn nwc10: And the commit immediately before it was clean?
18:06 nwc10 All tests successful.
18:06 nwc10 yes
18:08 jnthn If it's calling the wrong method, it could be that it's a mistake in validating whether we should use the cached thing
18:08 jnthn dinner; bbiab
18:10 brrt yeah... or maybe the invokish test isn't very good
18:11 brrt and.. that's not it, either
18:14 brrt this is by the way, the undebuggable bug from earlier :-(
18:36 * jnthn back
18:36 nwc10 JIT build good all the way to spectest at 0e369b3a31c74381678e047cbfe73db0e520c044
18:38 nwc10 fail on HEAD is for
18:38 nwc10 /home/nicholas/Sandpit/moar-g-jit/bin/moar
18:38 nwc10 --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --module-path=gen/moar/stage1 --setting-path=gen/moar/stage1             --setting=NQPCOR
18:38 nwc10 E --no-regex-lib --target=mbc             --output=gen/moar/stage1/QAST.moarvm g
18:38 nwc10 en/moar/stage1/QAST.nqp
18:38 nwc10 valgrind finds nothing wrong
18:39 nwc10 I can't see how to help further. And all I can really say is that it's not undefined behaviour. Something in the code is wrong.
18:43 brrt basically, there's an error that creeps in during the compilation of NQPHLL.nqp
18:43 brrt that error then breaks the compilation of QAST.nqp
18:43 brrt why should this be so? well, no idea, really
18:44 nwc10 it's a stage 1 error
18:44 brrt it also happens in stage2 :-)
18:44 nwc10 sure, but a clean build doesn't get that far
18:44 brrt you can work arround it by disabling jit in the compilation of NQPHLL
18:44 nwc10 is it possible to diff the outputs of stage 0 for JIT and not-JIT?
18:45 nwc10 I infer that the divergent behaviour is happening at runtime of stage 0
18:45 nwc10 while stage 0 is compiling stage 1
18:45 brrt yeah, i think that's possible
18:45 brrt although
18:45 brrt how to interpret the difference?
18:46 nwc10 stop asking sensible questions :-)
18:46 nwc10 I think, if you can identify which stage1 output file(s) have differences
18:47 nwc10 you can then start to figure out which bit of code running at stage0 is differing
18:48 brrt that... seems like sensible even if not entirely feasible
18:48 jnthn I can reproduce the issue on Windows too, fwiw
18:50 jnthn Looking at the backtrace, it happens while loading NQPHLL
18:51 brrt :-(
18:51 * brrt bbiab
18:51 dalek MoarVM/moar-jit: a9906fa | jnthn++ | src/mast/compiler.c:
18:51 dalek MoarVM/moar-jit: Don't hunt for outer frame index if it's cached.
18:51 dalek MoarVM/moar-jit:
18:51 dalek MoarVM/moar-jit: This was, curiously enough, one of the biggest time sinks in the
18:51 dalek MoarVM/moar-jit: entire assembly of large things like CORE.setting.
18:52 dalek joined #moarvm
18:53 jnthn That brings in latest stuff from master
18:58 jnthn The call to new_type in:
18:58 jnthn my $knowhow := nqp::knowhow().new_type(:repr("P6bigint"));
18:58 jnthn Is being compiled as:
18:58 jnthn 00103   prepargs     Callsite_5
18:58 jnthn 00104   arg_o        0, loc_15_obj
18:58 jnthn 00105   arg_s        1, loc_16_str
18:58 jnthn 00106   invoke_o     loc_15_obj, loc_17_obj
18:59 jnthn Which means it really does have a positional arg there instead of a named one in the compiled output
19:03 dalek MoarVM/moar-jit: 3bad756 | jnthn++ | src/core/bytecodedump.c:
19:03 dalek MoarVM/moar-jit: Unbust bytecode dump after lazy frame loading opt.
19:03 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3bad756339
19:06 FROGGS too bad, the commit is 3bad
19:15 jnthn I think I can imagine what's going wrong here
19:15 jnthn When we attach a named arg to something, it mixes in
19:15 jnthn Mixing in does deopt_all
19:15 jnthn But we don't know how to deopt JITted frames yet
19:16 jnthn cannot deopt from jitted frame named
19:16 jnthn cannot deopt from jitted frame colonpair
19:17 timotimo good catch
19:17 jnthn (if I put in a line to note the times we fail)
19:17 jnthn So yeah, it's a known todo.
19:21 timotimo that's definitely good to know
19:26 brrt joined #moarvm
19:28 timotimo there's certainly a lot of mysteries around the whole jit topic
19:28 brrt jnthn++ for brilliance :-o
19:30 brrt am i correct in assuming that if and when we have the extent-list-for-JIT-inlines-and-handlers (ahum)
19:30 brrt then we can fix this?
19:32 timotimo the elfiah?
19:32 jnthn It's related, yeah...
19:42 brrt elfiah?
19:42 timotimo the Extent List For Inlines and Handlers
19:42 vendethiel .oO( the elvish trees have spoken )
19:43 * brrt likes that
19:56 brrt ugh, complexity is greater than assumed
20:05 brrt although the deopt stuff seems like it should be doable if it can be started correctly, like in deopt_one
20:10 odc` joined #moarvm
20:16 klaas-janstol joined #moarvm
20:29 jnap1 joined #moarvm
21:09 ventica joined #moarvm
21:34 lizmat joined #moarvm
21:44 woolfy joined #moarvm
21:55 woolfy joined #moarvm
22:25 klaas-janstol joined #moarvm
22:32 dalek MoarVM/moar-jit: aafb3aa | jnthn++ | src/ (6 files):
22:32 dalek MoarVM/moar-jit: Fix deopt_all under JIT compilation.
22:32 dalek MoarVM/moar-jit:
22:32 dalek MoarVM/moar-jit: This records the JIT labels that map to each deopt all index, so we
22:32 dalek MoarVM/moar-jit: can turn a jit_entry_label into a deopt index at the time we need to
22:32 dalek MoarVM/moar-jit: deopt all. Fixes the crash in the NQP build under the JIT due to the
22:32 dalek MoarVM/moar-jit: named parameter QAST construction mixing in and triggering deopt_all.
22:32 dalek MoarVM/moar-jit: This is Fisher Price My First JIT Patch (TM); review suggested.
22:32 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/aafb3aaba4
22:33 * jnthn suspects brrt++ will be happy to see this in the morning. :)
22:33 jnthn Hope it works on Not My Machine too... :)
22:34 timotimo i can try it :)
22:34 * japhb imagines a Happy Fun Ball style spoof commercial for My First JIT Patch
22:36 timotimo was able to build nqp from scratch
22:36 timotimo (well, from scratch is wrong of course. i didn't create the universe first)
22:37 jnthn timotimo: yay
22:37 timotimo parse is at 34 seconds right now, but my computer is quite busy with other stuff
22:37 jnthn That was quite a fiddly one to write. But all deopt-related patches have been...
22:38 timotimo even sanity tests work fine!
22:43 jnthn Rakudo ones too :)
22:43 timotimo the rakudo tests, yes
22:44 jnthn oh, yeah, for some unknown reason I thought you meant the NQP ones
22:44 timotimo the beginning of the spectest looks good
22:46 timotimo oh well
22:46 timotimo ===(   20312;143   8/10  1/9  1/6 )=====================================*** Error in `/home/timo/perl6/rakudo/../install/bin/moar': munmap_chunk(): invalid pointer: 0x00007f0336559ebe ***
22:47 timotimo oh, hold on, do we have master merged in now?
22:47 jnthn What test?
22:47 jnthn Yes
22:47 timotimo t/spec/S17-promise/start.t it seems
22:47 jnthn But there's still at lesat one race I know of...
22:47 timotimo no, i think times.t is it
22:48 timotimo Unhandled exception: Contextual name cannot be null    and    Unhandled exception: Cannot assign to a readonly variable or a value
22:51 timotimo this is races caused by the jit or races caused by our recent optimizations to making stuff lazily vivified?
22:52 jnthn The latter, I think
22:52 timotimo OK, so if i want to develop something on moar with multithreaded stuff i ought to go back to 2014.07
22:52 timotimo well, that's fine
22:54 jnthn Was pondering patching it tonight, but ended up doing the jit deopt patch instead
22:54 timotimo that'll allow brrt to continue tomorrow morning
22:54 timotimo i think the decision was good.
22:55 jnthn aye
22:55 jnthn I know deopt can be horrible, and didn't really want him to lose another day to it
22:56 timotimo yeah, far too many bug hunts of his have ended somewhere that was way out of his range
23:02 jnthn Well, a JIT can only be so much of an isolated thing.
23:02 timotimo definitely true
23:06 klaas-janstol joined #moarvm
23:07 ventica joined #moarvm
23:32 dalek MoarVM/jit-extops: 16bde9a | jnthn++ | src/jit/graph.c:
23:32 dalek MoarVM/jit-extops: An initial sketch of JITting extops calls.
23:32 dalek MoarVM/jit-extops:
23:32 dalek MoarVM/jit-extops: Doesn't yet fully work, most probably because it JITs some that are
23:32 dalek MoarVM/jit-extops: invokey without handling that, or that mess with interpreter state
23:32 dalek MoarVM/jit-extops: (and so need a mechanism to flag them "don't JIT me").
23:32 dalek MoarVM/jit-extops: review: https://github.com/MoarVM/MoarVM/commit/16bde9abd1
23:33 jnthn That's all I've got energy for today... Mebbe I'll be able to finish that up tomorrow. :)
23:34 timotimo wouldn't "don't jit me" just be another flag on the op?
23:34 jnthn yeah, it's not that it's hard, it's just that I'm tired :)
23:35 jnthn I already added ext op flags
23:35 timotimo right
23:35 japhb jnthn: When you're less tired: I added the --min-time option for you to tune the noise thresholding
23:35 timotimo good night, then :)
23:35 jnthn japhb: Ah, cool. I'll have to do another benchmark run here soon. Hopefully with the JIT on to see how it handles things :)
23:35 oetiker joined #moarvm
23:35 japhb :-)
23:36 jnthn Really need exception handlers to work for that, though, since loops emit them.
23:36 jnthn brrt++ was looking at that today though, so maybe we get them in the not too distant future :)
23:36 jnthn japhb: Weren't you working on some concurrency stuff that spawned various scripts at one point, ooc?
23:37 jnthn Or spawned various other things, anyway....
23:37 jnthn Anyway, if so, I started working on a Proc::Async today, which should allow rather more efficient handling of such things (e.g. without blocking up a thread per process you spawn) :)
23:38 jnthn Anyways, yes, good night :) o/
23:42 japhb jnthn: Oh yay!  Yes, I did have a couple variations on a script that would spawn a lot of children, and pretty much eat up the thread pool with that.  Will your async spawning include being able to capture (or otherwise attach to) the child's standard handles?
23:44 japhb Oh, in case it wasn't clear ... the --min-time flag is a flag for the analysis phases, and acts as a filter on the timing data.  The timing data files always include all the collected info, so you needn't do new benchmark runs just to play with that particular knob.
23:45 timotimo japhb: should we teach perl6-bench to build multiple components in parallel?
23:46 japhb timotimo: I had initially *not* done that because multiple rakudos building at once could OOM a box.  But maybe it's time to consider a flag or env var for that.
23:47 timotimo hah
23:47 timotimo aye
23:49 japhb Let me put it this way ... I'm happy to test async spawn functionality in r-m by implementing parallel checkout builds in p6-b.  :-)
23:53 timotimo i'm off for tonight
23:53 timotimo o/
23:55 japhb o/

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