Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-08

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

All times shown according to UTC.

Time Nick Message
02:06 vendethiel joined #moarvm
03:33 vendethiel joined #moarvm
04:21 vendethiel joined #moarvm
05:34 vendethiel joined #moarvm
06:30 FROGGS joined #moarvm
07:37 rurban joined #moarvm
08:32 FROGGS joined #moarvm
10:55 dalek MoarVM/even-moar-jit: 79a2473 | brrt++ | / (4 files):
10:55 dalek MoarVM/even-moar-jit: Use S-expressions throughout the exprlist
10:55 dalek MoarVM/even-moar-jit:
10:55 dalek MoarVM/even-moar-jit: This makes parsing much simpler and reliable, as we no longer need
10:55 dalek MoarVM/even-moar-jit: to handle the special case of macro definition, and the appearance of
10:55 dalek MoarVM/even-moar-jit: declarations within s-expressions.
10:55 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/79a2473be8
12:12 brrt joined #moarvm
12:15 brrt 'o
12:27 lizmat brrt o/
12:28 brrt \o lizmat
12:28 lizmat it's been quiet here... I guess jnthn is fighting red tape in Kyiv
12:28 brrt back in the nl again? :-)
12:28 lizmat yeah, for a while already  :-)
12:28 lizmat about to leave again
12:28 brrt alright. where to?
12:28 lizmat Portland OR
12:28 brrt what to find?
12:29 lizmat a good time + OSCON
12:29 brrt oh, nice :-)
12:30 * brrt supposes that this is different from oscon.no a few months back
12:32 brrt i have reasonably good news to report, though, i think i know how to make (a simplistic) code generator
12:32 brrt as well as common subexpression elimination
12:33 brrt i'm not yet very sure on how to make the real code generation; but i note that it has become much simpler to think about such algorithms (for me at least)
12:35 lizmat in Norway, it was the OSDC.no
12:36 brrt fair enough :-)
12:36 nwc10 lizmat: on a non-stop flight to PDX?
12:36 brrt will you be speaking on any of these conferences?
12:39 lizmat non-stop indeed, yss
12:39 lizmat no, just attending
12:39 lizmat speaking on the Hallway++ track of course  :-)
12:42 brrt :-) still pretty nice
12:42 * brrt is getting nervous about his yapc::eu talk
12:42 brrt slowly
12:45 lizmat getting nervous is good, but *after* you prepared it  :-)
12:46 brrt i guess... :-)
12:46 brrt hmm
12:46 brrt what kind of jit-type things would you find interesting?
12:46 brrt if i focus on what i find interesting, i'm afraid of boring my audience to sleep
12:48 lizmat To be honest, I'm interested in JIT for its results
12:49 lizmat so I would show typical results
12:49 lizmat how much faster, less memory, less CPU, etc
12:50 brrt hmmm..... that's a complicated story
12:50 lizmat yeah, I know
12:50 brrt in fact, JIT is pretty much certain to use more memory :-)
12:50 lizmat for the YAPC::EU I would probably not go too deep into the specifics of how it works
12:51 lizmat I think that would be more appropriate at a more general CS / compiler development conference
12:51 brrt hmm. ok, right.
12:51 lizmat which you should also do, btw!
12:51 brrt jnthn++ always keeps his presentations very understandable-yet-in-depth
12:52 brrt :-)
12:52 brrt i guess my blog is typically very much in depth
12:54 brrt have fun in oregon, btw :-)
12:55 lizmat thank you!
12:55 timotimo o/
12:58 brrt \o timotimo
12:59 lizmat timotimo o\
12:59 leedo joined #moarvm
12:59 colomon joined #moarvm
13:00 brrt oh man, netsplits
13:01 BinGOs joined #moarvm
13:01 timotimo joined #moarvm
13:01 brrt timotimo.. i've a question for you
13:01 timotimo oh?
13:01 timotimo go ahead
13:02 brrt would you be able to think up a clever way to extract the call-nodes from src/jit/graph.c and convert 'm to exprlist call nodes
13:02 timotimo the call nodes, you mean the ones that we build for calling C functions?
13:03 brrt yes
13:03 brrt those
13:03 timotimo well, we've already discussed that we'd like to generate them from a data-driven format rather than from code
13:03 brrt considering, fwiw, that exprlist call nodes have the format (call $pointer (arglist) type)
13:03 brrt damn, that's wrong
13:04 brrt waitaminute, let me think about that for a bit
13:04 brrt hmmm
13:04 brrt no, that's right
13:04 brrt but what's wrong is my implementation of it
13:04 brrt yes. and the exprlist format, i think, can do this
13:05 brrt the difference is that rather than using (&funcptr function_name) i need (const (&funcptr function_name) ptr_sz)
13:05 brrt which is kind-of a pain, but it can be macro'd
13:05 timotimo you mean we should go from our current implementation directly to using exprlist?
13:06 brrt yes
13:07 timotimo we can probably then throw out the old code for handling c function call nodes and use the exprlist code generator for all cases?
13:11 brrt not today
13:11 brrt but eventually, hopefully, yes
13:12 timotimo can the exprlist parser be sufficiently easily re-used to be used for what we currently have the hard-coded code for?
13:13 brrt for most cases, yes
13:13 brrt not all
13:14 brrt most cases we fill in a pre-existing call argument list
13:14 brrt with a fixed function pointer
13:14 brrt in the cases where we can't, we'd need to implement some hand-coded expression tree generation
13:15 brrt for example in getlex/bindlex
13:16 timotimo mhm
13:16 timotimo sometimes we interpret literals from the bytecode and make decisions based on that
13:16 timotimo does the exprlist thing also do a tiny bit of constant folding for such cases?
13:16 timotimo i have no concrete example right now
13:17 * timotimo opens code
13:17 brrt no, nothing of the kind
13:17 brrt just, and only, template filling, and i aim to keep it that way
13:18 brrt i do allow the insertion of c-macros in the template
13:18 timotimo oh, do you have an idea for how devirtualization may be implemented in the new code generator?
13:18 timotimo devirtualization of reprops, that is
13:19 brrt notyet
13:20 brrt i'll come to that soon enough
13:20 brrt similarily, i presume, just with (hand-written) templates
13:20 timotimo mhm
13:27 brrt one thing at a time :-)
13:27 brrt actually, that's directed to myself with more vigour than to you
13:30 timotimo i just point it out because i'm going through the graph.c code right now ;)
13:33 brrt fair enough
13:34 brrt i can imagine we also have templates not just by opcode but by name as well
13:34 brrt hmm
13:34 brrt actually, that one is simpler than it looks
13:35 brrt during tree traversal, just insert a const node for the known repr op function
13:36 brrt replace the reference to the loading-the-repr-func tree with the refernce to the const node
13:36 brrt done
13:36 timotimo the arg list has to be shuffled around, too
13:36 brrt it's more complex than that since we need to keep the instruction facts aligned with the tree function, and we don't have that yet
13:36 brrt hmmm
13:37 brrt ok, maybe it's simpler to do during tree generation then
13:37 brrt in general there is a *lot* we can do during traversal
13:41 brrt actually, that's not really true timotimo
13:41 brrt currently, we use the repr op wrappers
13:41 timotimo no, look further up :)
13:42 timotimo jgb_consume_reprop
13:42 timotimo remember how i introduced MVM_JIT_REG_STABLE and MVM_JIT_REG_OBJBODY?
13:42 brrt yes
13:42 brrt i recall
13:44 timotimo in pretty much every case we pass the invocant three times with different offsets and many reprops take a "what's the type of register we're dealing with?" parameter, too
13:44 timotimo i expect we'd be able to do something clever-ish with common subexpression extraction to make the code for STABLE, VAL, OBJBODY optimal
13:44 timotimo i had put a small special case into the code generator at one point, but that was deemed inappropriate
13:47 brrt yes, i expect so too
13:48 brrt i deemed it inappropriate, because i'd forget about it, and i didn't consider that worth the risk :-)
13:48 timotimo fair enough :)
13:49 brrt but yes, CSE is an integral part of the plan, because otherwise we're going to emit quite  a few memory cycles of the same operand
13:49 brrt and that'd be not-so-very-nice
13:49 timotimo very much so
13:51 brrt (why would it do that? because a load registers a variable as computed (so it can be reused), and computed variables need to be stored
13:51 brrt can you eliminate that at tree creation time? yes, but CSE also does it, and more besides
13:52 brrt actually CSE doesn't do it, but makes it very simple; stores with two equal operands are simply removed from roots
13:54 timotimo excellent, i say
14:02 brrt it's just a plan, now :-)
14:02 [Coke] (portland) I have a cousin that lives in seaside, which has a beach you can drive on. It's also pretty close to the house from the movie Goonies. :)
14:02 timotimo we'll make it happen. either as planned, or better :D
14:02 [Coke] (if you're looking for sightseeing stuff for before or after. :)
14:24 brrt i'm off for a bit
14:26 brrt hmm
14:26 brrt nqp building crashes
14:48 rurban joined #moarvm
14:50 FROGGS btw, I own an ultrasparc server now
14:53 jnthn evening, folks o/
14:54 FROGGS hi jnthn
14:56 * jnthn had hoped to be doing more Perl 6 stuff these last days
14:56 jnthn Instead, I spent it discovering (the hard way) a medication I should not take. :/
14:58 FROGGS ewww :o(
14:58 FROGGS jnthn: you are better now? ó.ò
14:59 jnthn Well, I'm approximately back to the state I was before I took the darn thing...
15:00 FROGGS :S
15:02 japhb What's the medication, and what was the reaction?
15:04 jnthn Some anti-allergy thingy (tried 'cus I wasn't sure the one I was taking was doing enough to help). And reaction was a lot of fever and feeling really weak...
15:04 japhb Oh geez, not good!
15:04 * jnthn sees brrt++ seems to have been keeping busy in the backlog
15:05 timotimo the only anti-allergy things i know are loratadine and cetirizine (or some variation of that spelling) including a "new and improved" version that has the prefix "des"
15:05 timotimo they tend to not help terribly much against my hayfever
15:06 jnthn I'll have to use some translator to figure out the English names for the active ingredients...
15:08 jnthn Yay, latest warning-removal patches to Moar don't make any problems for MSVC :)
15:11 hoelzro hello, #moarvm!
15:11 FROGGS jnthn: :D
15:11 hoelzro I was digging into the source a bit while debugging a module issue, and I think I found a memory leak: https://github.com/MoarVM/MoarVM/blob/f0903057604627e21ad013350447bc0280a16369/src/core/nativecall.c#L360
15:12 FROGGS hie hoelzro
15:12 hoelzro hi FROGGS
15:14 timotimo hoelzro: we recently got a function for throwing exceptions that takes a list of things to free after throwing
15:14 timotimo it'll be a bit of work to start using it everywhere, but it helps with that
15:14 hoelzro timotimo: I noticed that, and was curious why it wasn't getting used.  I guess its age has something to do with it =)
15:15 timotimo yes, that function is rather young
15:15 timotimo if you have a few minutes left over, you can start anywhere you like :)
15:15 timotimo though i'd say you wouldn't be trying to load symbols from more than ~five libraries that can't be found
15:15 hoelzro timotimo: perhaps after I've figured out this bug I'm seeing =/
15:15 timotimo i expect after the first failure to find some library, you're screwed anyway :)
15:16 timotimo memory leaks in tight loops are much more worrying
15:16 hoelzro yeah, this callsite itself isn't a huge concern; it's more the pattern
15:16 timotimo not saying it shouldn't be fixed; just on low priority
15:16 hoelzro sure
15:20 timotimo i suppose putting this on my list of "things to do when i don't feel so good" is a good idea :)
15:20 timotimo it probably needs only little focus
15:41 TimToady joined #moarvm
16:01 Ven joined #moarvm
16:26 hoelzro I wonder if it would be a good idea to support something like %S in MoarVM format strings, which would use a MVMString
16:26 hoelzro that would probably handle most of the potential leaks
16:28 nwc10 hoelzro: if so, I'd suggest looking at what Perl 5 is doing for custom format strings. It's using obscure things that are valid (but pointless) C89 formats, which permits one to enable gcc (and similar) compile time warnings about "this function takes a *printf format string"
16:28 hoelzro ah, good point
18:02 FROGGS joined #moarvm
18:09 dalek MoarVM/even-moar-jit: 30a4b78 | brrt++ | src/jit/expr (2 files):
18:09 dalek MoarVM/even-moar-jit: Small fix; use const for acquiring func ptr
18:09 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/30a4b7853a
20:18 TEttinger joined #moarvm
20:33 colomon joined #moarvm
21:33 colomon joined #moarvm

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