Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-09-11

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

All times shown according to UTC.

Time Nick Message
01:15 [Coke] =-[p0
07:11 kjs_ joined #moarvm
07:12 timotimo i don't know that emoticn
07:12 timotimo emoticon*
07:18 Ven joined #moarvm
07:19 FROGGS joined #moarvm
07:20 lizmat joined #moarvm
07:27 zakharyas joined #moarvm
07:43 dalek joined #moarvm
07:46 FROGGS joined #moarvm
07:53 kjs_ joined #moarvm
08:11 timotimo how do we feel about the interp having checks for REPRs built-in vs the functions that get called from the interpreter doing REPR checks?
08:14 timotimo i can probably build a function "emit reprcheck" that throws an exception just like thet interpreter would
08:14 timotimo for the jit, that is
08:26 timotimo brrt, do you think it'd be terrible to implement lt_s, gt_s, le_s, ge_s and cmp_s as "append_call_c + append_primitive" and having the == 1/>= 0/== -1/<= 0/NOP part in emit.dasc with a comment saying "the actual comparison was already handled by a call to C"?
08:27 timotimo the terrible part being "there's an implementation of gt_s in the .dasc file that doesn't do anything with strings! wtf!"
08:28 timotimo i think that'd be okay
08:38 kjs_ joined #moarvm
09:01 FROGGS[mobile] joined #moarvm
09:02 FROGGS[mobile]2 joined #moarvm
09:02 lizmat joined #moarvm
09:28 dalek MoarVM: 667b7b5 | jnthn++ | src/ (3 files):
09:28 dalek MoarVM: Ensure thread ID is available after termination.
09:28 dalek MoarVM:
09:28 dalek MoarVM: This has never worked properly, but a recent change in join/GC meant
09:28 dalek MoarVM: that the Rakudo spectests uncovered it.
09:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/667b7b5990
09:35 dalek MoarVM: fd1ed2e | jnthn++ | src/main.c:
09:35 dalek MoarVM: Add MVM_CROSS_THREAD_WRITE_LOG to usage message.
09:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fd1ed2e8fa
09:40 dalek Heuristic branch merge: pushed 81 commits to MoarVM/x64-dynamic-registers by bdw
09:40 dalek MoarVM: 227c556 | jnthn++ | src/instrument/crossthreadwrite.c:
09:40 dalek MoarVM: Don't accidentally the newline to STDOUT.
09:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/227c55663c
09:42 brrt joined #moarvm
09:42 brrt i'm somewhat cautiously optimistic i've fixed the RSP/R12 encoding issues
09:43 zakharyas joined #moarvm
09:45 timotimo sounds good! :)
09:45 jnthn brrt++ # nice
09:45 jnthn x64 instruction encoding sounds...hairy
09:45 brrt it is
09:45 brrt and brittle
09:46 brrt actually, it'd be ok without this exception
09:46 timotimo in addition to gt_s and friends, i'll also add the sc related ops
09:46 timotimo brrt: how do you suggest it'd be easiest to handle ops that have a repr check + exception throw in their interp.c block?
09:46 brrt for some reason though, github doesn't seem to propagate my push
09:48 brrt (do (when (ne (^repr_id obj) (const (&QUOTE MY_EXPECTED_REPR_ID) ptr_sz)) (^throw_adhoc (&MSG not the right repr))) (call (^repr_func blabla) etc)
09:49 brrt yes, that's the world's worst LISP :-P
09:49 timotimo oh
09:49 timotimo i was thinking of the old jit at this point :)
09:49 dalek MoarVM: 1cf0479 | jnthn++ | src/core/interp.c:
09:49 dalek MoarVM: Try to get PC on valid instruction in CTW logging.
09:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1cf04798c3
09:49 timotimo unless of course you think the new jit will be up soon enough :D
09:51 brrt well, i hope at least
09:52 brrt ok, clearly doesn't quite kick it yet
09:52 brrt i'm not terribly surprised as it is quite brittle code
09:53 brrt too bad, i was too eager yet
10:05 jnthn Ouch ouch ouch ouch damn
10:06 jnthn I just discovered where a bunch of our thready crashes come from
10:06 FROGGS ?
10:07 jnthn We have a race condition around following ->outer chains
10:07 FROGGS uhh
10:07 FROGGS that would explain some of the error messages, yeah
10:07 jnthn And it just got more noticable
10:07 jnthn Because yesterday I fixed a code-gen bug that meant we takeclosure'd loads of things we should not have
10:08 timotimo oh!
10:08 jnthn Which meant the frames lived until the next GC run
10:09 jnthn Rather than dying immediately
10:09 jnthn And so hid the races
10:09 JimmyZ we have a 'takeclosure' roadmap on moarvm.org :P
10:09 jnthn JimmyZ: That's mostly about teaching spesh to understand it; this is something else
10:10 brrt ouch, that hurts
10:10 timotimo well, i'm glad i showed you the way to this sillyness in our codegen :)
10:10 JimmyZ oh, I thought it's about the api itself.
10:10 jnthn timotimo: Yes, that was a good hint and helped us get Text::CSV down to better than before we merged glr :)
10:11 timotimo yup <3
10:11 jnthn I'm glad to have this issue uncovered and caught nicely in the debugger, 'cus it will have been a source of much more occasional instability
10:11 jnthn But yeah, how to fix it is...interesting
10:12 jnthn Or how to fix it *well* is, anyway
10:13 jnthn ohh, I wonder if...
10:14 timotimo i wonder why
10:14 timotimo yesterday you told me 'bout the blue, blue sky
10:14 dalek MoarVM/even-moar-jit: 491c1c9 | brrt++ | src/jit/x64/tiles.dasc:
10:14 dalek MoarVM/even-moar-jit: Offset is a 32 bit integer
10:14 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/491c1c9d27
10:14 dalek MoarVM/even-moar-jit: e863e0d | brrt++ | 3rdparty/dynasm:
10:14 dalek MoarVM/even-moar-jit: Update DynASM to deal with r12/rsp irregularity
10:14 dalek MoarVM/even-moar-jit:
10:14 dalek MoarVM/even-moar-jit: RSP and R12 registers are encoded 'specially' because in legacy
10:14 dalek MoarVM/even-moar-jit: x86 RSP would have a special access mode.
10:14 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e863e0d475
10:14 timotimo oh, look, the push came through
10:14 brrt yeah
10:14 brrt we still aren't fully correct though
10:15 brrt but we at least don't SIGSEGV in a silly way
10:17 brrt ok, we're not out of the woods yet
10:17 brrt :-)
10:20 brrt mov    r8,QWORD PTR [rbp-0x30]
10:21 brrt to the tune of the ting tings: that's not my code
10:21 jnthn .oO( that code is totally over-r8-ed )
10:23 brrt i don't emit negative offsets, and certainly not from rbp
10:23 brrt y does this happen to me :-(
10:23 brrt gdb can tell fortunately
10:39 timotimo so another bit of wrong codegen, i suppose?
10:39 timotimo or ... code coding?
10:40 jnthn Darn, the crash vanishes under valgrind... :(
10:50 Ven joined #moarvm
10:50 timotimo valgrind prevents the memory from being overwritten by bogus data?
10:52 jnthn Or slows things down too much to race
10:54 timotimo ah
10:54 timotimo yeah, that sounds likely, indeed
11:13 timotimo my jit addendae don't cause spectest fallout
11:15 jnthn Aha
11:15 jnthn The interesting race is actually in the invocation sequence it seems
11:16 timotimo rather than returning? interesting
11:17 jnthn Yeah, we read the outer to invoke with
11:17 jnthn But don't increment it at that point
11:17 jnthn Increment its refcount that is
11:17 jnthn That happens later
11:17 jnthn By which time it may already have been killed
11:18 jnthn Then we try to re-use it
11:18 dalek MoarVM: 9f140d8 | timotimo++ | src/ (3 files):
11:18 dalek MoarVM: jit continuationreset and continuationcontrol
11:18 dalek MoarVM:
11:18 dalek MoarVM: these ops have to be set "invokish" for this to work
11:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9f140d8ff4
11:18 jnthn Brining a dead frame back to life
11:18 dalek MoarVM: 9f038d4 | timotimo++ | src/jit/ (2 files):
11:18 dalek MoarVM: jit string comparison ops
11:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9f038d4f70
11:18 timotimo so how come the solution isn't to just put the increment a bit earlier?
11:19 jnthn Question is if we can without creating a data race
11:20 jnthn Well, without *retaining* it
11:21 timotimo mhm, we really don't want to go atomic or even worse take a lock for invocations
11:21 jnthn But making it rarer
11:22 jnthn Right :)
11:22 jnthn Anyway, now I understand what's going on, at least.
11:22 jnthn It explains quite a bit.
11:23 jnthn Anyway, lunch, and got a few other bits to do this afternoon.
11:23 jnthn Will have to ponder this one a bit
11:24 * timotimo idly wonders about having bitwise reference counts rather than numeric
11:26 timotimo perhaps a little spinlock could be less than terrible
11:26 timotimo perhaps with a little spinlock we can also get rid of the atomic inc and dec for the refcount
11:29 timotimo huh, where'd my "skip unshift_n and push_n because they're wonky" change to?
11:29 timotimo go*
11:31 JimmyZ timotimo: http://demin.ws/blog/english/2012/05/05/atomic-spinlock-mutex/
11:32 timotimo oh, wow
11:32 timotimo the mutex has so much overhead?
11:32 timotimo amazing
11:49 tadzik joined #moarvm
11:52 dalek MoarVM: 00b3dfd | timotimo++ | src/jit/graph.c:
11:52 dalek MoarVM: don't devirt push_n or unshift_n for now
11:52 dalek MoarVM:
11:52 dalek MoarVM: because of a strange bug resulting in "expected num register"
11:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/00b3dfd8b4
11:52 dalek MoarVM: 0c250b1 | timotimo++ | src/jit/graph.c:
11:52 dalek MoarVM: remove a solitary trailing whitespace
11:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0c250b1d1b
11:54 kjs_ joined #moarvm
12:11 timotimo brrt got an idea what kind of speedup we can expect for not so tight loops from exprtree jit?
12:35 brrt joined #moarvm
12:48 timotimo i only recall the very old estimate from hand crafted asm
12:50 timotimo but i also don't remember what the factor was
12:50 brrt no, i have no idea. hand crafted asm did really well. on a high level, i kind of know how we could get there
12:50 timotimo istr 6x?
12:50 brrt 5x versus the current jit, iirc
12:51 timotimo mhm
12:51 brrt but i cannot overemphasisze that we are really, really, really far from there
12:51 timotimo can we expect 2x as soon as the code gen runs?
12:51 timotimo you have seenbthe asm it generatesbalready
12:51 timotimo mhhh
12:52 timotimo if we do not regress, we can at least flip the switch on graph.c
12:53 brrt no, we can't expect 2x
12:53 brrt we might expect 0.95x, more likely
12:53 timotimo when the rough code generation problems have gone, maybe i can look into implementing missing bits here or there
12:53 timotimo ugh
12:53 brrt hmmm
12:53 timotimo oj afk for a big bit
12:53 brrt i'm not sure this was a codegen bug after all
12:53 brrt i see i do emit rbp-relative code
12:54 brrt see you!
12:54 brrt (i've though ahead on how to implement the optimizer)
12:55 brrt fwiw, using lispy code fragments like i said earlier is not what i'm going to do
12:58 brrt has any of you tried gdb mode within emacs? it works quite well actually
12:58 FROGGS I'm not an emacser...
12:59 brrt well, what do you use?
13:00 brrt emacs is actually turning more IDE-like as you go along
13:00 brrt if you want it, at least
13:03 FROGGS I use SciTE
13:04 FROGGS I've seen lightning talks about emacs... though, I don't feel like changing my editor :o)
13:05 jnthn I keep meaning to give Visual Studio Code a try given it supports Perl 6 :)
13:31 brrt it what
13:31 brrt visual studio code supports perl 6 ? :-o :-o
13:31 jnthn It claims to have syntax highlighting for Perl 6
13:32 brrt awesome
13:35 JimmyZ url?
13:35 JimmyZ found it
13:55 [Coke] url? I haven't found it. :)
13:59 JimmyZ http://blogs.perl.org/users/andrew_shitov/2015/05/microsofs-visual-studio-code-editor.html
14:28 * [Coke] tries out visualstudio for os x... wonder if I can build moarvm here...
14:29 [Coke] this feels a lot like atom.
14:29 jnthn I'm not surprised. ;)
14:30 jnthn It's based on Electron too iirc
14:30 tadzik everything HTML5 is the same :P
14:31 FROGGS I bet they use the Perl 6 syntax highlighting hoelzro++ did
14:31 JimmyZ adobe has a editor to, it is on github
14:31 [Coke] ... I am lost. jnthn, do you use the studio to build, or command line tools?
14:32 JimmyZ *too
14:32 jnthn [Coke]: command line tools
14:34 dalek joined #moarvm
14:41 btyler_ hi folks. just want to check in before I go filing more PRs like this: https://github.com/MoarVM/MoarVM/pull/258 -- is this a useful thing, or would you rather I just file issues with crashing P6 snippets?
14:43 JimmyZ Didn't we fix it already?
14:44 btyler_ we fixed write,close
14:44 btyler_ this is close,close and close,write
14:45 JimmyZ oh
14:47 JimmyZ btyler_: PRs are wellcome, but it'd be nice to have some test in roast too :P
14:48 dalek joined #moarvm
14:49 btyler_ oh, cool, thanks for reminding me -- yes, that makes lots of sense
14:49 FROGGS jnthn: VSC is awesome! http://i.imgur.com/T7AcHpv.png
14:50 FROGGS jnthn: it shows the modified line (compared to git) with a blue bar and the branch I am on (at the buttom)
14:50 jnthn FROGGS: Is it actually doing Perl 6 highlighting there or Perl 5? :)
14:51 [Coke] based on the snapshot, that's perl5
14:51 [Coke] it would say "Perl 6" in the corner.
14:52 [Coke] did seem to work on .p6 files, anyway.
14:52 FROGGS ohh
14:53 JimmyZ you need use v6!
14:57 FROGGS even when I select Perl 6, it gets colonpairs wrong for example
14:58 FROGGS but it is okay
14:58 FROGGS ohh nice, it also shows changed lines (compared to git) on the scrollbar
14:59 FROGGS that's quite handy
14:59 hoelzro btyler_++ # fixes
15:05 dalek MoarVM: 8fd8663 | (Francois Perrad)++ | src/ (3 files):
15:05 dalek MoarVM: fix indentation
15:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8fd866360a
15:05 dalek MoarVM: 383de34 | (Francois Perrad)++ | src/jit/graph.c:
15:05 dalek MoarVM: remove useless &
15:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/383de349dc
15:05 dalek MoarVM: 0607cb2 | (Francois Perrad)++ | src/6model/reprs/CUnion.c:
15:05 dalek MoarVM: remove unless header file
15:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0607cb2eec
15:05 dalek MoarVM: ea3d8a1 | (Francois Perrad)++ | src/ (3 files):
15:05 dalek MoarVM: include with angle
15:05 dalek MoarVM:
15:05 dalek MoarVM: math.h & sys/wait.h are part of standard libraries
15:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ea3d8a12f4
15:09 dalek MoarVM: 9099796 | paultcochrane++ | build/Makefile.in:
15:09 dalek MoarVM: Remove more config and generated files in distclean target
15:09 dalek MoarVM:
15:09 dalek MoarVM: As mentioned in GH #139, the `realclean` target doesn't clean everything up.
15:09 dalek MoarVM: Actually, it seems that the `distclean` target is the one which is supposed
15:09 dalek MoarVM: to clean up the configuration and generated files (at least in MoarVM).
15:09 dalek MoarVM: This wasn't happening completely and the current commit removes all files
15:09 dalek MoarVM: still needing to be cleaned.
15:09 dalek MoarVM:
15:09 dalek MoarVM: The file `src/jit/emit_posix_x64.c` is force-removed since it might not
15:09 dalek MoarVM: exist on non-POSIX systems.  The `config.log` and `config.status` files
15:09 dalek MoarVM: within the atomic ops library are also removed, although they really should
15:09 dalek MoarVM: 9b805c3 | (Ben Tyler)++ | src/io/asyncsocket.c:
15:09 dalek MoarVM: Async sockets: handle close,close and close,write.
15:09 dalek MoarVM:
15:09 dalek MoarVM: This avoids a segfault in case of Perl 6 code like this:
15:09 dalek MoarVM:
15:10 dalek joined #moarvm
15:57 kjs__ joined #moarvm
16:54 tadzik joined #moarvm
17:25 tokuhiro_ joined #moarvm
17:29 brrt joined #moarvm
17:58 brrt joined #moarvm
18:22 FROGGS joined #moarvm
18:26 tokuhiro_ joined #moarvm
18:27 FROGGS o/
18:30 japhb o/
18:33 timotimo o/
19:06 brrt \o
19:07 brrt i ++ the removal of src/jit/emit_posix_x64.c, which i also do in the even-moar-jit branch
19:07 brrt so i suppose that's paultcochrane++ :-)
19:54 dalek Heuristic branch merge: pushed 22 commits to MoarVM/even-moar-jit by bdw
19:57 ggoebel joined #moarvm
20:28 tokuhiro_ joined #moarvm
22:23 tokuhiro_ joined #moarvm
23:12 lizmat joined #moarvm
23:39 dalek joined #moarvm

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