02:06 vendethiel joined 03:33 vendethiel joined 04:21 vendethiel joined 05:34 vendethiel joined 06:30 FROGGS joined 07:37 rurban joined 08:32 FROGGS joined
dalek arVM/even-moar-jit: 79a2473 | brrt++ | / (4 files):
Use S-expressions throughout the exprlist

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