01:45
FROGGS_ joined
04:07
lue joined
|
|||
sergot | o/ | 06:13 | |
06:40
teodozjan joined
|
|||
FROGGS_ | colomon_ / moritz: the smoker has problems: host07.perl6.com:8080/report | 06:45 | |
and I really guess it is the smoker, not perl6/moarvm | 06:46 | ||
ohh, ww | |||
07:30
FROGGS_ joined
08:25
brrt joined
|
|||
nwc10 | jnthn: you seem to have fixed the ASAN upset for t/spec/S32-list/roll.t but I can't work out how | 09:07 | |
jnthn | Hmm... | 09:12 | |
Or is it just hidden by something else... | |||
(like, a Rakudo change) | |||
nwc10 | I don't know. And I don't know a good way to work out | ||
work it out | |||
lizmat | jnthn: would be suprised if it were a rakudo change, as not much changed there afaik | 09:13 | |
jnthn | lizmat: Quite a few optimizer patches. | 09:14 | |
lizmat | ah, ok.. right | ||
fitness& | |||
jnthn | brrt: Invocation-related things coming up today? :) | 09:22 | |
brrt | related, yes | 09:23 | |
i'm working on refactoring the graph building code so we can consume multiple spesh instructions into a single node | |||
for that, i'm containing the current speshgraph, speshbb, speshins, in a struct, so that i can 'skip ahead' as it were | 09:24 | ||
so hopefully later today i'll get the 'single invocation node' worked out and constructed | 09:26 | ||
jnthn | Will we have other places where the multiple -> single thing is useful? | 09:29 | |
brrt | i suppose so, yes | ||
put another way, not joining the invocation nodes together is really annoying | 09:30 | ||
09:31
kkul joined
|
|||
brrt | and i'd probably need to do this anyway if i wanted to do the temporary interpreter variable magic | 09:32 | |
jnthn | ok | ||
Just wanted to check we weren't building an abstraction to use it once. :) | 09:33 | ||
brrt | it's a good idea, i took it from you :-) | ||
hmm.. i think you can compare it with the codegen structures in spesh? | |||
fair point :-) | |||
jnthn | codegen.c works an instruction at a time really... | 09:34 | |
brrt | ok, but it does create a special-purpose 'builder' structure, which is what i mean | 09:35 | |
jnthn | Ah, yes, true. | 09:36 | |
brrt | i'm having the weirdest bug possible | 10:11 | |
jnthn | Congrats. | 10:13 | |
Want to see if explaining it to somebody else makes it less weird? :) | 10:14 | ||
brrt | i'll try.... | ||
basically | |||
i forgot to allocate labels in my refactored version, so the JIT graph builder predicatbly throwed an exception | |||
ok, no problem | |||
i allocate them (using spesh alloc, /exactly as before/, and lo and behold | 10:15 | ||
segfault, in an area removed from the code | |||
jnthn | diff? | 10:16 | |
brrt | rather large, unfortunately | 10:17 | |
gist.github.com/bdw/5eb866631c6fc6f1a075 | 10:19 | ||
i'll see if i can find the relevant bits | |||
gist.github.com/bdw/5eb866631c6fc6...-diff-L328 is what causes crashing | 10:22 | ||
jnthn | Did you try it under valgrind or asan btw? | 10:23 | |
brrt | not yet | 10:25 | |
:-) | |||
jnthn | JitGraphBuilder jgb; | ||
Note that this is stack allocated | |||
And will contain junk at the start | 10:26 | ||
brrt | yes, that is intentional | ||
oh, that is not intentional | |||
good point | |||
valgrind .. dies with sigsegv | 10:30 | ||
jnthn | wtf... | 10:41 | |
brrt | yes | 10:42 | |
no warnings, by the way | |||
hmmm | 10:45 | ||
ok, i'm suspicious of how gcc compiles get_label_name | 10:48 | ||
i'm even more suspicious of the result of calling get_label_name | 10:49 | ||
i..e in the part that actually assigns the label, the i is actually optimized out | 10:50 | ||
and under gdb, nothing happens | 10:51 | ||
10:51
cognominal joined
|
|||
brrt | i.e., the array of labels isn't even touched at all | 10:53 | |
hmmmm.... | 10:54 | ||
build cleanup cleans it up | 10:55 | ||
jnthn | hmmm...so missing dependency? | 10:57 | |
brrt | unlikely | 11:02 | |
but anyway | |||
:-) | |||
weird | |||
heisenbug is what it's called, right? | |||
jnthn | Something like... | 11:03 | |
brrt | i did end up initializing the whole builder structure, maybe that did it, too | 11:07 | |
dalek | arVM/moar-jit: a0fc795 | (Bart Wiegmans)++ | src/ (7 files): Refactor JIT graph building I refactored the JIT graph building to use a 'JitGraphBuilder' structure. In this way, the graph builder can 'consume' more than one spesh instruction at a time, which is very useful for many reasons. One of these reasons is that it allows us to build a single 'master invoke node'. |
11:09 | |
brrt | minor pain point: can i assume the MVMReturnType enum is an int (4 byte) large, or should i really build a switch for that? | 11:15 | |
bbiab | 11:21 | ||
jnthn | brrt: I don't think you can portably rely on it | 11:31 | |
11:59
jnap joined
|
|||
dalek | arVM: bd0fa75 | Carlin++ | Configure.pl: [Configure] make --no-optimize and --no-debug work These options are mentioned in the --help output but do not work |
12:02 | |
arVM: 0225dc5 | (Tobias Leich)++ | Configure.pl: Merge pull request #109 from carbin/no-moar [Configure] make --no-optimize and --no-debug work |
|||
12:09
teodozjan joined
12:41
carlin joined
|
|||
nwc10 | jnthn: commit 569173f87cb45dccc9d26a72d0239a66b6c4e290 in the specs hides the ASAN | 12:48 | |
Sun Jul 6 12:15:09 2014 -0700 | |||
added Test::Util::run(). Utilized in S32-list/roll.t | |||
hides the ASAN barf | |||
13:55
tadzik joined
14:06
brrt joined
14:16
btyler joined
14:40
FROGGS joined
|
|||
brrt | i'm kind of frustrated with the value type situation | 15:04 | |
i.e. i don't want to end up with 15 different ways to say 'this is an int, a num, a string, or an object, or a local register, or the address of a local register, or an interpreter value, or... etc etc' | 15:05 | ||
jnthn | brrt: What's causing there to be so many ways? | 15:09 | |
brrt | they are used differently in different parts of the system, basically as many as there are ways to use pointers in C | 15:10 | |
to give an example | |||
a return value may be a pointer to a value, it may be a float value, it may be an integer value, or - sometimes - it may be a pointer where we should store something | 15:11 | ||
on the other hand, c call args may be addresses of registers, interpreter variables, literal values, literal floating point values, local floating point variables, local integer / pointer variables, etc | 15:12 | ||
not... *quite* the same thing, but there is a lot of overlap | 15:13 | ||
jnthn | Well, if certain things are invalid in a given context, you can always just say so if they're ever used that way... | 15:16 | |
brrt | that is true | 15:19 | |
and i don't actually think the invalid type bug happens that much - or i'd be scared of using C, like the rest of the internet | 15:20 | ||
some value types would need a size, and others would not | 15:21 | ||
i've wanted for a long time to make a unified value type, but can't seem to find the right one, and in most cases i just don't do anything and let MVMSpeshOperand handle it | 15:46 | ||
which is almost-but-not-quite enough :-) | 15:47 | ||
jnthn | MVMSpeshOperand is meant to have a direct correspondence to the kinds of things interp.c has to care about, or that show up in the bytecode format, which is almost but not quite enough for the JIT. | 15:49 | |
It's probably better to deconfuse to two, imho | 15:50 | ||
brrt | i agree | ||
but that takes me into the terroritory of either one big tagged union type for all, or 16 different union types for all specific cases | 15:51 | ||
jnthn | Well, if the 16 would mostly overlap, though... | 15:53 | |
15:55
raiph joined
|
|||
brrt | i think i'll get to it when invoke is working | 15:56 | |
jnthn | *nod* | 15:57 | |
Having code that exhibits the need to refactor makes the refactor clearer. :) | 15:58 | ||
brrt | *nod back* | 16:08 | |
as far as JIT complexity goes, invoke_ and fastinvoke aren't that different | 16:10 | ||
one has an extra callout, but it seems like that's it | |||
jnthn | Yeah | 16:14 | |
fastinvoke saves some work | 16:15 | ||
brrt | floating points support modulas? | 16:22 | |
brrt has to check that out | |||
floating point arithmetic does not (natively) support modula | 16:24 | ||
i think it does support floor, though | 16:27 | ||
jnthn | Can always disassemble interp.c to see what mod_n is compiling into :) | 16:28 | |
rurban | well, mod_n is a bit too tricky for that | 16:34 | |
jnthn | I'm sure the disassembler with cope... :P | 16:35 | |
brrt | i'm afraid of disassembling interp.c | ||
because of teh huge | |||
jnthn | Well, or just put what it does for mod_n into a C file :) | ||
But if it's non-trivial, then the usual "shove it in a function" applies | |||
brrt | the best solution is that x87 supports some kind of 'floor', and i can then basically perform the magic that mod_n does | 16:36 | |
rurban | see e.g. for the mod problems: github.com/parrot/parrot/blob/mast...h.ops#L473 | 16:37 | |
I see, you are using the same. | 16:38 | ||
jnthn | brrt: Yeha, though I suspect it's quite a rare operation, so it doesn't need to be too near the top of the todo list :) | 16:39 | |
rurban | I profiled this mod algo to be a major bottleneck in parrot | 16:40 | |
brrt | nqp has a kind of 'num bias' | ||
oh really? | |||
rurban | there should be a check>0 branch, I guess and use native % then | 16:41 | |
brrt | i'm off for dinner now, will see to this later | ||
(i actually noticed because of nqp forcing it on me :-)) | 16:42 | ||
16:42
brrt left
|
|||
rurban | on my benchmark suite it's the 2nd most function: 5.45% [.] Parrot_util_intval_mod | 16:42 | |
perf record ../do-bench.sh; perf report | |||
and perf report conveniently disassembles it for you. no need to grep through the objdump | 16:43 | ||
and it shows you the profiling info. hotspots, cache affecting jumps, red/green | 16:45 | ||
18:19
teodozjan joined
19:34
cognominal joined
20:14
japhb joined
20:16
brrt joined
|
|||
brrt | \o #moarvm | 20:17 | |
jnthn | o/ brrt | ||
brrt is wondering what was troubling him before he left this evening | |||
jnthn | Whether Germany could beat Brazil? But don't worry, they're 1-0 up, so you can hack JIT. ;) | 20:18 | |
brrt | what? 1-0 for germany? | ||
jnthn | Yes! | ||
o.O | |||
brrt | wow. yes, JIT :-) | 20:19 | |
oh, i renember, the distraction of mod_n | 20:21 | ||
jnthn | aye | ||
I wondered how you got into that distraction :) | |||
brrt | well, i've written a little test for invoke | 20:23 | |
and it contained a modulus, because i knew i had implemented modules for integers (and had assumed, by the way, that modulus for floating points was bs) | 20:24 | ||
it seems x86 agrees with me, and moar doesn't, and nqp thinks for some reason it ought to compile my integer mod to floating point mod | |||
nwc10 | no longer 1-0, it seems | 20:25 | |
brrt | o.O | 20:26 | |
jnthn | 3-0!! | ||
wtf is happening! | |||
4. | 20:28 | ||
brrt: You can write nqp::mod_i(...) to force integer modulo, fwiw. | |||
brrt | it's not important :-) also, i should study up on x86 floating points anyway | 20:29 | |
i can always write another type of routine, it's just invocation i'm after | 20:32 | ||
FROGGS | sorry that I'm not very active here atm :o) | 20:50 | |
that's a very good game, and I don't even like soccer | |||
jnthn | Unbelievable. | 20:51 | |
hoelzro | I've been popping into our break room every few minutes | ||
the first time I had no knowledge of the score, and I saw it was 4-0 | |||
and then #5 happened. | |||
wow. | |||
FROGGS | and again I wish I had beer :P | 20:52 | |
brrt | yes, much amaze | 20:53 | |
FROGGS | such goals! | ||
brrt | can MVM_frame_find_invokee_multi_ok invoke? i.e. can it run the moarvm interpreter? | 21:21 | |
jnthn | No. | ||
brrt | /phew/ | ||
jnthn | It *can* fiddle with the callsite/args, but by that point it's all set up. | 21:22 | |
And that case is rare. | |||
brrt | i don't care as long as it can do it by itself | 21:23 | |
:-) | |||
although, if i have to pass a pointer to the callsite, that is slightly more difficult as it implies i must first put it on the stack | |||
jnthn | code = MVM_frame_find_invokee_multi_ok(tc, code, &cur_callsite, args); | 21:26 | |
yeah, it wants a pointer | |||
That's so it can tweak it if needed | |||
brrt | ok, good to know | 21:30 | |
should i move prepargs to core/compunit.c or to core/frame.c? | 21:31 | ||
jnthn | args.c ? :) | ||
brrt | works for me :-) | 21:32 | |
jnthn | heh, 7-1 | 21:49 | |
Go Germany. | |||
brrt | unbelievable | 21:52 | |
brrt now wondes if the dutch will lose from germany or from brasil next match | |||
hoelzro | well, at least Brazil got 1 | 21:56 | |
FROGGS | true | ||
hoelzro | I'm hoping the Dutch win tomorrow | ||
we'll see how they fare against DE then... | |||
brrt | that would be an exciting match | ||
ok, i'm going to take the liberty to add a small wrapper arround MVM_frame_invoke | 21:57 | ||
because the alternative is much pointer fiddling, and i don't feel like that | |||
jnthn | OK | 22:04 | |
brrt | is callsite_idx the right value for the ... args buffer index in the arg_* ops? | 22:15 | |
jnthn | No | 22:16 | |
It's just an int16 saying what slot in ->args to populate | |||
->args just being an area within ->work, fwiw. | 22:17 | ||
callsite_idx is taken by prepargs | |||
dalek | arVM/moar-jit: 5071857 | (Bart Wiegmans)++ | src/ (9 files): Added invoke graph building This creates a single 'giant invoke node' that contains all that is needed to invoke a routine. |
22:19 | |
arVM/moar-jit: 8a64bdf | (Bart Wiegmans)++ | / (5 files): Take callsite preparation out of interp.c |
|||
MoarVM/moar-jit: bad7c37 | (Bart Wiegmans)++ | src/core/frame. (2 files): | |||
MoarVM/moar-jit: Add a small wrapper arround MVM_frame_invoke | |||
MoarVM/moar-jit: | |||
brrt | i think that's what i mean, yes | ||
timotimo | is something missing? | ||
brrt | yes, something is missing, that happens frequently | 22:20 | |
:-) | |||
(i've just heard i have an 8 out of 10 for my thesis. i'm done with my bachelor, officially, now :-o) | |||
brrt afk, see you tomorrow | 22:21 | ||
timotimo | well, congrats on the good score :) | 22:22 | |
jnthn | brrt: Congrats on the bachelor \o/ | 22:24 | |
And goonight :) | |||
uh, goodnight | |||
FROGGS | brrt++ | 22:27 | |
22:32
jnap1 joined
|