00:10 eternaleye joined 00:18 masak joined, PerlJam joined 00:32 eternaleye joined 00:33 lizmat joined 00:47 woolfy joined 00:53 cognominal joined 01:29 cognominal joined 02:04 frodwith left 02:28 eternaleye joined 02:35 FROGGS joined 04:10 jnap joined 05:11 jnap joined 07:43 FROGGS joined 08:06 flussence joined 08:27 odc joined
moritz nwc10: your current mode of operation wrt patches seems rather inefficient (easy to lose track which patches haven't been applied) 08:42
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
(b) I think I've done most of what I was hoping to get done
moritz ok
nwc10 (ie my contribution rate may well drop off in the medium term)
that lot are really only "fix that thing that was bugging me with the GC changes - small non-inline functions" 08:44
09:49 crab2313_ joined
jnthn nwc10: Urgh 09:53
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.
uh, pasting fial
fail
nwc10: Can you try gist.github.com/jnthn/9089099 ? 09:58
Anyway, with that extra patch it builds here. 10:08
Running spectest now.
No noticable performance difference so far. 10:11
dalek arVM: 5da7d03 | nicholas++ | / (2 files):
Add probing code to Configure.pm to learn how the compiler does 'static inline'

The compiler probing framework is intended to be generic, and is based on the approach used by Perl 5's Configure, but with the compiler and linker flags eae3b91 | nicholas++ | src/ (39 files): Pass an MVMCollectable* to MVM_ASSIGN_REF(), without using casts.
All derivatives of MVMObject and MVMSTable contain a nested MVMCollectable struct. By using structure member access, we can get a pointer to it without using a cast. This encourages type safety, and reduces the number of casts and hence places that might conceal strict aliasing violations.		 10:16
10:17 dalek joined
nwc10 jnthn: yes, that change still works on OS X, Linux, HP/UX and AIX 10:31
jnthn nwc10: OK.
I'm not entirely fond of the fact that every MVM_ASSIGN_REF is now trickier to write...
(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
differently
no, I'm not either. It would be totally possible to put the cast back into it
jnthn Yeah, but then we're back to them all being strict aliasing violations... 10:33
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:34
I don't mind if you punt on it for now, or decide to reject it. 10:36
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:38
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
In that, the read of the header field could potentially have been cached/hoisted/whatever.
That's an unlikely thing to do. 10:40
But playing chicken with the optimizer is probably a bad idea. :)
Which is what we're doing now, given things fall apart under -O2... 10:41
nwc10 yes, good analysis
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:43
(volatile implies a half-barrier on those platforms; in C it doesn't imply any such thing...) 10:44
nwc10: You appear to have attached the MoarVM patch 0001 twice, rather than the Rakudo one. 10:46
nwc10 Interesting. 10:47
In that I tried hard not to
OK, I see now I failed
jnthn Yes, that one applies with rather less conflcits ;-) 11:01
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:05
but that also seemed ugly 11:06
and Perl 5 has way to many casts and macros and stuff
jnthn *nod*
nwc10 a comment of a long-ago colleague was that the spidermonkey source was much easier to read, as it wasn't macro soup
arVM: f4232b3 | nicholas++ | src/ (4 files):
Convert MVM_WB to an inline function MVM_gc_write_barrier().
11:21 tgt joined 11:34 tgt joined
dalek arVM: 4290f68 | jnthn++ | docs/ChangeLog:
Start a ChangeLog; add 2014.02 entries.
 11:53
12:27 woolfy1 joined 12:28 lizmat_ joined 12:33 woolfy joined, lizmat joined 12:36 lizmat joined
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?
timotimo gcc, sorry
jnthn Dunno. Does it work?
timotimo it seemed to the last time i tried it 12:50
jnthn Maybe safer post-release? :)
timotimo sure
jnthn So we get some more testing...
But yeah, let's do it after the relesae is cut.
nwc10 jnthn: for completeness, I think that this is the last one that can usefully be done from sc.c: paste.scsys.co.uk/308694 12:53
not fully tested yet :-)
12:57 jnap joined
jnthn k :) 12:58
nwc10 well, it got to the end of Rakudo's own tests 12:59
jnthn I'll do the MoarVM relesae this evening, so that's how long there is to sneak in any more patches :) 13:28
13:29 tgt joined
moritz 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?
especially since we don't want any fudged tests without associated tickets any more 13:31
moritz timotimo: correct
jnthn Sounds reasonable. 13:33
Let's aim for clean Moar spectest in March release. 13:34
timotimo i'll look into the exact errors from these tests soon
that would be crazy-cool
especially given that you want to go for concurrency and async IO next :)
13:40 ggoebel1117 joined 14:09 dalek joined 14:15 colomon joined 14:21 jnap joined 14:36 tgt joined 15:20 benabik joined 15:21 tgt joined 15:37 tgt joined
timotimo hum 15:51
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
so i can only every dictate a piece of text at once and then have to click in the input area again
jnthn timotimo: ww? :) 15:53
FROGGS no need to start a world war now^^ 15:54
voice recognition is not that important
tadzik what :D
timotimo oh, yes. 15:55
timotimo is trying out Dragon Naturally Speaking on wine
fortunately the recognition stuff works as flawlessly as under windows
FROGGS hehe, perhaps too mcuh wine??
:P
tadzik Dragon Speaking on Wine? He must be speaking funny 15:56
timotimo %)
i think i'll need a more "advanced" window manager to handle this 15:57
i wonder if a more up-to-date wine version would help any 16:00
FROGGS .oO( Draco dormiens numquam titillandus ) 16:02
timotimo wine's virtual desktop helps with that problem \o/ 16:03
16:08 tgt joined
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:24
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:26
nwc10: But yes, I'd thought of the race there already. :) 16:27
nwc10 giid
er, good
jnthn So far all I've done is get Thread.pm expressed in nqp::ops rather than JVM interop.
Which means it's now nicely abstracted. 16:28
Got some simpler code out of it too 16:29
dalek arVM: 10580a0 | jnthn++ | docs/ChangeLog:
ChangeLog corrections; japhb++.
 16:31
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
16:32 tgt joined
jnthn japhb: The JVM interop way was certainly very good for rapidly developing it in the first place, though. ) 16:33
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. :-)
jnthn japhb: And now you're looking forward to not getting teased about startup time? :) 16:39
nwc10 I suspect it will rapidly find bugs 16:41
but how long it keeps finding bugs for, that's hard 16:42
jnthn *nod*
japhb jnthn: OMG YES. 16:49
Plus, you know, not having to wait all that time myself ... 16:50
I've considered setting up servers whose only purpose is to remove the startup delay for my heavier concurrent stuff.
Because sometimes the reason I'm doing something concurrently is to ... not wait so much.
timotimo %) 16:53
jnthn There's something kinda amusing about running perl6-m tools/update_ops.p6 :) 16:55
timotimo a very light scent of circularity is in the air 16:57
tadzik you can smell someone smelling 16:58
17:11 tgt joined
timotimo i can smell someone smiling 17:24
rurban_ github.com/ivmai/libatomic_ops/blo...geLog#L175 18:03
Fix AO_compare_and_swap return type for s390 and PowerPC.
But fetch_compare_and_swap is still not implemented 18:06
18:08 tgt joined
rurban_ however those architectures (ppc, ppc64) do work fine with gcc (doing inline assembly) 18:10
jnthn Are those big endian? 18:12
rurban_ sure
I'm even having a natove ppc machine at home. My potion jit works fine with ppc
The CAS problem is only on native AIX and HP/UX compilers
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
jnthn is more going for being worth porting/running ahead of working in lots of places first :)
dalek arVM/moar-conc: 39ee02a | jnthn++ | / (12 files):
Bring thread ops in line with desired API.

The thread code itself hasn't been touched for months, so will need a good bit of work. Not to mention the places missing concurrency control.		 18:15
18:52 FROGGS joined 19:10 tgt joined 20:11 tgt joined 20:37 flussence joined 21:06 flussence joined 21:08 tgt joined 21:17 flussence joined 21:18 cognominal joined
dalek arVM/moar-conc: 19dbf88 | jnthn++ | src/core/threads.c:
Don't inherit caller when starting a new thread.

Certainly, that doesn't happen on the JVM, and given most things run on a thread pool thread in real code, it's not much use anyway.		 21:19
arVM/moar-conc: 3986719 | jnthn++ | src/core/frame.c:
Avoid frame pool out-of-bounds on new threads.
arVM/moar-conc: 316b58e | jnthn++ | src/core/thread (2 files):
Create cur_usecapture on thread start, not alloc.
21:25 flussence joined 21:33 tgt joined
dalek arVM/moar-conc: d11e964 | jnthn++ | src/gc/roots.c:
Guard against adding a NULL to the worklist.
 22:10
arVM/moar-conc: f7cfbfd | jnthn++ | src/core/threads.c:
Don't blow up if asking for ID of starting thread.
arVM/moar-conc: 0deecc1 | jnthn++ | src/gc/orchestrate.c:
Avoid duplicate additions to stolen work list.
arVM/moar-conc: 7a704ac | jnthn++ | src/moar.c:
Set up us the initial thread ID.
 22:16
jnthn Passing 21/25 of thread.t so far. 22:17
dalek arVM/moar-conc: 6ffed03 | jnthn++ | src/core/interp.c:
Block/unblock thread while sleeping.

This means another thread can do GC on its behalf, rather than waiting for its slumber to end.		 22:25
23:12 tgt joined
jnthn Data breakpoints FTW 23:16
timotimo \o/ 23:17
got threads.t 100% yet? :)
dalek arVM/moar-conc: 2aa58c7 | jnthn++ | src/gc/gen2.c:
Correct freelist update code.

At least, this looks righter, and removes comparing two things that are potentially unrelated memory addresses.		 23:19
MoarVM/moar-conc: 19ff5ac | jnthn++ | src/gc/orchestrate.c:
MoarVM/moar-conc: Remove unsafe gen2 sweep.
MoarVM/moar-conc:
MoarVM/moar-conc: Nice try, but if we only nursery marked, it doesn't matter the thread
MoarVM/moar-conc: is going away, we still can't go assuming its gen2 objects are dead.
MoarVM/moar-conc: If it just so happens we already were doing a gen2 run then we'll get
jnthn timotimo: Got it to same point JVM is at, yeah.
timotimo yays! :D
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
We need a LOT more exercise for this stuff though.
I'll get work passing will have bugs somewhere.
timotimo sure.
jnthn *bet
gist.github.com/jnthn/f292fdc0eafedbe054ae # this works, at lesat.. 23:25
*least
timotimo what are you tackling next?
jnthn My bed and then $dayjob and then DT concert :P 23:26
timotimo the thread pool would probably be a possibility
Dream Theater? :)
jnthn I'll do Lock next
Yes
Perhaps Channel after that.
timotimo cool :) 23:27
jnthn Thread pool needs locks and lock-free queues.
Channels only need the queues.
timotimo that makes sense
jnthn iirc, anyway...
I think we'll want semaphores too.
timotimo always helpful 23:28
jnthn Promises use them and I think they're the way to go
I may look and see if it'd be better with a barrier.
But I don't immediately see how to do it.
Hm, or a cond var...
Not so fond of those though. 23:29
So yeah, probably I stick with semaphore
Especially as libuv provides 'em.
Lock will be a small amount of fun as its mutex ain't reentrant. 23:30
And we need that.
Anyway, I'm encouraged I got this far on day 1 S17 on Moar :) 23:32
*of
timotimo \o/ 23:36
jnthn OK, I should cut the release... 23:37
timotimo cool :) 23:43

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!