04:46 ggoebel111111114 joined 07:32 FROGGS joined 08:04 zakharyas joined 08:06 lizmat_ joined 08:19 brrt joined 08:39 lizmat joined 08:42 lizmat_ joined
brrt tratt.net/laurie/blog/entries/fast_...nough_time interesting 08:44
about vm's and pypy and stuff
FROGGS ohh, will read that as soon as I have time 08:46
08:48 lizmat joined 08:49 lizmat__ joined 08:50 lizmat joined
brrt i'm not totally agreeing about rpython being awesome 08:50
i saw it and it was limited, but unlike nqp, it didn't make that entirely obvious 08:51
that sucks imho
FROGGS yeah
08:51 lizmat___ joined 08:53 lizmat_ joined
nwc10 brrt: irclog.perlgeek.de/moarvm/2014-10-24#i_9559181 08:58
09:02 lizmat joined
brrt thanks :-) 09:04
09:15 lizmat_ joined, kjs_ joined
brrt wrt to the difficulties he expressed in writing JIT's... I can concur with some, and not with others 09:21
but that may be because moarvm is on the whole pretty well-designed 09:22
i.e. it was easier than he makes it out to be
09:38 brrt joined 09:45 lizmat joined 10:02 lizmat_ joined 10:10 JimmyZ joined
JimmyZ I saw the luajit asm code, it's well designed, and so looks like it's not that hard, i.e: call exten func 10:11
precall and postcall etc 10:12
*extern 10:13
brrt luajit is well designed indeed :-) 10:14
i should study that a bit more
JimmyZ yeah, And I really like its allocation sink optimization and I hope moarvm will also have it . 10:15
which will really helps perl6's performance 10:16
10:16 lizmat joined
JimmyZ will discuss it a bit with jnthn later ... 10:16
*jnthn++ :P 10:17
nwc10 timotimo: unfortunately 15d3b75921577f342ffaa128de141199343e3a37/824b28497ceab5a162a50ab6bcaa17bd1bf6a89d/0809f665c272dcdd28fc6d0eaacd7354b7a38135 add ASAN barfage 10:21
can jit multicacheadd and multicachefind 10:23
er
paste.scsys.co.uk/435332
brrt allocation sink pot?
opt
JimmyZ yeah 10:26
*sinking 10:28
an addition optimization to escape analysis 10:29
for the escaped variable
nwc10 timotimo: strangely, valgrind can't spot anything 10:44
brrt hmmm 10:45
11:31 zakharyas joined
dalek arVM: 63f3285 | (Timo Paulssen)++ | src/jit/graph.c:
fix wrong number of arguments passed to multicache*
11:35
timotimo ^- should be better
brrt: allocation sinking means you move the allocation that *does* escape as far towards the end as possible, which often causes the allocation to be moved past some branching point that is only taken rarely 11:37
brrt: implementing brshift_i and blshift_i should be very easy, but i've had massive amounts of trouble 11:39
especially regarding register sizes and such
as the shift instructions want an 8bit register for the shift amount 11:40
11:52 JimmyZ joined
nwc10 timotimo: works on "my" machine 11:54
(2 spectests fail. I think that's a #perl6 problem)
JimmyZ timotimo: the example is past to some branch, but the it actually is to past to anoter frame(and the benchmark code too)
timotimo might be
JimmyZ an frame always return a new object and past to another frame sometimes is not need, which can be optimized 11:56
timotimo ah, hmm 11:57
we do have an "is in sink context" thing inside our optimizer
i think the GLR will also cause a nice improvement to how sinking works 11:58
JimmyZ and that's why it said it needs tracing
timotimo it'd be moved out of the code-gen and into return handlers possibly?
i don't 100% remember
JimmyZ well, it's different thing, methinks?
sink context vs allocation sinking
timotimo i meant the "blocks have to return something" thing 12:01
JimmyZ I know nothing about perl6's sinking context :P
and I didn't see any context sinkin in the Rat type 12:04
*sinking
timotimo right, fair enough 12:08
it's a "big thing" in rakudo though 12:09
JimmyZ the luajit benchmark code is very much like the Rat type in rakudo
and I think the Rat type doesn't have context sinking
timotimo yes 12:10
i was talking about "the rest of rakudo" :)
JimmyZ I know :P 12:11
brrt aha timotimo 12:12
brrt can look at b(lr)shift
timotimo thanks :)
brrt np :-)
timotimo and when i implemented reprname, i stumbled upon a segfault, but that's probably due to the multicache* stuff i botched rather than reprname itself 12:13
also, invokewithcapture? :)
brrt haven't had time for it
if you just finish my distributed system course project for me, i'll fix the JIT, how about that
;-)
timotimo :D
brrt (which i'm doing on my own by now... o.O) 12:14
timotimo - how to make a shift in nqp 12:21
timotimo nqp::shift? 12:22
brrt aha
no 12:23
timotimo what are you looking for, exactly?
brrt a binary shift 12:24
$x << 1 or so, that doesn't work
timotimo oh
+< in perl6
the op is called bitshiftl_i
brrt aha 12:25
12:37 lizmat_ joined 12:40 lizmat__ joined 12:44 brrt joined
brrt have i cmplained about clang sufficiently yet 12:45
FROGGS brrt: yes :o)
brrt ok
then i can skip it today
FROGGS *g*
12:46 lizmat joined 12:49 lizmat_ joined 12:53 lizmat joined
brrt pff 13:10
13:22 itz joined
dalek arVM: 6724ed6 | (Bart Wiegmans)++ | src/jit/ (2 files):
JIT blshift_i and brshift_i

Also small fix to make clang a bit happier
13:37
brrt timotimo ^
13:38 lizmat_ joined
timotimo <3 13:45
pretty much every single run of perl6 uses blshift_i because it's used when setting up moar op mappers
oh, shl and shr are correct? 13:46
i was convinced i'd have to use shld and shrd
brrt as far as i know they are ok
shld is probably shift-left-doubleword
timotimo i believe so
brrt as in, 32 bit shift-left
timotimo well, "double precision"
should be 64bit
brrt but dynasm doesn't use op modifiers but argument modifiers 13:47
so if you want to do that, you want to write shl eax, cl;
timotimo oh
brrt (cl is rcx lower byte)
timotimo well, that's good to know! :)
brrt and you only need to use 'm when accessing memory, because it is 'embedded' in the size of the register 13:48
timotimo 'k
13:49 kjs_ joined
[Coke] Octover? 13:53
brrt octover? 13:54
timotimo quadrover?
brrt octoword :-)]
and quadword
13:58 zakharyas joined
[Coke] whoops, wrong window. 13:58
brrt :-) 14:02
[Coke] moarvm jit died today. 14:12
brrt wow 14:14
i see
hmmm
can we bisect that
[Coke] brrt: sure, I can do that. 14:25
brrt thanks :-) 14:26
timotimo [Coke]: it would be enough to see if my fix commit for multicache* fixes it: github.com/MoarVM/MoarVM/commit/63f3285b53 14:28
[Coke] HEAD seems fine. 14:37
(still running, but passing stuff)
14:50 bcode joined
TimToady I would be very surprised to see any sinking in a value type like Rat, since the only purpose of sink is to trigger side effects. 15:55
m: 42; 43 15:56
camelia rakudo-moar 315ec6: OUTPUT«WARNINGS:␤Useless use of constant integer 42 in sink context (line 1)␤»
TimToady m: 1/42; 1/43
camelia ( no output )
TimToady there's a missing diagnostic there
m: 42.1; 43.1; 16:00
camelia ( no output )
TimToady well, probably a #perl6 issue now
FROGGS m: v42; v1 16:01
camelia ( no output )
JimmyZ TimToady: yeah, we didn't expect to see any sinking in a value like Rat 16:04
Good night 16:06
FROGGS gnight JimmyZ
TimToady o/
16:14 FROGGS[mobile] joined 16:34 kjs_ joined 16:46 FROGGS joined 17:33 lizmat joined 17:49 FROGGS_ joined 19:17 kjs_ joined 19:32 Ven joined 19:44 Ven joined
timotimo damn it, building rakudos core setting gives me segfaults quite reliably now >_< 19:50
[Coke] timotimo: does it work with moarvm-recommended? 20:01
timotimo will try 20:02
it doesn't :\ 20:03
i don't have local changes either 20:05
21:42 kjs_ joined 22:34 colomon joined 23:13 timotimo joined