brrt good * #moarvm 10:32
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?
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
[Coke] this is actually a moarvm config bug: RT #127308 14:07
brrt [Coke]: link? 14:23
[Coke] rt.perl.org/Ticket/Display.html?id=127308 14:27
brrt thanks 14:33
Guest72620 RT #12345 19:36
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
timotimo mhh 22:13

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!