00:12 tokuhirom_ joined 01:16 tokuhiro_ joined 01:48 ilbot3 joined 02:30 tokuhirom_ joined 02:58 tokuhiro_ joined 04:01 tokuhirom_ joined 05:01 tokuhirom_ joined 06:10 rarara_ joined 06:17 tokuhirom_ joined 06:40 Ven joined 07:02 domidumont joined 07:07 domidumont joined 07:17 zakharyas joined 07:40 Ven joined 07:47 Ven joined 07:51 Ven_ joined 08:03 tokuhirom_ joined 08:12 Ven joined 08:14 Ven_ joined 08:16 Ven joined 08:31 Ven joined 08:33 Ven joined 08:37 Ven joined 08:50 Ven joined 08:53 Ven joined 09:04 tokuhirom_ joined 09:07 zakharyas joined 09:08 Ven_ joined 09:11 Ven joined 09:14 Ven_ joined 09:36 brrt joined
brrt \o 09:36
nwc10 o/ 09:37
brrt: morepypy.blogspot.co.at/2015/10/pow...r-jit.html
URL says enough :-)
also, gcc.gnu.org/wiki/CompileFarm now has aarch64 09:38
and we build fine on it
but, page imples that IBM paid for Power
so, grant application to IBM soon? :-)
timotimo i hope our jit will reach speedups of 50x at some point ... 09:39
for things bigger than an empty loop :)
brrt oh, let's see 09:46
cool stuff
i'll have to write a 'porting' document 09:47
one day or another
i have a new topic for a talk at some conference in the future
'how to make a JIT on the cheap' or 'how to make building a JIT so simple it can be done in < 1 person-year'
timotimo hah
brrt but, cool progress for pypy :-) 09:48
i have a decent guess as to why the performance gain on powerpc exceeds that of the relative gain on x86_64 09:49
09:49 FROGGS__ joined
brrt a): x86_64 these days have impressively good branch prediction, and that helps the interpreter 09:49
b): 9.3 to 9.7 is noise, when we're considering we're talking about an average *factor* 09:50
09:51 zakharyas joined
brrt (i'm not sure, because i haven't calculated it, whether that is calculated as a geometric average, but let's ignore that for now) 09:51
09:52 ShimmerFairy joined
timotimo it says geometric average 09:52
under that table, they also say the thing about branch prediction
brrt aha 09:53
c): powerpc, being a RISC architecture, is 'easier' to write a good code generator for
oh, i fixed a few bugs on the bus here... but i have a question for you to ponder 10:00
it so happens that i sometimes load a 1-or-2 byte value from memory, and then try to use it as a 4 or 8 byte value 10:01
however, x86 does not clear the upper bytes of a register if you load it word or byte mode
10:04 tokuhirom_ joined
Ven_ should it? 10:07
don't you have the "zbl" variants for that?
10:13 Ven joined 11:18 Ven joined 11:20 tokuhirom_ joined
brrt actually, you do 11:50
good point
no, the question is just that when we're loading smaller values and using them as indices, the fact that the higher bytes are not cleared yields a segfault 11:55
my question is really a design question 11:56
should i, when using a smaller-byte value in a larger-byte context - and i know the sizes of my operands, they're encoded througout the expression tree, a): automatically zero-extend all values and not care b): have an explicit 'scale' node to do so 11:57
and b.a): should i explicitly insert it everywhere or b.b): should this be done automatically, and b.b.b: if that is the case, how do i know ahead of time which operations are signed and unsigend 11:58
always design questions :-) 12:00
12:36 tokuhirom_ joined 13:27 Ven joined 13:48 FROGGS joined 15:00 Ven_ joined 15:03 Ven joined 16:10 kjs_ joined 16:18 colomon joined 16:30 nine joined 16:39 domidumont joined 16:53 tokuhiro_ joined 17:00 kjs_ joined 18:05 vendethiel joined 18:36 leont joined 19:00 Peter_R joined 19:23 kjs_ joined
konobi jnthn: ping 19:25
TimToady on his honeymoon this week 19:28
konobi ah yes 19:29
19:38 tokuhirom_ joined 20:30 dalek joined 20:35 synbot6 joined 21:16 tokuhiro_ joined 21:22 kjs_ joined 21:33 kjs_ joined 21:36 kjs_ joined 22:16 tokuhiro_ joined 22:21 zakharyas joined 23:28 tokuhirom_ 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!