00:06 jnap joined 00:31 jnap joined 01:26 FROGGS_ joined 03:15 FROGGS[mobile] joined 04:05 woolfy left
sergot morning o/ 06:10
06:30 vendethiel- joined, ggoebel111119 joined 06:33 japhb__ joined 06:34 daxim joined 06:39 brrt joined 06:55 klaas-janstol joined
brrt \o 07:30
FROGGS_ hi brrt 07:36
brrt hi FROGGS 07:37
POSIX calls are quite a bit more complex than win64 calls in the general case 07:38
FROGGS_ I had guesses it would be the other way around 07:40
brrt well.. yeah, i dunno 07:42
ok, the issue is this 07:47
FROGGS_ listens
brrt a): i have 6 general-purpose registers and 8 floating point registers in which to pass arguments in left-to-right order 07:48
b): all other arguments are passed in right-to-left order on the stack
i.e. leftmost argument on the stack is on the top, rightmost argument on the stack is on the bottom 07:49
07:51 brrt left, brrt joined
brrt floating point arguments are counted seperately from integer / pointer arguments 07:52
hmm... i already see how it is to be done 07:53
FROGGS aha, well, I see how this can be confusing easily 07:54
brrt basically, the parameters have to be pre-allocated 08:01
i.e. go over the arguments in two passes, one to allocate them over GPR, FPR, stack, and one to emit code to store them there 08:02
hmm, i can simplify the logic by moving all arguments into a temporary register first and moving them into their proper position afterwards 08:46
but that is costly at run-time
FROGGS[mobile] if it is not much work you could at least check that way that this solves the issue 08:57
09:27 donaldh joined 09:28 brrt joined
dalek arVM: 65958f4 | jnthn++ | VERSION:
Bump VERSION.
 09:50
09:51 tgt joined
FROGGS[mobile] nice, then I can do the release when I'm home :o) 09:52
jnthn Yeah 09:53
I got $uk_friend visiting from this evening, so want to get this done first :) 09:54
FROGGS[mobile] sure :o) 10:00
dalek href="https://moarvm.org:">moarvm.org: fc04e47 | jnthn++ | / (3 files):
Update site for 2014.07 release.
jnthn I hope this will be the last MoarVM release... 10:01
...without JIT.
:)
FROGGS[mobile] *g* 10:04
10:05 cognominal joined
FROGGS[mobile] the planned features and their dates read nicely (as always) 10:05
jnthn Yeah. I missed getting as many async improvements as I wanted into this release...but have a YAPC::EU talk about it in August which will be a good reason for a puch on it in this one :) 10:06
Uh, push :)
The things taht did make it in were fixes to make what was already there more usable, though... 10:07
FROGGS[mobile] and you are going to discuss NFG at the APW hackathon? 10:09
dalek MoarVM/moar-jit: 0c127ce | (Bart Wiegmans)++ | / (5 files): 10:10
MoarVM/moar-jit: Fix POSIX argument passing.
MoarVM/moar-jit:
MoarVM/moar-jit: POSIX AMD64 argument passing may be weird, but it's understandable.
MoarVM/moar-jit: Arguments are divided per class. The first 6 integer or pointer
MoarVM/moar-jit: arguments are passed in general-purpose registers, the first 8
MoarVM/moar-jit: floating point arguments are passed in SSE registers, and any
MoarVM/moar-jit: further arguments are passed on the stack in right-to-left order.
MoarVM/moar-jit:
MoarVM/moar-jit: Win64 on the other hand specifies that the first four arguments
MoarVM/moar-jit: are always passed in registers - either GPR or SSE - and all others
MoarVM/moar-jit: on stack, so far as I can tell in left-to-right order. Thus, if it
MoarVM/moar-jit: happens that the second argument of any function is a floating-point
MoarVM/moar-jit: argument, on POSIX it is passed in %xmm0, and on Win64 it is passed
jnthn brrt++ 10:11
brrt next release will be a month from now, no?
jnthn Right :)
brrt should be doable
jnthn The day before YAPC::EU, as it happens :)
brrt o rly
ok, then it /would/ be cool if we had JIT
FROGGS[mobile] would be nice to merge it as sondern nothing breaks 10:12
brrt i try to keep nothing breaking in the meantime :-)
FROGGS[mobile] soon*
damn auto collect! 10:13
jnthn hah
Yeah, I hate it when my auto cat rectal does stupid stuff...
brrt: Does the above mean that things now pass? 10:14
FROGGS[mobile] brrt: I can also do module smoke tests on your branch when you think you are ready
brrt nqp testsuite passes, yes
jnthn yay
FROGGS[mobile] *g*
brrt i'll check rakudo sanity tests, too
jnthn :)
So...what's next? :)
FROGGS[mobile] the world \o/
brrt i suppose pouring a cold one, but it's still early for that
ehm... i want to do exceptions, i suspect they'll be challenging 10:15
or at least, jumpy
jnthn Hmm
Yeah
brrt how are exceptions dealt with, anyway
jnthn The other options are OSR and extops...
brrt extops is conceptually simple, but would require some testing 10:16
timotimo OSR would give us good benchmark numbers real soon :P
brrt aw.. rakudo doesn't build
timotimo except ... extops are important, too
for the rakudo piece of the benchmarks, i mean 10:17
brrt damn, JIT bug again
timotimo aaw
oh well
brrt (JIT does take quite a byte out of stage parse, fwiw)
or is that a bite 10:18
jnthn ooh
How much % wise, ooc?
brrt i don't know; last good build i had was about 14s, without JIT i'm at 37s 10:19
so that seems a doubling
timotimo o_O
that's excellent!
brrt except! that i now have a JIT bug
i'll check it out w/o invokish operators
jnthn Whoa :) 10:20
I almost want to go try that but I should really do $dayjob
Oh, I can kick off a build in the background...
brrt well, there's a bug, so be warned
jnthn :) 10:21
We can see if we hit the same bug :)
brrt would be very frustrated if this was a call arg bug again
hmm now i get 36s with JIT enabled 10:22
must've mismeasured
jnthn oh...
brrt :-( 10:23
shame
without if_o and unless_o, btw
do you get a bug?
jnthn aww 10:24
Actually I can't build latest Rakudo on moar-jit
oh wait
brrt :'-( 10:25
jnthn hadn't got latset
brrt ok, why doesn't rakudo build? 10:27
jnthn I get instant SEGV, it seems :(
C:\consulting\MoarVM\install\bin\nqp-m.bat --target=mbc --output=blib/Perl6/ModuleLoader.moarvm --encoding=utf8 src/gen/m-ModuleLoader.nqp
NMAKE : fatal error U1077: 'C:\consulting\MoarVM\install\bin\nqp-m.bat' : return code '0xc0000005'
Same with NQP 10:28
brrt o rly 10:29
i don't get segfaults, in fact
this stuff... is hard, it seems 10:30
jnthn Well, yes. JIT compiler is not generally set as a beginners task... :) 10:31
brrt :-p 10:32
i'll get there
at the very least, my gdb skills are improving 10:34
brrt will be back in a few hours
jnthn o/ 10:35
timotimo i wonder how much the jit will actually impact stage parse, even when we're still pushing all our data back to ram after every operation
brrt i dunno, but there is quite a large number of frames that do get compiled 10:36
timotimo and then it'll be interesting to see what it'll look like when we have proper register allocation strategies
brrt ... we might not have these this summer, yet
timotimo i suppose that's all right
jnthn Getting rid of interpreter overhead and being nice to the branch predictor and removing a bunch of indirections is already going to help a lot 10:38
On stage parse, it spends a bunch of its time in grammars and actions.
timotimo well, we're getting parts of the indirection removal in the regular spesh'd bytecode, too
brrt :-) afk 10:39
jnthn Yes, some. Not all.
10:39 brrt left
timotimo hm, there was something else you suggested (and i wanted to do) to spesh something into a simpler operation 10:40
was that boolification?
jnthn maybe 10:41
I mean, there is work that's worth doing on boolification and spesh
timotimo can we actually turn these boolification modes into a single instruction? 10:43
unbox int/num/str_not_empty/str_not_empty_or_zero sounds like it'd want an extra register
unless the result of unboxing int or num can be any number that's not zero for it to mean true 10:44
jnthn Yeah, they'll want an extra register
*but* 10:45
istrue and isfalse don't
uh
for sokme cases
like the isconcrete one
10:46 carlin joined
timotimo yeih, i thought the mode_not_type_object would be simple to do 10:46
how often does that come up?
jnthn It's the default boolification mode for many objects, I think 10:48
timotimo that sounds useful. but i'll be AFK for a bit first
11:57 carlin joined
timotimo jnthn: can a bool mode unbox int just be turned into a get_i and have that result pretend to be a bool? 12:08
jnthn Well, an unbox_i 12:11
Which we may then in turn be able to further optimize
timotimo er, yes 12:12
jnthn I'd make it an unbox_i and then delegate to the thing that knows how to optimize unbox_i to do the rest
timotimo aye.
i haz cheezkake \o/
and i suppose a boolify call method case can be turned into an actual method call, which can then, in turn, be spesh'd as well, right? 12:14
oh, actually, what spesh does with methods doesn't apply here, as the method is supplied as a MVMObject* which is probably a callable directly, eh?
12:15 jnap joined
timotimo jnthn: is there a single op i can emit instead of the istrue in the invoke_method case? 12:36
or does that require more than one op and thus also more registers? 12:37
jnthn Multiple ops 12:38
It's a bit tricky
Though ultimately worth it
Since we might be able to inline
timotimo during the nqp build i see extremely few instances where i use the boolification spec, but so far i only do int, num and isconcrete, and only for istrue 12:45
does "multiple ops" also mean "including the allocation of extra registers"?
i don't think i can spesh if_o without creating new registers yet 12:46
(as in, that'd turn into istrue + if_i and then i could spesh that again)
t/spec/S17-lowlevel/lock.rakudo.moar .......................... Failed 1/8 subtests 12:51
can that be my fault?
jnthn Unlikely. 12:54
timotimo i suppose using an up-to-date rakudo should help :) 12:55
dalek arVM: 1869baf | (Timo Paulssen)++ | src/spesh/optimize.c:
istrue: some boolification specs can be spesh'd (twice!)
 13:04
timotimo the spectest fails go away when i run the tests in isolation
which is annoying
but it'd appear my changes are all right
jnthn MVM_BOOL_MODE_UNBOX_NUM 13:07
um...
That one looks rather dubious. Putting a num into an int register?
timotimo oh!
yeah, that *is* dubious
jnthn But the others look fine
On negated, you can handled them by inserting a not_i
dalek arVM: c6282c6 | (Timo Paulssen)++ | src/spesh/optimize.c:
remove dubious unbox_n that'd put a num into an int register
 13:08
timotimo can i just overwrite that register?
jnthn not_i reg, reg
Yeah, should work OK
timotimo will do
jnthn It's a little naughty in terms of the SSA stuff
timotimo that's what i thought :) 13:09
should i insert that before running the next optimization or afterwards?
a part of me thinks it ought to not matter
jnthn Shouldn't matter 13:12
timotimo new_operands[0] = ins->operands[0]; new_operands[1] = ins->operands[0] ought to work, right? 13:18
ah, lots of isfalse get optimized 13:20
many more than istrue
(at least during the nqp build) 13:21
jnthn right 13:22
dalek arVM: 40120f0 | (Timo Paulssen)++ | src/spesh/optimize.c:
can now handle isfalse, too. (a bit naughty, though)
timotimo hopefully correct 13:23
rakudo build is still successfull
i do declare, spesh is pretty nice. though i'm having a hard time thinking of a way to make register "allocation" possible without some heavy duty SSA manipulation that might end up causing trouble in between things ... 13:25
though as long as we're not relying on the SSA to be "coherent" during optimize_bb and perhaps make sure the bb-boundaries are properly fixed, that could work perhaps
jnthn You need to know the deopt points as much as the BBs 13:26
timotimo ah, yes
13:27 carlin joined 13:28 jimmyz joined
timotimo oh, a bunch of spectest fails, eh? 13:28
that's not so nice
jimmyz hello, I still can't build rakudo on moarvm ..
jnthn That means you did it wrong
timotimo haha, it's because i left a debug printf in there 13:29
jnthn Oh :)
timotimo not ok 4 - providing command line arguments sets @*ARGS
# got out: "1, 2, foobuilt an isfalse\n"
# expected out: "1, 2, foo"
jnthn hah
jimmyz: Oh? I've not heard anybody else having trouble... What environment?
And how does it fail? 13:30
Does NQP build?
jimmyz rakudo build
jnthn: gist.github.com/zhuomingliang/5c8d...a39d2ba5cf
on ubuntu 14.04 64bit destkop 13:31
timotimo i've seen deserialize_stable pop up a few times
hey, have you reconfigured?
i recently changed the size of some struct in there
jimmyz yes, all do `git clean -xdf`
jnthn: NQP builds fine 13:34
13:47 brrt joined
brrt \o 13:47
the broken frame, it appears, is rather large
13:48 btyler joined
jnthn Well, on the upside, we JITted a large frame? :) 13:48
brrt very large 13:51
the downside is that i don't have any idea where we're broken
hmm 13:52
repr_at_key_o is where we're crashing
that's weird
hmm, quite a few atkey_o's 14:00
14:03 itz__ joined
brrt and thus began the slow decoding of the broken frame 14:07
wait, i know how to figure out where i'm at 14:11
subtract the entry point from the current position on stack 14:15
tada
doesn't tell me what happened before it, though 14:18
so it may be less-than useful
brrt brb 14:22
14:49 brrt joined 14:53 cognominal__ joined
brrt what's coloncircumfix 14:53
jnthn A grammar rule iirc
It exists to worry if you write :foo<> and otherwise parse a circumfix. 14:54
brrt right 14:55
jnthn Why'd you ask? Is it involved in a crash somehow? 14:56
14:56 jnap joined
brrt it's the attribute that is requested of the object in atkey_o 14:56
jnthn Oh 14:58
So you're in an action method somewhere.
Or in routine_def maybe :) 14:59
brrt probably, this is stage parse after all
jnthn parse runs the action methods too 15:00
brrt (microsoft laying of 18.000 employees. wow :-o)
off
moritz let me get this straight; coloncircumfix is the value inside an attribute, not the name of the attribute. Correct? 15:01
jnthn Yeah. That's a lot.
brrt in my case it's the name that is looked up upon an object 15:02
and i kind of need to know why it crashes
jnthn Well, it's a hash lookup, if it's atkey_o
brrt is what i mean 15:03
:-)
brrt has a fried brain in here
jnthn Most things taste better after frying.
brrt they rarely work better, though 15:04
jnthn This is true.
15:18 tgt joined
brrt thinks that it's likely the nqp optimizer can remove quite a few sets 15:20
timotimo how would the nqp optimizer remove sets? it doesn't work at the bytecode level after all ... 16:04
16:22 btyler joined
FROGGS ewww 16:41
t/spec/S32-io/IO-Socket-Async.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 5
that test is flapping
16:47 carlin joined
timotimo yes :( 16:59
nwc10 brrt: ASAN thinks that your jit branch is most boring. Which is good. 18:21
20:43 jnap left 20:45 brrt joined
brrt nwc10: good to hear 20:49
but i'm still having trouble building rakudo
[Coke] brrt++, btw.
brrt thanks :-)
but bugs!
my current expectation is something of getlex (maybe vivify) or decont 20:51
but, i don't know which, and i still don't know how to testcase decont
anyway, i'll look at it tomorrow :-) 20:52
brrt afk
20:52 brrt left 22:35 lizmat joined 22:53 itz__ joined, ingy joined, sergot joined, betterworld joined, retupmoca joined, lizmat joined, cognominal__ joined, woosley joined 22:56 bcode joined 22:57 lee_ joined, rurban joined, colomon joined, ren1us joined, woosley joined, cognominal__ joined, lizmat joined, retupmoca joined, betterworld joined, sergot joined, ingy joined, itz__ joined, carlin joined, japhb__ joined, ggoebel111119 joined, FROGGS joined, odc joined, brother joined, TimToady joined, ashleydev joined, timotimo joined, tokuhirom joined, harrow joined, cxreg joined, camelia joined, flussence joined, moritz joined, japhb_ joined, hoelzro joined, jnthn joined, xiaomiao joined, krunen joined, nwc10 joined, diakopter joined, masak joined, BinGOs joined, nebuchadnezzar joined, ChanServ joined, avar joined, dalek joined, bcode joined 22:58 bcode_ joined 23:05 woolfy joined 23:20 woolfy joined 23:25 woolfy 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!