|
02:01
colomon joined
03:55
colomon joined
09:14
rurban joined
11:19
kjs_ joined
14:00
kjs_ joined,
Ven joined
14:28
Ven joined
14:45
zakharyas joined
15:11
Ven joined
15:30
kjs_ joined
16:09
dalek joined
17:20
kjs_ joined
17:54
rurban joined
18:01
Ven joined
|
|||
| 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 | |
| I never figured out why and was assuming "Windows artefact", but it'd be curious if it showed up on Linux that way too. | |||
| timotimo | hmm, mayhaps | 19:23 | |
| 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? | |||
| jnthn | Well, this week I'll be quite distracted. :) | 19:24 | |
| Next week I'm back home and should be ready to start digging back into things again. | |||
| I think I'm going to be focusing on 6pe and native arrays first. | 19:25 | ||
| Those will help performance for programs that can make use of them :P | |||
| timotimo | is there anything i could try to do to prepare 6pe for you a tiny bit? | 19:30 | |
| jnthn | The most valuable thing would be to port what I did so far to, say, JVM. | 19:32 | |
| Or even Parrot. | |||
| Thing is, much of what remains to do in Moar is related to the interaction of 6pe and bounded serialization. | 19:33 | ||
| Which is, uh...delicate. :) | |||
| timotimo | oh lord! :P | ||
| jnthn | Exactly. :P | 19:34 | |
| timotimo | both porting to jvm/parrot and the interaction ... :S | 19:40 | |
| jnthn | Well, the porting bit should be mostly mechanical | 19:42 | |
| And there's tests in nqp/6pe to say if you got it right. | |||
|
19:45
Ven joined
|
|||
| timotimo | i'm frustratingly excitement-driven :\ | 19:45 | |
| nwc10 | 6pe? | ||
| timotimo | sixmodel parametric edition | 19:46 | |
| nwc10 | OK, "sixmodel parametric edition?" - that was the next thing to do for spesh? | ||
| FROGGS__ | it is needed for NSA | ||
| nwc10 | ah OK thanks | 19:47 | |
| timotimo | i think it's actually "parametric extensions"? | 19:49 | |
| jnthn | It was extensions :P | ||
| It's a small 6model extension that solves a bunch of painful things that bothered me for a while | |||
| 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) | ||
| jnthn | FROGGS__: Eww! In return for that I'm going to tell you to render it in German! :P | ||
| japhb | At least you kept notes .... | ||
| jnthn | japhb: This is true ;) | ||
|
19:53
kjs_ joined
20:00
colomon joined
|
|||
| timotimo | suggest something simple i could pour a bit of spare time into? | 20:01 | |
| 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:03 | |
| Plus not producing the spesh'd bytecode we never use will be a time win too. | 20:04 | ||
| 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 | |||
| It *may* related to deopt tables being built in the code-gen phase. | |||
| But that feels a bit off... | 20:05 | ||
| I can't really think easily what it is | |||
| brrt++ may know | |||
| timotimo | i'm not sure what you mean with "spesh'd bytecode we never use"? | ||
| 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 | |
| But if we have a successful JIT of it, we'll always choose that over interpreting | |||
| See src/spesh/candidate.c | 20:07 | ||
| 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. | |||
| jnthn hopes he's making some sense | 20:09 | ||
| timotimo | oh, we don't use the bytecode as the source for the jit? | 20:11 | |
| that's something i have not properly grokked so far | |||
| now it makes sense to me :) | |||
| jnthn | We use spesh graph for both | 20:13 | |
| timotimo | that makes sense | 20:14 | |
| do we throw out the spesh graph after we've jitted successfully, too? | 20:15 | ||
| jnthn | Yes, that should be happening already. | 20:18 | |
| In either case. | |||
| Otherwise I think we'd be leaking a good bit more. | |||
| 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 :) | ||
| 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. | ||
| 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 | |
| Or nestedly acquiring. | |||
| japhb | right | 20:27 | |
| dalek | arVM: 7e95c05 | jnthn++ | src/6model/reprs/ReentrantMutex.c: Make ReentrantMutex work out with serialization. |
20:28 | |
|
20:46
ggoebel111111117 joined
21:38
kjs_ joined
21:51
FROGGS[tab] joined
22:56
FROGGS joined
23:07
danaj joined
23:18
FROGGS joined
|
|||