Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-08

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

All times shown according to UTC.

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

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