Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-10-24

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:42 arnsholt_ joined #moarvm
00:42 hoelzro_ joined #moarvm
00:42 ilmari_ joined #moarvm
00:47 BinGOs joined #moarvm
01:32 camelia joined #moarvm
01:33 cxreg joined #moarvm
01:33 konobi joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:59 FROGGS joined #moarvm
02:11 geekosaur joined #moarvm
05:45 FROGGS .tell nebuchadnezzar MoarVM builds fine on mips64el, but is rather unusable it seems: https://gist.github.com/FROGGS/05195d5426cbda9882a9dd00f684de72
05:45 yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.
05:50 FROGGS hmmmm, perhaps the jit was active? I should check that...
05:54 FROGGS root@debian-sid-mips64el:/home/MoarVM# grep jit src/gen/config.c
05:54 FROGGS add_entry(tc, config, "jit", "$(JIT_STUB)");
05:54 FROGGS compared to my ubuntu box: ~/dev/MoarVM$ grep jit src/gen/config.c
05:54 FROGGS add_entry(tc, config, "jit", "$(JIT_POSIX_X64)");
05:55 FROGGS I guess that means that the jit is correctly disabled on mips64el
06:08 FROGGS which is kinda bad, because I have no idea what could be wrong...
06:08 FROGGS jnthn: do you have an idea?
06:45 domidumont joined #moarvm
06:50 domidumont joined #moarvm
06:58 brrt it'd probably help if we had a debug build :-)
07:05 nwc10 \o
07:08 brrt good * nwc10
07:10 brrt I'm quite amazed at magit, btw
07:11 brrt oh, nwc10, can you help me out with a bit of advice :-)
07:11 brrt I'm writing a blog about memory allocation strategies
07:12 brrt should I include a bit about the difference between GC and refcounting
07:12 brrt noting that the post isn't really about either, except to contrast them with the chosen strategy
07:13 nwc10 urg, I think it's still hard to answer that without seeing a draft
07:13 domidumont joined #moarvm
07:13 brrt hmm, okay, I can probably get you that :-)
07:13 nwc10 but also, it sort of feels like apples vs oranges
07:13 nwc10 in that, reference counting and "real" GC are both ways to manage ownership of memory
07:14 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
07:14 nwc10 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"
07:15 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 brrt walking object graphs is annoying, for one thing
07:16 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 nwc10 and you're just trying to avoid the complexity of that issue
07:16 nwc10 by being far less granular
07:16 nwc10 leaking internally, and then throwing away the whole lot at a safe point
07:29 brrt that is more  or less the thing, yes
07:36 zakharyas joined #moarvm
07:38 FROGGS[mobile] joined #moarvm
07:39 FROGGS[mobile] brrt: that is a debug build
07:49 brrt oh... why no stack trace then :-o
08:14 vendethiel joined #moarvm
08:57 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
08:58 brrt heh, that's right, I hadn't even considered that one
08:59 jnthn I guess viewed another way, that's just a latency/throughput trade-ff
08:59 jnthn *trade-off
09:04 jnthn .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.
09:25 brrt which brings to mind... how do we deal with destructors in youngspace
09:25 brrt because if we have destructors, we still have to scan youngspace for any objects that might want them to trigger
09:25 brrt which otherwise wouldn't be necessary
09:25 brrt (destructors suck)
09:26 timotimo we register every object that has a destructor when it gets created
09:27 brrt uhuh... and how ... oh
09:27 brrt i see
09:27 brrt you just run over that list, and if they've been traced / moved, you'll know
09:27 jnthn You stick them on a queue, then scan that queue
09:27 jnthn After the rest of the work
09:28 brrt cool, that's pretty clever
09:28 jnthn And if they were unmarked, you mark them but kick them off the queue
09:28 jnthn :)
09:28 jnthn It is, quite literally, the textbook approach :)
09:28 jnthn It's basically "you only live twice" semantics
09:28 * brrt should look up the textbook
09:29 jnthn The GC Handbook :)
09:29 brrt hehe
09:29 brrt oh, I should check out if I can still access that by university library now that I can
09:29 * jnthn has it on dead tree
09:29 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
09:31 brrt I do have a PDF of 'Compiler Engineering' from that, though
09:33 brrt of which my only complaint is that it could go a bit further into theory
09:34 timotimo i hope i wasn't out of line to add the valgrind stuff to moar/master
09:35 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
09:36 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:42 lizmat joined #moarvm
09:48 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:50 jnthn Except all the things we're doing with them are O(1)?
09:50 jnthn (In the FSA case, I mean)
09:52 timotimo but following the chain gives us cache misses left right and center
09:53 * timotimo not experienced enough with close-to-hardware stuff to have an accurate discussion :(
09:54 jnthn Yes, but we don't really follow the chain either
09:55 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
09:56 jnthn 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
09:56 jnthn (Since it's the most recently used block of that size)
09:56 jnthn I agree with the general assessment that linked lists are cache-horrible, fwiw.
09:57 nwc10 and also LTA for divide-and-conquer approaches to parallise stuff
09:57 jnthn *nod*
09:57 timotimo can you tell me more specifics about the MVM_barrier we have in place in MVM_fixed_size_alloc?
09:58 timotimo 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
09:58 nwc10 oh the sad irony - functional languages have immutability (which is great conceptually for parallelisation) and then prefer data structures which tank the praciticalies
09:58 jnthn nwc10: There's no free lunch :)
09:59 nwc10 such an excellent feed line. And 2.5 hours too early to point ilmari to
10:01 jnthn "feed line"...I see what you did there... :P
10:01 jnthn timotimo: I think the barrier may be unrequired there at this point
10:01 * timotimo tries removing it
10:02 jnthn Since trycas implies a barriering
10:02 jnthn But looking at the comment there, I think it was once needed
10:04 timotimo i'm doing a tiny measurement right now
10:05 timotimo 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 timotimo it runs for 16.76s in total
10:07 timotimo 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 timotimo it runs for 14.21s in total
10:07 timotimo the difference is a start { say "started" } near the beginning
10:08 timotimo 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:09 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
10:09 brrt i.e. small-scale immutability is unpractical, large-scale can save your day
10:15 * nwc10 waves_ ilmari_
10:19 timotimo spec tests are clean on my machine with the removal of the barrier there
10:49 jnthn I suspect Intel CPUs are probably the worst to test if a barrier is actually needed :)
11:10 dalek joined #moarvm
11:57 brrt joined #moarvm
12:36 nebuchad` joined #moarvm
12:40 moritz_ joined #moarvm
12:52 ggoebel joined #moarvm
12:53 * nwc10 worries that if ilmari doesn't eat, he too will go immutable
12:54 * ilmari is just about to go for lunch, actually
12:55 nwc10 \o/
12:55 nwc10 don't let me stop you
12:55 nwc10 (or anyone else)
13:33 * ilmari is full of tasty burrito
13:49 geekosaur joined #moarvm
16:20 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:28 domidumont joined #moarvm
17:04 JackCode2 joined #moarvm
18:28 FROGGS joined #moarvm
18:31 FROGGS o
18:31 FROGGS o/
18:32 timotimo o
18:57 FROGGS brrt / jnthn: I updated the gist for mips64el: https://gist.github.com/FROGGS/05195d5426cbda9882a9dd00f684de72
19:38 FROGGS the issue seems to be with atomic ops
19:42 FROGGS lemme rebuild moar with debians libatomic-ops -.-
19:45 FROGGS (because there are three mips patches in debians package included)
23:13 dalek joined #moarvm
23:43 arnsholt joined #moarvm
23:46 ilbot3 joined #moarvm
23:46 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary