Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-01-04

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

All times shown according to UTC.

Time Nick Message
02:01 colomon joined #moarvm
03:55 colomon joined #moarvm
09:14 rurban joined #moarvm
11:19 kjs_ joined #moarvm
14:00 kjs_ joined #moarvm
14:00 Ven joined #moarvm
14:28 Ven joined #moarvm
14:45 zakharyas joined #moarvm
15:11 Ven joined #moarvm
15:30 kjs_ joined #moarvm
16:09 dalek joined #moarvm
17:20 kjs_ joined #moarvm
17:54 rurban joined #moarvm
18:01 Ven joined #moarvm
19:22 jnthn timotimo: fwiw, I've tended to find probabalistic profiles show up lock or interlocked operations hotter than instrumented ones do while using the Visual Studio tools.
19:22 jnthn I never figured out why and was assuming "Windows artefact", but it'd be curious if it showed up on Linux that way too.
19:23 timotimo hmm, mayhaps
19:23 timotimo how optimistic are you about perl6/rakudo performance in the next few weeks? do you have tips for JimmyZ for the alias analysis stuff he's been up to?
19:24 jnthn Well, this week I'll be quite distracted. :)
19:24 jnthn Next week I'm back home and should be ready to start digging back into things again.
19:25 jnthn I think I'm going to be focusing on 6pe and native arrays first.
19:25 jnthn Those will help performance for programs that can make use of them :P
19:30 timotimo is there anything i could try to do to prepare 6pe for you a tiny bit?
19:32 jnthn The most valuable thing would be to port what I did so far to, say, JVM.
19:32 jnthn Or even Parrot.
19:33 jnthn Thing is, much of what remains to do in Moar is related to the interaction of 6pe and bounded serialization.
19:33 jnthn Which is, uh...delicate. :)
19:33 timotimo oh lord! :P
19:34 jnthn Exactly. :P
19:40 timotimo both porting to jvm/parrot and the interaction ... :S
19:42 jnthn Well, the porting bit should be mostly mechanical
19:42 jnthn And there's tests in nqp/6pe to say if you got it right.
19:45 Ven joined #moarvm
19:45 timotimo i'm frustratingly excitement-driven :\
19:45 nwc10 6pe?
19:46 timotimo sixmodel parametric edition
19:46 nwc10 OK, "sixmodel parametric edition?" - that was the next thing to do for spesh?
19:46 FROGGS__ it is needed for NSA
19:47 nwc10 ah OK thanks
19:49 timotimo i think it's actually "parametric extensions"?
19:49 jnthn It was extensions :P
19:49 jnthn It's a small 6model extension that solves a bunch of painful things that bothered me for a while
19:50 jnthn Though in the relaxation excesses of the past couple of weeks and the work excesses of the preceeding weeks, I'd probably have to go look at my notebook to remember all of them...
19:50 FROGGS__ that's not a reason to call it six-pee though :o)
19:50 jnthn FROGGS__: Eww! In return for that I'm going to tell you to render it in German! :P
19:50 japhb At least you kept notes ....
19:50 jnthn japhb: This is true ;)
19:53 kjs_ joined #moarvm
20:00 colomon joined #moarvm
20:01 timotimo suggest something simple i could pour a bit of spare time into?
20:03 jnthn If you turn off spesh, Rakudo uses a bunch less memory. I think one of the memory sinks is that when we JIT, we also are still producing the optimized bytecode too. I don't know what, exactly, needs us to do that. But I think there's a potential multi-meg reduction on offer for fixing this.
20:04 jnthn Plus not producing the spesh'd bytecode we never use will be a time win too.
20:04 jnthn So I guess it's a case of (a) just try the easiest thing - don't produce it, and (b) untangle what breaks, if anything does
20:04 jnthn It *may* related to deopt tables being built in the code-gen phase.
20:05 jnthn But that feels a bit off...
20:05 jnthn I can't really think easily what it is
20:05 jnthn brrt++ may know
20:05 timotimo i'm not sure what you mean with "spesh'd bytecode we never use"?
20:06 jnthn When we do spesh today, I'm pretty sure if we JIT a frame we also produce the specialized bytecode to interpret
20:06 jnthn But if we have a successful JIT of it, we'll always choose that over interpreting
20:07 jnthn See src/spesh/candidate.c
20:07 jnthn MVM_spesh_codegen(tc, sg); is called; later, we try to JIT. We may want to try to JIT, and do the bytecode formation as a fallback.
20:09 * jnthn hopes he's making some sense
20:11 timotimo oh, we don't use the bytecode as the source for the jit?
20:11 timotimo that's something i have not properly grokked so far
20:11 timotimo now it makes sense to me :)
20:13 jnthn We use spesh graph for both
20:14 timotimo that makes sense
20:15 timotimo do we throw out the spesh graph after we've jitted successfully, too?
20:18 jnthn Yes, that should be happening already.
20:18 jnthn In either case.
20:18 jnthn Otherwise I think we'd be leaking a good bit more.
20:19 japhb jnthn: What's the intended behavior if a thread tries to acquire the same semaphore more than once?  (I'm writing Semaphore tests right now, as you may have guessed.  :-)
20:19 timotimo i'll have a look-see, but for now i'll be AFK and commuting and sleeping :)
20:23 jnthn japhb: It's just asking for another permit
20:23 japhb jnthn: So it should succeed and decrement the available permits normally, then.  Good, that's what I was hoping for.
20:25 jnthn japhb: Yes. That's different from ReentrantMutex, which - as the name hints - makes an already-holding thread re-acquiring the lock Just Work.
20:25 jnthn Or nestedly acquiring.
20:27 japhb right
20:28 dalek MoarVM: 7e95c05 | jnthn++ | src/6model/reprs/ReentrantMutex.c:
20:28 dalek MoarVM: Make ReentrantMutex work out with serialization.
20:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7e95c057ba
20:46 ggoebel111111117 joined #moarvm
21:38 kjs_ joined #moarvm
21:51 FROGGS[tab] joined #moarvm
22:56 FROGGS joined #moarvm
23:07 danaj joined #moarvm
23:18 FROGGS joined #moarvm

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