00:02 vendethiel joined 02:24 vendethiel joined 02:48 ilbot3 joined 03:54 moritz joined 05:12 vendethiel joined 05:26 vendethiel- joined 05:40 leedo joined 07:04 vendethiel joined 07:09 domidumont joined 07:14 domidumont joined 07:25 domidumont1 joined 07:32 domidumont joined 07:37 domidumont1 joined 07:53 FROGGS joined 08:08 Ven joined 08:10 vendethiel joined 08:17 kjs_ joined 08:30 zakharyas joined 08:36 vendethiel joined 08:55 vendethiel- joined 09:24 kjs_ joined 09:39 leont joined 10:28 brrt joined
brrt good * #moarvm 10:32
10:32 kjs_ joined 10:33 vendethiel joined
jnthn o/ brrt 10:37
brrt \o jnthn 10:38
brrt has started on the implementation of pseudotiles this morning :-)
and this works except that we're jumping to the wrong space, so that's probably a labelling issue 10:39
how are things, though :-) 10:47
do you have any plans for optimisation work currently?
10:49 FROGGS joined
jnthn brrt: I'm still a bit tired, but gradually starting to get back in to things 10:50
It seems I need to make some kind of rulings of how we'll do language back/forward compat before I get to doing opts :)
brrt well.. not meaning to rush you :-) 10:51
yeah, that seems like important work, too 10:52
jnthn I've lots of ideas for opt work. But I just wasn't feeling up to doing much of anything, or distracted with errands, for the first half of January. And now am tied up doing $dayjob things, to make sure I put food on the family this month. :-)
brrt aye
well, i for one at least am interested in speculations too :-) 10:53
jnthn (No, the situation isn't *that* bad, but I should still actually do my $dayjob. :))
(And it's quite fun at the moment anyway.)
Well, got various plans. Reducing the cost of invocation and closures is one big one.
brrt (that is a lucky position to be in, to have a fun $dayjob)
oh, ++ for that one 10:54
jnthn Got a gradually congealing design
nwc10 jnthn: I don't think that it's a good idea to put food onto the family. *Into* the family, maybe. Or onto the table.
jnthn But not quite sure I can make it work yet.
brrt i have not measured, but a very strong feeling that invocation is a very major cost currently
jnthn But overall, the idea is to have a chunk of memory that represents a "stack", and only internal frame references are allowed 10:55
And if we ever need an external one, the frame is then promoted to the heap, and it then becomes a GC-able.
So long-living closures can then be handled by the normal generational scheme, which they ain't at present. 10:56
(Which costs us a bit in CORE.setting compilation)
brrt sounds pretty good, and doable eventually, even if pretty complex 10:57
fwiw, i'm going to try and meet andy wingo at fosdem, and see if we can talk a bit about compilers
11:03 Ven joined 11:28 vendethiel joined 11:51 vendethiel joined 12:19 vendethiel joined 12:37 llfourn joined 13:16 kjs_ joined 13:27 vendethiel joined 13:30 dalek joined 13:38 llfourn joined 13:47 pochi_ joined, colomon_ joined 13:49 ggoebel8 joined 13:51 nine_ joined, moritz_ joined, psch_ joined 14:02 tadzik joined, FROGGS joined 14:03 mtj_ joined, ingy joined, retupmoca joined
[Coke] this is actually a moarvm config bug: RT #127308 14:07
14:09 _longines joined
brrt [Coke]: link? 14:23
14:26 vendethiel joined
[Coke] rt.perl.org/Ticket/Display.html?id=127308 14:27
brrt thanks 14:33
14:39 kjs_ joined 14:54 kjs_ joined 15:00 synopsebotimo joined 15:05 Ven joined 15:19 kjs_ joined 15:43 FROGGS joined 16:37 kjs_ joined 16:56 vendethiel joined 16:59 ashleydev joined 17:10 kjs_ joined 17:34 virtualsue joined 18:00 FROGGS joined 18:03 domidumont joined 18:09 kjs_ joined 18:12 leont joined 18:16 flussenc1 joined 18:18 xiaomiao joined 18:20 timo joined 18:28 tadzik joined 19:21 leont joined
Guest72620 RT #12345 19:36
21:47 colomon joined 22:02 colomon joined
timotimo is turning on link-time-optimization required to make dead code elimination better? 22:02
geekosaur "yes"? 22:05
timotimo a friend is telling me that it's not necessary for statically linked stuff 22:06
geekosaur you can;t eliminate a dead global function unless you can do LTO, eiter manually by putting each function in its own file, creating a .a from them, and linking main() against that, or enabling compiler+inker LTO
timotimo but i seem to remember something else
geekosaur static you can do because if it's not used in that file and no pointers to it are leaked, it can be remoed
(the "no pointers" part may be what you are remembering)
timotimo hmm 22:07
geekosaur again you'd need comiler+linker support to catch that properly
22:07 colomon joined
timotimo mhh 22:13
22:33 colomon joined 23:29 llfourn joined