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!