Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-17

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

All times shown according to UTC.

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

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