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
|