00:32 dalek joined 01:19 ggoebel joined 01:30 TEttinger joined 01:46 dalek joined 01:47 JimmyZ joined, avuserow joined 01:48 Util joined, [Coke] joined, sergot joined, masak joined, PerlJam joined, psch joined 02:11 colomon joined 02:14 colomon_ joined 02:19 colomon_ joined 02:25 colomon_ joined 02:30 colomon_ joined 02:34 colomon_ joined 02:37 colomon joined 02:42 colomon joined 02:45 colomon_ joined 06:53 FROGGS joined
FROGGS o/ 06:53
nwc10 \o 06:54
06:56 zakharyas joined
jnthn o/ 07:01
nwc10 jnthn: never mind the 10 minute commute, is the curry good? :-) 07:02
07:02 rurban joined
timotimo i hope jnth's teachings go well today :) 10:52
jnthn nwc10: No curry yet :) 11:18
Last night was beer and burger
Maybe curry tonight :) 11:19
But certainly curry at end of week ocne I'm back home...
jnthn has a long list of curry recipes he wants to try cooking
13:09 ggoebel joined 13:40 JimmyZ_ joined 14:04 _longines joined 14:56 brrt joined
brrt \o 14:57
nwc10 o/ 14:58
brrt i just had a *horrible* road trip
nwc10 oh :-(
tadzik :( 15:00
brrt actually, train trip
dunno why i sad road trip
anyway, can you help me with something? i still need to represent the 3d array efficiently 15:02
oh, and another problem; i need to prune rulesets, and earlier = better
for pruning, i currently have no good solution other than the idea that it'll have something to do with topological sort 15:06
(early pruning, that is)
for the 3d array, i was thinking of having a linear array of 3 integers and using binary search 15:07
that's not the most space efficient way to do it, but it'll be very easy to implement 15:10
pruning (late) reduces 17003 rules to 1202 15:19
timotimo i put the "run" in "prune" 15:50
[Coke] You can't spell prune without a pun. 15:56
16:02 rurban joined 17:58 zakharyas joined
jnthn
.oO( I put in the prune and got runs... )
18:32
18:42 FROGGS joined 19:36 zakharyas joined 19:49 brrt joined
brrt hmm... i think i have a strategy for 'early' pruning 19:51
what's the difference? oh, why not, i'll explain
(what's the use? currently the table construction algorithm is O(m*n^2), n = number of rules, m = number of IR tree node types 19:52
actually, that's wrong
n = number of rule*sets*, which are combinations-of-rules; given any tree node type (head) with i matching rules, we have 2^i combinations 19:54
but many of those 2^i combinations are 'invalid', i.e. are never generated
now, a simple way to figure out which sets *are* generated is by generating the entire table and picking all rulesets from those 19:57
but of course, by then i've already done my million-or-so iterations
so what is needed is a way to figure out all the rulesets generated by the grammar without generating the entire ruleset-table 19:58
first observation: the tiler table maps heads with specific children-states to new rulesets-states 20:00
hence, only rulesets with the same head can combine
hmm 20:12
dalek arVM/even-moar-jit: e165986 | brrt++ | tools/tiler-table-generator.pl:
Add rule pruning, making the table much smaller
20:32
arVM/even-moar-jit: 499d4c2 | timotimo++ | / (12 files):
add special support for nativecallinvoke to profiler
20:44
MoarVM/even-moar-jit: b0e6608 | timotimo++ | src/profiler/profile.c:
MoarVM/even-moar-jit: fix output of profiler wrt. native function names
20:45 dalek joined 21:53 colomon_ joined 21:58 colomon joined