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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!