Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-02-19

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

All times shown according to UTC.

Time Nick Message
00:10 eternaleye joined #moarvm
00:18 masak joined #moarvm
00:18 PerlJam joined #moarvm
00:32 eternaleye joined #moarvm
00:33 lizmat joined #moarvm
00:47 woolfy joined #moarvm
00:53 cognominal joined #moarvm
01:29 cognominal joined #moarvm
02:04 frodwith left #moarvm
02:28 eternaleye joined #moarvm
02:35 FROGGS joined #moarvm
04:10 jnap joined #moarvm
05:11 jnap joined #moarvm
07:43 FROGGS joined #moarvm
08:06 flussence joined #moarvm
08:27 odc joined #moarvm
08:42 moritz nwc10: your current mode of operation wrt patches seems rather inefficient (easy to lose track which patches haven't been applied)
08:43 moritz nwc10: would it help to provide some sort of git repo that's occasionally synced with github?
08:43 nwc10 maybe. However (a) I haven't lost track
08:43 nwc10 (b) I think I've done most of what I was hoping to get done
08:43 moritz ok
08:43 nwc10 (ie my contribution rate may well drop off in the medium term)
08:44 nwc10 that lot are really only "fix that thing that was bugging me with the GC changes - small non-inline functions"
09:49 crab2313_ joined #moarvm
09:53 jnthn nwc10: Urgh
09:53 jnthn Configuring native build environment ................... OK auto-detecting x64 toolchain ....................... YES probing whether your compiler thinks that it is gcc  Can't compile simple gcc probe, so something is badly wrong at build/probe.pm line 92.
09:53 jnthn uh, pasting fial
09:53 jnthn fail
09:58 jnthn nwc10: Can you try https://gist.github.com/jnthn/9089099 ?
10:08 jnthn Anyway, with that extra patch it builds here.
10:08 jnthn Running spectest now.
10:11 jnthn No noticable performance difference so far.
10:16 dalek MoarVM: 5da7d03 | nicholas++ | / (2 files):
10:16 dalek MoarVM: Add probing code to Configure.pm to learn how the compiler does 'static inline'
10:16 dalek MoarVM:
10:16 dalek MoarVM: The compiler probing framework is intended to be generic, and is based on the
10:16 dalek MoarVM: approach used by Perl 5's Configure, but with the compiler and linker flags
10:17 dalek joined #moarvm
10:31 nwc10 jnthn: yes, that change still works on OS X, Linux, HP/UX and AIX
10:31 jnthn nwc10: OK.
10:31 jnthn I'm not entirely fond of the fact that every MVM_ASSIGN_REF is now trickier to write...
10:32 jnthn (with the next patches)
10:32 nwc10 not surprised. *but* we had some fun with g++ on FreeBSD and OS X, where the "same" version behaved different
10:32 nwc10 differently
10:32 nwc10 no, I'm not either. It would be totally possible to put the cast back into it
10:33 jnthn Yeah, but then we're back to them all being strict aliasing violations...
10:34 nwc10 yes. Well, to be fair, I don't know if they *are* strict aliasing violations, becuase that's stuff I don't understand well. But it is another thing you have to check to be sure that they aren't
10:36 nwc10 I don't mind if you punt on it for now, or decide to reject it.
10:38 jnthn It gets murky in the sense that there's plenty of times you can violate the rules, but there's no optimization available that transforms code in a bad way at that point.
10:39 jnthn We would, afaict, be vulnerable here if we invoked the write barrier, it cast, set a header bit, and then we tried to read the header bit using the original pointer.
10:39 jnthn In that, the read of the header field could potentially have been cached/hoisted/whatever.
10:40 jnthn That's an unlikely thing to do.
10:40 jnthn But playing chicken with the optimizer is probably a bad idea. :)
10:41 jnthn Which is what we're doing now, given things fall apart under -O2...
10:41 nwc10 yes, good analysis
10:43 jnthn I recently spent a bunch of time reading up on memory barriers, and the C#/Java semantics of volatile, and those influence similar optimizations.
10:44 jnthn (volatile implies a half-barrier on those platforms; in C it doesn't imply any such thing...)
10:46 jnthn nwc10: You appear to have attached the MoarVM patch 0001 twice, rather than the Rakudo one.
10:47 nwc10 Interesting.
10:47 nwc10 In that I tried hard not to
10:47 nwc10 OK, I see now I failed
11:01 jnthn Yes, that one applies with rather less conflcits ;-)
11:05 nwc10 it did occur to me that given the rather consistent naming convention of all the MVMObject derivatives, it would be possible to have MVM_ASSIGN_REF be 2 macros, and just do the games textually to get ->common.header
11:06 nwc10 but that also seemed ugly
11:06 nwc10 and Perl 5 has way to many casts and macros and stuff
11:06 jnthn *nod*
11:06 nwc10 a comment of a long-ago colleague was that the spidermonkey source was much easier to read, as it wasn't macro soup
11:16 dalek MoarVM: eae3b91 | nicholas++ | src/ (39 files):
11:16 dalek MoarVM: Pass an MVMCollectable* to MVM_ASSIGN_REF(), without using casts.
11:16 dalek MoarVM:
11:16 dalek MoarVM: All derivatives of MVMObject and MVMSTable contain a nested MVMCollectable
11:16 dalek MoarVM: struct. By using structure member access, we can get a pointer to it without
11:16 dalek MoarVM: using a cast. This encourages type safety, and reduces the number of casts and
11:16 dalek MoarVM: hence places that might conceal strict aliasing violations.
11:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eae3b91d4c
11:16 dalek MoarVM: f4232b3 | nicholas++ | src/ (4 files):
11:16 dalek MoarVM: Convert MVM_WB to an inline function MVM_gc_write_barrier().
11:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f4232b3959
11:21 tgt joined #moarvm
11:34 tgt joined #moarvm
11:53 dalek MoarVM: 4290f68 | jnthn++ | docs/ChangeLog:
11:53 dalek MoarVM: Start a ChangeLog; add 2014.02 entries.
11:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4290f6883d
12:27 woolfy1 joined #moarvm
12:28 lizmat_ joined #moarvm
12:33 woolfy joined #moarvm
12:33 lizmat joined #moarvm
12:36 lizmat joined #moarvm
12:49 timotimo should we put something in the makefile to give gdb a -fno-strict-alias or what it's called as well as -O2 by default?
12:49 jnthn gdb? or gcc?
12:49 timotimo gcc, sorry
12:49 jnthn Dunno. Does it work?
12:50 timotimo it seemed to the last time i tried it
12:50 jnthn Maybe safer post-release? :)
12:50 timotimo sure
12:50 jnthn So we get some more testing...
12:50 jnthn But yeah, let's do it after the relesae is cut.
12:53 nwc10 jnthn: for completeness, I think that this is the last one that can usefully be done from sc.c: http://paste.scsys.co.uk/308694
12:53 nwc10 not fully tested yet :-)
12:57 jnap joined #moarvm
12:58 jnthn k :)
12:59 nwc10 well, it got to the end of Rakudo's own tests
13:28 jnthn I'll do the MoarVM relesae this evening, so that's how long there is to sneak in any more patches :)
13:29 tgt joined #moarvm
13:30 moritz http://perlpunks.de/paste/show/5304b1de.2a60.167 # current spectest failures on jvm and moar
13:30 timotimo moritz: for the release, i should see to it that the failing jvm tests are fudged, but i don't have to do that for rakudo-moar, right?
13:31 timotimo especially since we don't want any fudged tests without associated tickets any more
13:31 moritz timotimo: correct
13:33 jnthn Sounds reasonable.
13:34 jnthn Let's aim for clean Moar spectest in March release.
13:34 timotimo i'll look into the exact errors from these tests soon
13:34 timotimo that would be crazy-cool
13:34 timotimo especially given that you want to go for concurrency and async IO next :)
13:40 ggoebel1117 joined #moarvm
14:09 dalek joined #moarvm
14:15 colomon joined #moarvm
14:21 jnap joined #moarvm
14:36 tgt joined #moarvm
15:20 benabik joined #moarvm
15:21 tgt joined #moarvm
15:37 tgt joined #moarvm
15:51 timotimo hum
15:52 timotimo it seems like the little floating window it opens to show what it recognized or when it wants me to repeat or something is stealing the focus and then dragon gets confused
15:52 timotimo so i can only every dictate a piece of text at once and then have to click in the input area again
15:53 jnthn timotimo: ww? :)
15:54 FROGGS no need to start a world war now^^
15:54 FROGGS voice recognition is not that important
15:54 tadzik what :D
15:55 timotimo oh, yes.
15:55 * timotimo is trying out Dragon Naturally Speaking on wine
15:55 timotimo fortunately the recognition stuff works as flawlessly as under windows
15:55 FROGGS hehe, perhaps too mcuh wine??
15:55 FROGGS :P
15:56 tadzik Dragon Speaking on Wine? He must be speaking funny
15:56 timotimo %)
15:57 timotimo i think i'll need a more "advanced" window manager to handle this
16:00 timotimo i wonder if a more up-to-date wine version would help any
16:02 * FROGGS .oO( Draco dormiens numquam titillandus )
16:03 timotimo wine's virtual desktop helps with that problem \o/
16:08 tgt joined #moarvm
16:24 nwc10 jnthn: though on Moar concurrency - I think if you implement the idea of the GC freeing stuff in a different thread, you have to block the original thread from re-entering the GC. (Which it's not clear that is planned). Because having a worker thread free stuff means that fromspace is no longer dead memory, able to be re-used as a new tospace
16:26 jnthn nwc10: I'm pondering having a general "service thread" that does that and also runs around doing specializations, and that we include that in the "things to sync when starting GC"
16:27 jnthn nwc10: But yes, I'd thought of the race there already. :)
16:27 nwc10 giid
16:27 nwc10 er, good
16:27 jnthn So far all I've done is get Thread.pm expressed in nqp::ops rather than JVM interop.
16:28 jnthn Which means it's now nicely abstracted.
16:29 jnthn Got some simpler code out of it too
16:31 dalek MoarVM: 10580a0 | jnthn++ | docs/ChangeLog:
16:31 dalek MoarVM: ChangeLog corrections; japhb++.
16:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/10580a0828
16:32 * japhb is perhaps unreasonably excited by the idea of getting concurrency on r-m soon.  And actually, of having it expressed in terms of ops instead of JVM interop -- it will feel safer to contribute when that conversion is done.
16:32 tgt joined #moarvm
16:33 jnthn japhb: The JVM interop way was certainly very good for rapidly developing it in the first place, though. )
16:34 jnthn japhb: Hard to predict how rapidly things will go, also. :)
16:34 japhb jnthn: Oh definitely.  And I've been happily using it for ... well, pretty much right after you wrote it.  :-)
16:39 jnthn japhb: And now you're looking forward to not getting teased about startup time? :)
16:41 nwc10 I suspect it will rapidly find bugs
16:42 nwc10 but how long it keeps finding bugs for, that's hard
16:42 jnthn *nod*
16:49 japhb jnthn: OMG YES.
16:50 japhb Plus, you know, not having to wait all that time myself ...
16:50 japhb I've considered setting up servers whose only purpose is to remove the startup delay for my heavier concurrent stuff.
16:50 japhb Because sometimes the reason I'm doing something concurrently is to ... not wait so much.
16:53 timotimo %)
16:55 jnthn There's something kinda amusing about running perl6-m tools/update_ops.p6 :)
16:57 timotimo a very light scent of circularity is in the air
16:58 tadzik you can smell someone smelling
17:11 tgt joined #moarvm
17:24 timotimo i can smell someone smiling
18:03 rurban_ https://github.com/ivmai/libatomic_ops/blob/master/ChangeLog#L175
18:03 rurban_ Fix AO_compare_and_swap return type for s390 and PowerPC.
18:06 rurban_ But fetch_compare_and_swap is still not implemented
18:08 tgt joined #moarvm
18:10 rurban_ however those architectures (ppc, ppc64) do work fine with gcc (doing inline assembly)
18:12 jnthn Are those big endian?
18:12 rurban_ sure
18:12 rurban_ I'm even having a natove ppc machine at home. My potion jit works fine with ppc
18:12 rurban_ The CAS problem is only on native AIX and HP/UX compilers
18:13 jnthn Yeah, we didn't do the work to fiddle the bytecode so things work out on big endian yet.
18:13 rurban_ I see
18:13 * jnthn is more going for being worth porting/running ahead of working in lots of places first :)
18:15 dalek MoarVM/moar-conc: 39ee02a | jnthn++ | / (12 files):
18:15 dalek MoarVM/moar-conc: Bring thread ops in line with desired API.
18:15 dalek MoarVM/moar-conc:
18:15 dalek MoarVM/moar-conc: The thread code itself hasn't been touched for months, so will need
18:15 dalek MoarVM/moar-conc: a good bit of work. Not to mention the places missing concurrency
18:15 dalek MoarVM/moar-conc: control.
18:15 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/39ee02a467
18:52 FROGGS joined #moarvm
19:10 tgt joined #moarvm
20:11 tgt joined #moarvm
20:37 flussence joined #moarvm
21:06 flussence joined #moarvm
21:08 tgt joined #moarvm
21:17 flussence joined #moarvm
21:18 cognominal joined #moarvm
21:19 dalek MoarVM/moar-conc: 19dbf88 | jnthn++ | src/core/threads.c:
21:19 dalek MoarVM/moar-conc: Don't inherit caller when starting a new thread.
21:19 dalek MoarVM/moar-conc:
21:19 dalek MoarVM/moar-conc: Certainly, that doesn't happen on the JVM, and given most things run
21:19 dalek MoarVM/moar-conc: on a thread pool thread in real code, it's not much use anyway.
21:19 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/19dbf88916
21:19 dalek MoarVM/moar-conc: 3986719 | jnthn++ | src/core/frame.c:
21:19 dalek MoarVM/moar-conc: Avoid frame pool out-of-bounds on new threads.
21:19 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/398671934f
21:19 dalek MoarVM/moar-conc: 316b58e | jnthn++ | src/core/thread (2 files):
21:19 dalek MoarVM/moar-conc: Create cur_usecapture on thread start, not alloc.
21:19 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/316b58e305
21:25 flussence joined #moarvm
21:33 tgt joined #moarvm
22:10 dalek MoarVM/moar-conc: d11e964 | jnthn++ | src/gc/roots.c:
22:10 dalek MoarVM/moar-conc: Guard against adding a NULL to the worklist.
22:10 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/d11e9647c7
22:10 dalek MoarVM/moar-conc: f7cfbfd | jnthn++ | src/core/threads.c:
22:10 dalek MoarVM/moar-conc: Don't blow up if asking for ID of starting thread.
22:10 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/f7cfbfd332
22:10 dalek MoarVM/moar-conc: 0deecc1 | jnthn++ | src/gc/orchestrate.c:
22:10 dalek MoarVM/moar-conc: Avoid duplicate additions to stolen work list.
22:10 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/0deecc130f
22:16 dalek MoarVM/moar-conc: 7a704ac | jnthn++ | src/moar.c:
22:16 dalek MoarVM/moar-conc: Set up us the initial thread ID.
22:16 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/7a704ace8b
22:17 jnthn Passing 21/25 of thread.t so far.
22:25 dalek MoarVM/moar-conc: 6ffed03 | jnthn++ | src/core/interp.c:
22:25 dalek MoarVM/moar-conc: Block/unblock thread while sleeping.
22:25 dalek MoarVM/moar-conc:
22:25 dalek MoarVM/moar-conc: This means another thread can do GC on its behalf, rather than waiting
22:25 dalek MoarVM/moar-conc: for its slumber to end.
22:25 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/6ffed037cc
23:12 tgt joined #moarvm
23:16 jnthn Data breakpoints FTW
23:17 timotimo \o/
23:17 timotimo got threads.t 100% yet? :)
23:19 dalek MoarVM/moar-conc: 2aa58c7 | jnthn++ | src/gc/gen2.c:
23:19 dalek MoarVM/moar-conc: Correct freelist update code.
23:19 dalek MoarVM/moar-conc:
23:19 dalek MoarVM/moar-conc: At least, this looks righter, and removes comparing two things that
23:19 dalek MoarVM/moar-conc: are potentially unrelated memory addresses.
23:19 dalek MoarVM/moar-conc: review: https://github.com/MoarVM/MoarVM/commit/2aa58c71b2
23:19 dalek MoarVM/moar-conc: 19ff5ac | jnthn++ | src/gc/orchestrate.c:
23:19 dalek MoarVM/moar-conc: Remove unsafe gen2 sweep.
23:19 dalek MoarVM/moar-conc:
23:19 dalek MoarVM/moar-conc: Nice try, but if we only nursery marked, it doesn't matter the thread
23:19 dalek MoarVM/moar-conc: is going away, we still can't go assuming its gen2 objects are dead.
23:19 dalek MoarVM/moar-conc: If it just so happens we already were doing a gen2 run then we'll get
23:19 jnthn timotimo: Got it to same point JVM is at, yeah.
23:19 timotimo yays! :D
23:21 jnthn Was kinda fun, at the point it SEGV'd before I fixed 19ff5ac, to look through the treads and see them GCing in parallel...
23:21 jnthn We need a LOT more exercise for this stuff though.
23:21 jnthn I'll get work passing will have bugs somewhere.
23:21 timotimo sure.
23:21 jnthn *bet
23:25 jnthn https://gist.github.com/jnthn/f292fdc0eafedbe054ae # this works, at lesat..
23:25 jnthn *least
23:25 timotimo what are you tackling next?
23:26 jnthn My bed and then $dayjob and then DT concert :P
23:26 timotimo the thread pool would probably be a possibility
23:26 timotimo Dream Theater? :)
23:26 jnthn I'll do Lock next
23:26 jnthn Yes
23:26 jnthn Perhaps Channel after that.
23:27 timotimo cool :)
23:27 jnthn Thread pool needs locks and lock-free queues.
23:27 jnthn Channels only need the queues.
23:27 timotimo that makes sense
23:27 jnthn iirc, anyway...
23:27 jnthn I think we'll want semaphores too.
23:28 timotimo always helpful
23:28 jnthn Promises use them and I think they're the way to go
23:28 jnthn I may look and see if it'd be better with a barrier.
23:28 jnthn But I don't immediately see how to do it.
23:28 jnthn Hm, or a cond var...
23:29 jnthn Not so fond of those though.
23:29 jnthn So yeah, probably I stick with semaphore
23:29 jnthn Especially as libuv provides 'em.
23:30 jnthn Lock will be a small amount of fun as its mutex ain't reentrant.
23:30 jnthn And we need that.
23:32 jnthn Anyway, I'm encouraged I got this far on day 1 S17 on Moar :)
23:32 jnthn *of
23:36 timotimo \o/
23:37 jnthn OK, I should cut the release...
23:43 timotimo cool :)

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