timotimo | cool :) | 00:10 | |
dalek | arVM: 4d3c45d | jimmy++ | src/jit/emit_x64.dasc: s/dec/sub/ && s/inc/add/, which is cheaper |
02:06 | |
timotimo | stackoverflow.com/questions/133834...an-inc-x86 / stackoverflow.com/questions/121636...rformances / stackoverflow.com/questions/599332...nstruction | 02:07 | |
On some micro-architectures, with some instruction streams, INC will incur a "partial flags update stall" (because it updates some of the flags while preserving the others). ADD sets the value of all of the flags, and so does not risk such a stall. | 02:11 | ||
that's apparently what's up | |||
02:14
jimmy_ joined
|
|||
jimmy_ | which means it's better to do out-of-order execution? | 02:14 | |
japhb | Or at least use multiple execution units more effectively | 02:15 | |
02:24
timotimo joined
|
|||
JimmyZ | stackoverflow.com/questions/121636...es#tab-top | 02:30 | |
timotimo | so, did our performance just go through the roof? :) | 02:47 | |
hoelzro | so I'm trying to understand how bytecode loading works | 03:43 | |
I see these calls to nqp::loadbytecode in ModuleLoader.nqp, but I don't understand how the loaded symbols make it into @GLOBALish | 03:44 | ||
JimmyZ | MVM_cu_from_bytes ? | 03:45 | |
hoelzro | JimmyZ: you probably know better than I =) | 03:46 | |
I just don't see any return value being used, so I'm guessing something in NQP/Moar pushes something into @GLOBALish through a reference of some sort | 03:47 | ||
JimmyZ | anyway, the code is in src/core/compunit.c which returns a compunit | 03:48 | |
06:05
jimmy_ joined
|
|||
dalek | arVM: 9e03616 | TimToady++ | src/6model/reprs/NFA.c: act needs to fit into 32-bit signed (for jvm) |
07:05 | |
07:22
nebuchadnezzar joined
|
|||
JimmyZ | .oO(MoarVM on JVM) |
07:31 | |
07:48
FROGGS joined
07:58
brrt joined
08:04
kjs_ joined
09:27
kjs_ joined
10:20
zakharyas joined
11:20
kjs_ joined
|
|||
timotimo | hoelzro: i think the code in each comp unit has a frame that's responsible for doing the deserialization and installation of symbols | 12:52 | |
have you --dump'd a simple module? | |||
12:53
timo joined
12:59
lue joined
|
|||
hoelzro | timotimo: I haven't | 13:16 | |
timotimo | maybe it'd be a good idea :) | ||
hoelzro | sounds good =) | ||
hoelzro .oO( how does one do that? ) | |||
tadzik | use weechat :) | 13:17 | |
timotimo | moarvm --dump foobar.moarvm | 13:19 | |
hoelzro | [7:20:22] rob@eridanus /tmp/golfed-abc $ moar --dump lib/ABC/Grammar.pm | 13:20 | |
Unhandled exception: Bytecode stream shorter than header | |||
=/ | |||
tadzik | .pm doesn't look like bytecode stream :) | 13:21 | |
timotimo | yeah | ||
hoelzro | oops | ||
hoelzro needs coffee | |||
what's a frame and a callsite? I'm guessing the former is like a scope of sorts? | 13:46 | ||
13:49
kjs_ joined
|
|||
timotimo | frames are pieces of code together with local and lexical variables that can be invoked | 14:09 | |
callsites are shared structures that hold information about the shape of a call used at any given point | |||
for example: | 14:10 | ||
m: say "hello"; say "goodbye"; | |||
camelia | rakudo-moar 316f99: OUTPUTĀ«helloā¤goodbyeā¤Ā» | ||
timotimo | these two invocations of "say" share a callsite, because they both have just one argument | ||
callsites are important to moar because they give us a way to hang specializations off of invocations | |||
a callsite is, however, not tied to a given "target" | 14:11 | ||
m: say "hello"; print "what" | |||
camelia | rakudo-moar 316f99: OUTPUTĀ«helloā¤whatĀ» | ||
timotimo | these two invocations would have the same callsite assigned to them, too | ||
hoelzro | I see, thanks! | ||
btw, I went over the dump of a very stupid module | 14:12 | ||
and I'm no closer to figuring it out =/ | 14:13 | ||
granted, the module is just 'package ABC {}', so it's probably too little to tell me anything | |||
17:35
kjs_ joined
17:54
lizmat joined
18:01
kjs_ joined
|
|||
dalek | arVM: 4d71a93 | TimToady++ | src/6model/reprs/NFA.c: lazier longlit initialization |
18:17 | |
18:33
travis-ci joined
|
|||
travis-ci | MoarVM build errored. TimToady 'lazier longlit initialization' | 18:33 | |
travis-ci.org/MoarVM/MoarVM/builds/42110425 github.com/MoarVM/MoarVM/compare/9...71a93b814c | |||
18:33
travis-ci left
18:44
FROGGS joined
|
|||
timotimo | jnthn: in order to figure out if i should put an allocation into the interp/spesh/jit bucket, i'll investigate tc->cur_frame->spesh_cand(if unset -> interp)->jitcode(if unset -> spesh | if set -> jit)? | 18:52 | |
19:20
kjs__ joined
20:07
FROGGS joined
|
|||
timotimo | though, since profiling uses the spesh mechanism, doesn't that mean the spesh_cand is always set? | 20:24 | |
20:33
brrt joined
|
|||
brrt | \o | 20:33 | |
nobody broke JIT today, right? :-) | |||
TimToady | did it need breaking? :P | 20:36 | |
jnthn | timotimo: Why all the trouble? Just track in the profiler callgraph node object how the current routine was entered | 20:38 | |
[Coke] | brrt: I assume you're not talking to the OS X people. :) | ||
jnthn | timotimo: We already convey if we entered through interp, spesh, or JIT | 20:39 | |
I think that data is already stored in the call graph node data structure. | |||
timotimo | oh, cool | 20:43 | |
does that mean i don't even have to store three numbers in callgraph node objects | 20:44 | ||
except maybe in "collected" ones if we introduce the callgraph flattening again? | |||
the data is already in the json dump anyway? | |||
ah, not quite | 20:45 | ||
it seems like the PCN stores how often it was entered per type of entering | |||
so it'd still want three integers | |||
and the entry_mode member (that is persisted because continuations) is what i could just use to figure out where to +1 the allocation count | 20:46 | ||
jnthn | No, I think you'd need to store the numbers. | 20:50 | |
But yes, entry_mode is what you want. | |||
brrt | [Coke]: not especially today, no | 20:52 | |
TimToady: it didn't need it, but it might happen nevertheless :-) | |||
hmm does anybody know a more recent version of open-source darwin than 2011 | 20:53 | ||
jnthn: back from .cn? :-) | 20:56 | ||
jnthn | brrt: Aye :) | ||
I'm currently in Stockholm, midly jetlug, teaching TDD with...Java. :) | 20:57 | ||
The neat thing about Java is, there's so little syntax you basically can't get it wrong. | |||
japhb | Too bad you can't just teach people to do the Java tests in Perl 6 ... | 20:58 | |
jnthn | I did tell a (true) story about a recent project where I *did* write a test suite and prototype in Perl 6, then replaced the `is` sub with something that spat out JUnit tests to exercise the final impl which had to be in Java. They were like...wow, that's neat. :) | 20:59 | |
japhb | That is actually a very nice use of prototyping freedom | 21:01 | |
jnthn: Is that translation piece open sourceable? | 21:02 | ||
jnthn | No, and thanks to NDA I can't say any more about the project really :( | ||
japhb sees another shape of foot to stick in the door at hardcore Java shops. | |||
Ah well. NDA happens. | 21:03 | ||
jnthn | Only that I feel very comfortable saying that doing the prototype in Perl 6 first was a net win time (and thus cost) wise. | ||
japhb | Good! | 21:04 | |
Which reminds me, we haven't been in close enough time zones (or mental states) for a while to discuss this, but while working on the stress branch for perl6-bench it occurred to me that since r-j and r-m were *both* failing at divide-and-conquer, that implies something is wrong with concurrency either in the NQP threading primitives or in the Rakudo layers -- and *not* necessarily in the VMs themselves. Mind you, the two VMs crash in different ways, so it coul | 21:07 | ||
timotimo | cut off after "so it could"? | 21:08 | |
japhb | ... so it could be two different bugs in the NQP primitives instead of one bug in the Rakudo code ... or maybe they just have different failure behavior for essentially the same bug. | ||
I hate that irssi does not | |||
*show* you that the line got cut off. | |||
(Or better, just split the line for you.) | 21:09 | ||
brrt agrees with jnthns java-comment | |||
java is really very simple, it just has layers of people avoiding their problems in it | 21:10 | ||
japhb | Welcome to the waterbed theory of complexity. | ||
timotimo | there is a irssi plugin that splits for you | ||
weechat does it by default | |||
japhb can't imagine why the default behavior would be FAIL for an otherwise smart client | 21:11 | ||
jnthn | brrt: Yes, I did point that out to the folks I was teaching today, in a slightly different context. I was talking about the law of demeter, and pointing out that when your languages makes near enough everything look like a normal object, it's harder to see how to apply it... | ||
japhb: Well, from a Moar perspective, even if there are concurrency bugs at Rakudo level, SEGV is the wrong answer. | 21:12 | ||
japhb: I suspect we have bugs in both places. | |||
japhb | Yeah, agreed. | 21:13 | |
timotimo | we have bugs in all the places :) | 21:14 | |
i don't understand why, but my enthusiasm seems a bit limited this week | |||
[Coke] | timotimo: you and me both | ||
japhb | Everybody has down weeks. You need to accomplish something. And get more sun. :-) | ||
timotimo | i think i need a low-effort, big-payoff project :P | 21:15 | |
jnthn | Get more sun? I'M IN SWEDEN. | ||
japhb | Involving FREAKIN' LASERS | ||
timotimo | unfortunately, sun was swallowed by oracle | ||
ever since then, i didn't have the heart to look it in the eye | |||
jnthn | We greedily use up all our sun in the summer, and in winter there's noe left... | ||
japhb | jnthn: OK, so spend a lot of time under the aurorae? | ||
jnthn | Not in a north enough bit of Sweden for those :( | ||
japhb | Well geez, no way to win on that one. | 21:16 | |
jnthn | I know. | ||
brrt | japhb: my high school teacher called that the law of conservation of misery :-) | ||
japhb | Heh! | ||
jnthn | If I do get to see one at home, it'd probably mean we got a solar flare big enough to damage something or other :) | ||
At least the temperature is nice and cool here now :) | 21:17 | ||
brrt | dutchland is also cooling down (finally) | 21:25 | |
timotimo is looking at the code to walk the allocation nodes and is sad javascript doesn't have what perl6 has | 21:26 | ||
hypers and such | |||
i'm not really seeing how to correctly "enhance" the code here ... | 21:34 | ||
maybe i'll just count up the total directly in the "count" and then have numbers for spesh and jit that have to be subtracted, so to speak, to get the interp_allocation_count | |||
japhb | jnthn: If I could figure out stress tests for the NQP-layer threading primitives, would that be a big benefit, or just another data point that's unlikely to do much for you? | 21:38 | |
jnthn | japhb: I'm not sure it'd give me a lot more, tbh. | 21:39 | |
japhb | OK, fair enough. | ||
jnthn | japhb: Certainly I'd be lying if I said "big benefit". I can't say it wouldn't be one for somebody else coming into this. | 21:40 | |
japhb | Hmmm, that's an interesting point. | ||
jnthn | But I tend to have a clear enough mental map of the layers we have to have little trouble seeing my way through them. | ||
japhb | Yeah, I figured that might be the case. | ||
jnthn | So I'm a bad example in that sense. :) | ||
japhb | But that brings up the point that maybe the reason you're the only concurrency debugger is that no one else currently can wrap their heads around all the layers and their interactions. | 21:41 | |
So even if it wouldn't help you, maybe it will open up the debugging task to others. | 21:42 | ||
jnthn | Right. | ||
So "would that be a big benefit" may have a different answer to "will it do much for you". :) | 21:43 | ||
japhb | Heh. | ||
jnthn | (As in, if it opens it up to someone else, that's a big beneift...to everyone :)) | 21:44 | |
japhb | Truedat | ||
brrt | by the way, i removed MVM_exception_throw_adhoc in the JIT for MVM_panic | 21:48 | |
if something is wrong in the JIT, it shouldn't be caught by an exception handler | |||
jnthn | If there's no way to sanely reover, then yeah | ||
brrt | well... the sane recovery strategy is not to JIT | ||
japhb | Is there any NQP-level code (examples, tests, etc.) that uses the threading ops, or just Rakudo? | 21:49 | |
brrt | but any cases in which it would happen are clearly programmer errors | ||
jnthn | The downside is that panic assumes the VM state is corrupted and doesn't show a backtrace, iirc. | ||
japhb: Just Rakudo, sadly. | |||
brrt | as in JIT programmer errors :-) | ||
jnthn | japhb: nqp tests for them would be totally kosher. | ||
brrt | true, which is why i think i used throw_adhoc in the first place | ||
jnthn | japhb: Mostly they don't exist for historical reasons. | ||
japhb | jnthn: Wheee! I get to figure out how red blood cells work by dissecting a moose! | ||
;-) | 21:50 | ||
brrt doesn't get something, and that's probably OK | |||
jnthn | japhb: The reasons being that I did the original impl on the JVM in terms of Java interpo, in the Rakudo core setting. | ||
japhb: Then when I came to abstract it, I already had a bunch of tests at Rakudo level to guide me. | 21:51 | ||
japhb | nodnod | ||
jnthn | And given my usual...abundance...of time, that was Good Enough. | ||
japhb | Heh | ||
jnthn | <- still working on "done and gets stuff smart" :) | 21:52 | |
japhb | I still think you qualify on that count just based on your tendency to CDD that ends up being committed to mainline | 21:53 | |
brrt | i can hardly count the possible meaningful permutations of these words | ||
japhb | C == Conference | 21:54 | |
brrt | i was just about to ask | ||
:-) | |||
japhb | :-) | ||
brrt | done smart stuff and gets | 21:55 | |
and smart stuff gets done | |||
japhb | brrt: That one works really well for the second part of an aphorism | 21:56 | |
brrt | :-) what a monster of a sentence | 21:57 | |
22:02
kjs_ joined
|
|||
jnthn | Early sleep...still fighting jetlag, plus teaching tomorrow... | 22:05 | |
brrt | sleep well :-) | 22:10 | |
22:41
brrt left
23:13
kjs_ joined
|