01:01
TimToady joined
01:11
raiph joined
01:38
flussence joined
06:36
vendethiel joined
06:58
zakharyas joined
07:00
FROGGS joined
|
|||
FROGGS | nebuchadnezzar: when do we start packaging nqp? | 07:43 | |
nebuchadnezzar | I plan to look at it this week-end | 07:49 | |
07:57
brrt joined
|
|||
brrt | \o | 08:01 | |
this is weird | 08:07 | ||
all my memory has been corrupted | |||
nebuchadnezzar | brrt: do you remember your name? ;-) | 08:08 | |
brrt | computer says its brrt | 08:09 | |
i can't.... believe it | 08:11 | ||
stack overflow | 08:12 | ||
a cycle in the tree? | |||
no, a corruption | 08:14 | ||
you dense... | |||
dalek | arVM/even-moar-jit: 6023ac9 | brrt++ | src/jit/ (2 files): Add a few expressions and made calls consistent |
08:17 | |
jnthn | o/ | 08:34 | |
08:39
FROGGS joined
|
|||
brrt | \o jnthn | 08:44 | |
i'm compiling a todo list | |||
and... i'm still a bit fuzzy on the tile-and-emit routine | 08:45 | ||
or, let's put that in other words | 08:49 | ||
i don't really prefer to have *another* pass after tiling | |||
the problem with adding a routine for tree traversal is that everything then becomes a tree traversal problem | 08:50 | ||
08:56
Ven joined,
zakharyas joined
|
|||
dalek | arVM/even-moar-jit: 04f336d | jnthn++ | src/core/bytecode.c: Fix a missing lock release. |
09:05 | |
arVM/even-moar-jit: f89d760 | jnthn++ | src/core/frame.c: Avoid concurrent frame prepare/validate. While the validation itself is idempotent, the assigning of a lexotic pool index decidedly is not. Should fix a crash reported by nwc10++. |
|||
MoarVM/even-moar-jit: bbe6231 | jnthn++ | src/core/interp.c: | |||
MoarVM/even-moar-jit: Fix extop "did interpreter move" check. | |||
MoarVM/even-moar-jit: | |||
brrt | hmm, waitaminute | 09:08 | |
let me see how we implement 'did interpreter move' in the JIT | |||
dalek | arVM: 14d2155 | jnthn++ | tools/update_ops.p6: Fix warning in op gen tool. |
09:29 | |
09:34
Ven joined
09:56
zakharyas joined
|
|||
dalek | arVM: b8fdeae | jnthn++ | / (6 files): Add ctxcode op. Gets the code object associated with a particular context. |
10:01 | |
10:02
Ven_ joined
|
|||
brrt | nice, we can implement that | 10:03 | |
uhm | |||
what's the *ctx doing on line 4692 | |||
it's not referenced or initialized | 10:04 | ||
jnthn | argh, I hate that declaration syntax for exactly this reason | ||
dalek | arVM: 4db70f8 | jnthn++ | src/core/interp.c: Clear up unused vars; brrt++. |
10:05 | |
arVM: bc79c56 | jnthn++ | src/core/interp.c: Tweak error message. |
10:07 | ||
10:12
masak joined
|
|||
dalek | arVM/even-moar-jit: 13d0694 | brrt++ | src/jit/ (4 files): Initial rough draft of tile implementations In order to figure out what kind of things real tiles would need, I find it helpful to write a rough draft of what they would look like. |
10:29 | |
11:24
Ven joined
|
|||
dalek | arVM/even-moar-jit: 14d2155 | jnthn++ | tools/update_ops.p6: Fix warning in op gen tool. |
11:42 | |
arVM/even-moar-jit: b8fdeae | jnthn++ | / (6 files): Add ctxcode op. Gets the code object associated with a particular context. |
|||
arVM/even-moar-jit: 4db70f8 | jnthn++ | src/core/interp.c: Clear up unused vars; brrt++. |
|||
arVM/even-moar-jit: bc79c56 | jnthn++ | src/core/interp.c: Tweak error message. |
|||
brrt | hmm waitaminute | 11:43 | |
dalek | arVM/even-moar-jit: d68dd69 | brrt++ | build/Makefile.in: Add additional dependencies for exprlist and tiles When oplist changes, the expression template table needs to be recompiled. |
11:48 | |
brrt wonders what is wrong with MVM_jit_expr_tree_destroy | 11:54 | ||
no, wait | 12:12 | ||
what i wonder is how we can be looking at node 184 when only 172 nodes have been written | |||
timotimo | is "MVMObject *this_ctx = GET_REG(cur_op, 2).o, *ctx;" really correct? | 12:15 | |
the comma operator just evaluates to its RHS, so the argument actually doesn't get used at all? | 12:16 | ||
brrt | has already been fixed :-) | 12:17 | |
timotimo | OK | ||
ah, the unused var fix | 12:18 | ||
12:31
zakharyas joined
|
|||
dalek | arVM/even-moar-jit: a9c0a68 | brrt++ | src/jit/core.expr: Fix misplaced parenthesis in core.expr These bugs can be extremely tricky to hunt down, so it may be worth it to spend some time parsing the expr.h definitions, so that the core.expr file is consistent with that. |
12:36 | |
brrt | i'm afk for a bit | 12:42 | |
13:23
raiph joined
14:16
hoelzro_ii joined
14:23
psch joined
15:05
FROGGS[mobile] joined
|
|||
jnthn | m: say 4.99 / 0.17 | 17:05 | |
camelia | rakudo-moar 56ae33: OUTPUTĀ«29.352941ā¤Ā» | ||
jnthn | dinner & | 17:09 | |
18:16
Peter_R joined
19:22
vendethiel joined
19:23
oetiker joined
19:45
FROGGS joined
19:48
raiph joined
|
|||
timotimo | i ... what? | 20:11 | |
jnthn | ?? | 20:13 | |
20:13
TEttinger joined
|
|||
timotimo | did you just make something only take 29% as much time or ram or something? :-) | 20:14 | |
jnthn | Oh, doing some GLR guts exploring | 20:16 | |
timotimo | mhm | 20:17 | |
20:31
raiph joined
|
|||
tadzik | (so, yes) :P | 20:35 | |
timotimo | :) | 20:37 | |
i'm expecting times of things to shrink down to at least 10%, if not less | 20:38 | ||
jnthn | Well, that was before I put in various things we'll need. | 20:41 | |
timotimo | ah | 20:48 | |
timotimo still not progressing with the optimizer thing, but i know i'll probably have to work with pre-setting code | 20:58 | ||
jnthn | m: say 4.49 / 0.59 # more like this now :) | 21:27 | |
camelia | rakudo-moar 5d9306: OUTPUTĀ«7.610169ā¤Ā» | ||
jnthn | Anyways, plenty to go :) | 21:28 | |
timotimo | well, to be honest i have no clue what exactly you're working on | ||
for @foo { for @foo { for @foo { something } } }? | |||
jnthn | for ('beer' xx 10000).map(*.uc) -> $beer { } | 21:30 | |
timotimo | ah, that's it, yeah? | ||
so much slower ;( | |||
jnthn | Well, 8x faster than today's impl, and the new code should be a bunch more optimizable | 21:31 | |
More importantly, though, we don't leak memory | 21:32 | ||
So: for ('beer' xx *).map(*.uc) -> $beer { } | 21:33 | ||
Sits nomming memory in Rakudo today | |||
While GLRfor(infix:<GLRxx>('beer', *).GLRmap(*.uc), -> $beer { }) | 21:34 | ||
Works in constant memory | 21:35 | ||
timotimo | good! | ||
so basically infinitely better memory usage? | 21:36 | ||
jnthn | Pretty much ;) | ||
timotimo | that's something we should put into marketing | 21:37 | |
jnthn | But that's easy enough, what's harder is making sure we don't lose values | ||
timotimo | mhm | 21:38 | |
jnthn | hm, why on earth do we end up in find_method a load | ||
timotimo | i wondered the same thing a few times already :S | ||
also the slow path binder in general | |||
jnthn | Hm, what on earth | 21:39 | |
Slow path binder is often understandable | |||
But find_method here is...odd | |||
timotimo | improving the binding lowerer was good fun | 21:40 | |
jnthn | Gee, we're getting int lex refs too | ||
timotimo | isn't that good? | 21:41 | |
jnthn | no, they should be vanishing during the compile | ||
timotimo | they should? | 21:42 | |
i didn't know that | |||
jnthn | In many cases, yes | ||
timotimo | so a lex ref turns into just the lexical again? | ||
if the lexical is "reachable"?( | 21:43 | ||
jnthn | Well, it's more that | 21:44 | |
nqp::assign_i(nqp::getlexref_i(...), 42) should just turn into nqp::bind(..., 42) | |||
Anyway, long story short, it's 8 times faster with sucking code-gen. | |||
timotimo | ah, right | ||
that's a good way to look at it :) | 21:45 | ||
jnthn | I think I'm going to push on with fleshing out the overall new list guts model though | ||
timotimo | that's fair | ||
jnthn | So I've got something to pass to TimToady++ go look through and consider the semantics of | ||
timotimo | get the semantics into the hands of users | ||
then we can have optimization all over the map | 21:46 | ||
jnthn | Well, it's mostly the thing needs to be in the right ballpark and optimizable | ||
Anyway, really enough for today :) | 21:50 | ||
'night | |||
timotimo | gnite! |