00:42 arnsholt_ joined, hoelzro_ joined, ilmari_ joined 00:47 BinGOs joined 01:32 camelia joined 01:33 cxreg joined, konobi joined 01:48 ilbot3 joined 01:59 FROGGS joined 02:11 geekosaur joined
FROGGS .tell nebuchadnezzar MoarVM builds fine on mips64el, but is rather unusable it seems: gist.github.com/FROGGS/05195d5426c...00f684de72 05:45
yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.
FROGGS hmmmm, perhaps the jit was active? I should check that... 05:50
root@debian-sid-mips64el:/home/MoarVM# grep jit src/gen/config.c 05:54
add_entry(tc, config, "jit", "$(JIT_STUB)");
compared to my ubuntu box: ~/dev/MoarVM$ grep jit src/gen/config.c
add_entry(tc, config, "jit", "$(JIT_POSIX_X64)");
I guess that means that the jit is correctly disabled on mips64el 05:55
which is kinda bad, because I have no idea what could be wrong... 06:08
jnthn: do you have an idea?
06:45 domidumont joined 06:50 domidumont joined
brrt it'd probably help if we had a debug build :-) 06:58
nwc10 \o 07:05
brrt good * nwc10 07:08
I'm quite amazed at magit, btw 07:10
oh, nwc10, can you help me out with a bit of advice :-) 07:11
I'm writing a blog about memory allocation strategies
should I include a bit about the difference between GC and refcounting 07:12
noting that the post isn't really about either, except to contrast them with the chosen strategy
nwc10 urg, I think it's still hard to answer that without seeing a draft 07:13
07:13 domidumont joined
brrt hmm, okay, I can probably get you that :-) 07:13
nwc10 but also, it sort of feels like apples vs oranges
in that, reference counting and "real" GC are both ways to manage ownership of memory
brrt uhuh 07:14
nwc10 whereas what you seem to be describing is a strategy for how to carve up big amounts of memory that the OS gave into bits
or is this "We get a big block, and then use it without ever freeing stuff itnernally, and throw it away when we're done"
brrt well, I'm actually treating it from the perspective that the hard bit is to throw it away at the right time 07:15
walking object graphs is annoying, for one thing
nwc10 then I think "yes", it having a short bit to note that reference counting and "real" GC are about the general case of trying to free up memory at "the right time" 07:16
and you're just trying to avoid the complexity of that issue
by being far less granular
leaking internally, and then throwing away the whole lot at a safe point
brrt that is more or less the thing, yes 07:29
07:36 zakharyas joined 07:38 FROGGS[mobile] joined
FROGGS[mobile] brrt: that is a debug build 07:39
brrt oh... why no stack trace then :-o 07:49
08:14 vendethiel joined
jnthn Interesting that reference counting's idea of "right time" is "as soon as the memory is no longer in use", while reachability GCs have it more as "when we need that memory for something else" 08:57
yoleaux2 22 Oct 2016 11:24Z <lizmat> jnthn: "abc".match(/./,:nth(2,3,4)) fails because there is no 4th match, implying this is cached after all. So, since we *have* caching here, I propose we just make "abc".match(/./,:nth(1,3,2)) work
brrt heh, that's right, I hadn't even considered that one 08:58
jnthn I guess viewed another way, that's just a latency/throughput trade-ff 08:59
*trade-off
.tell lizmat I suspect that shouldn't fail at all, but just end the iteration 09:04
yoleaux2 jnthn: I'll pass your message to lizmat.
brrt which brings to mind... how do we deal with destructors in youngspace 09:25
because if we have destructors, we still have to scan youngspace for any objects that might want them to trigger
which otherwise wouldn't be necessary
(destructors suck)
timotimo we register every object that has a destructor when it gets created 09:26
brrt uhuh... and how ... oh 09:27
i see
you just run over that list, and if they've been traced / moved, you'll know
jnthn You stick them on a queue, then scan that queue
After the rest of the work
brrt cool, that's pretty clever 09:28
jnthn And if they were unmarked, you mark them but kick them off the queue
:)
It is, quite literally, the textbook approach :)
It's basically "you only live twice" semantics
brrt should look up the textbook
jnthn The GC Handbook :) 09:29
brrt hehe
oh, I should check out if I can still access that by university library now that I can
jnthn has it on dead tree
brrt in the past, I used to be able to get a 'alumni' account which would've given access, but they've stopped doing that half a year ago
I do have a PDF of 'Compiler Engineering' from that, though 09:31
of which my only complaint is that it could go a bit further into theory 09:33
timotimo i hope i wasn't out of line to add the valgrind stuff to moar/master 09:34
jnthn Didn't get to check it yet :) 09:35
brrt timotimo: didn't see people panicking in #perl6, so I think you're good
timotimo i'm expecting almost all the stuff i put in would be dead-code-eliminated when the --valgrind flag wasn't passed to Configure.pl 09:36
09:42 lizmat joined
timotimo my recent exposure to talks telling how absolutely dreadful the performance of linked lists are has made me a bit unhappy about our free lists in the FSA 09:48
jnthn Except all the things we're doing with them are O(1)? 09:50
(In the FSA case, I mean)
timotimo but following the chain gives us cache misses left right and center 09:52
timotimo not experienced enough with close-to-hardware stuff to have an accurate discussion :( 09:53
jnthn Yes, but we don't really follow the chain either 09:54
timotimo we only ever take the first or put a new one in the first slot, yeah 09:55
jnthn We pull the thing off the head of it and read the pointer to the next thing from it, but that's memory that's going to be used immediately anyway in most cases, by the thing that has done the allocation
iirc, we also insert free things at the head and allocate from the head, so in many cases the memory we access will be in the cache anyway. 09:56
timotimo ah, mhm
jnthn (Since it's the most recently used block of that size)
I agree with the general assessment that linked lists are cache-horrible, fwiw.
nwc10 and also LTA for divide-and-conquer approaches to parallise stuff 09:57
jnthn *nod*
timotimo can you tell me more specifics about the MVM_barrier we have in place in MVM_fixed_size_alloc?
especially: can the barrier itself be put off when we do multiple allocs in a row? 09:58
jnthn Barriers are generally there for the sake of CPUs with weaker consistency models
nwc10 oh the sad irony - functional languages have immutability (which is great conceptually for parallelisation) and then prefer data structures which tank the praciticalies
jnthn nwc10: There's no free lunch :)
nwc10 such an excellent feed line. And 2.5 hours too early to point ilmari to 09:59
jnthn "feed line"...I see what you did there... :P 10:01
timotimo: I think the barrier may be unrequired there at this point
timotimo tries removing it
jnthn Since trycas implies a barriering 10:02
But looking at the comment there, I think it was once needed
timotimo i'm doing a tiny measurement right now 10:04
in this version of the workload the program spends 15% of its time in fixed_size_alloc and 5.4% in fixed_size_free 10:05
it runs for 16.76s in total
in the other version of the workload the program spends 3.71% of its time in fixed_size_alloc and 2.18% of its time in fixed_size_free 10:07
it runs for 14.21s in total
the difference is a start { say "started" } near the beginning
with the barrier removed and the start { started } in again, fixed_size_alloc is down to only 8.47% and fixed_size_free is at 6.03% 10:08
brrt I recall reading somewhere that immutability 'in the large' was considered preferable to 'in the small' due to the practicalities and scope 10:09
timotimo total time spent down to about 15.46s
brrt i.e. small-scale immutability is unpractical, large-scale can save your day
nwc10 waves_ ilmari_ 10:15
timotimo spec tests are clean on my machine with the removal of the barrier there 10:19
jnthn I suspect Intel CPUs are probably the worst to test if a barrier is actually needed :) 10:49
11:10 dalek joined 11:57 brrt joined 12:36 nebuchad` joined 12:40 moritz_ joined 12:52 ggoebel joined
nwc10 worries that if ilmari doesn't eat, he too will go immutable 12:53
ilmari is just about to go for lunch, actually 12:54
nwc10 \o/ 12:55
don't let me stop you
(or anyone else)
ilmari is full of tasty burrito 13:33
13:49 geekosaur joined
diakopter nwc10: re "functional languages have immutability (which is great conceptually for parallelisation) and then prefer data structures which tank the praciticalies" - if only people could prove the more practical implementations are as safe/equivalent 16:20
16:28 domidumont joined 17:04 JackCode2 joined 18:28 FROGGS joined
FROGGS o 18:31
o/
timotimo o 18:32
FROGGS brrt / jnthn: I updated the gist for mips64el: gist.github.com/FROGGS/05195d5426c...00f684de72 18:57
the issue seems to be with atomic ops 19:38
lemme rebuild moar with debians libatomic-ops -.- 19:42
(because there are three mips patches in debians package included) 19:45
23:13 dalek joined 23:43 arnsholt joined 23:46 ilbot3 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!