Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-06-09

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

All times shown according to UTC.

Time Nick Message
00:34 dalek joined #moarvm
01:48 FROGGS_ joined #moarvm
02:21 raiph joined #moarvm
02:27 raiph maybe of interest in years to come: "deterministic garbage collection algorithm that supports RAII (initialism) directly, evenin the case of recursive graphs of objects" https://www.reddit.com/r/ProgrammingLanguages/comments/4n4i5i/deterministic_garbage_collection/
06:29 rurban_ joined #moarvm
07:03 zakharyas joined #moarvm
08:28 * jnthn wonders what trade-offs it makes to do that :)
08:35 konobi there was that memory allocation and gc paper from a while back
09:20 nine The programming language uses atomic reference counts along with an algorithm that detects and identifies the unique set of objects in a recursive graph of objects by performing graph scans in real-time, and then, when the last reference from an object outside the graph is removed (meaning that there are only references from objects that participate in the graph), the object being dereferenced is then destroyed, which causes a chain reaction which causes all obj
09:20 nine from the paper's announcement
09:20 jnthn heh, atomic reference counts :)
09:20 jnthn We ripped those out of MoarVM last month :)
09:21 jnthn Interesting idea, though.
09:22 jnthn (The real-time graph scans, I mean)
10:43 retupmoca joined #moarvm
10:59 colomon joined #moarvm
11:06 cognominal joined #moarvm
11:35 rurban_ joined #moarvm
11:49 lizmat jnthn: is there a reason we don't have any nqp::inc_i($a) / nqp::dec_i($b) ops ?
11:50 lizmat (basically providing prefix ++ and --_
11:50 lizmat )
11:50 lizmat I was just wondering
11:58 jnthn Various reasons, among them working out what they should actually do :)
11:58 jnthn Note that they'd want to update their arg, but the way you want the do that in NQP vs Perl 6 aren't the same
11:59 jnthn Then it's not clear if pre or post inc/dec semantics are wanted
12:05 lizmat to me, pre inc semantics are clear  :-)
12:05 jnthn That's 'cus it's what you want at the moment :P
12:06 lizmat true
12:06 jnthn The "how should they even work2 is the bigger issue though.
12:06 lizmat ok, I got an answer  :-)
12:06 lizmat it just felt like such an omission to me
12:06 lizmat and having them (in whatever way) would prove to be an easier optimization target, no ?
12:07 jnthn "It's complicated" :)
12:08 jnthn Note that it'd need to care about, say, attributes too
12:08 jnthn Where you need to compile it into a read/add/write
12:08 jnthn So it'd need case analysis to compile
12:08 lizmat ok, in my limited view, nqp::inc_i() would ever only take native ints
12:09 jnthn What's a native int? :)
12:09 lizmat ok, gotcha  :-)
12:09 jnthn Or more to the point: if it only *takes*, then it can't update :)
12:09 jnthn That's why it gets tricky
12:09 lizmat I guess I was just thinking it essentially takes a pointer and does an inc there  :-)
12:10 jnthn Well, it "could" by demanding an Int*Ref
12:10 jnthn Then we'd not like that and so end up trying to special-case it in various cases :)
12:11 lizmat ok, I get the "it's complicated"  :-)
12:12 jnthn I guess the kicker really being that, after all that work, it's not entirely clear that post-JIT we'd have better code anyway. :-)
12:12 nwc10 or even post-spesh?
12:12 jnthn Or possibly that
13:05 domidumont joined #moarvm
13:10 cognominal joined #moarvm
13:21 dalek MoarVM: 27fccc1 | (Will Coleda)++ | build/ (2 files):
13:21 dalek MoarVM: Smoke me/spaceybuild (#375)
13:21 dalek MoarVM:
13:21 dalek MoarVM: Make build in dir containing space work
13:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/27fccc198d
13:26 nwc10 [Coke]: sorry, no, I didn't test that earlier. I slack
13:26 nwc10 I have now. It works.
13:26 nwc10 Thanks
13:31 [Coke] no worries.
13:35 colomon joined #moarvm
14:12 cognominal joined #moarvm
14:56 timotimo this is an interesting crash
14:56 timotimo 0x00007ffff7959557 in MVM_spesh_osr (tc=0x6037c0) at src/spesh/osr.c:46
14:56 timotimo 46     if (!tc->cur_frame->params.callsite->is_interned)
14:57 timotimo (gdb) print tc->cur_frame->params
14:57 timotimo $3 = {callsite = 0x0, arg_flags = 0x0, args = 0x0, named_used = 0x0, named_used_size = 0, arg_count = 0,
14:57 timotimo num_pos = 0, flag_count = 0}
14:57 timotimo i can easily put a null check in there, but what's the actual meaning of .params being completely nulled out?
14:57 jnthn Sounds rather busted
14:57 jnthn Outdated pointer maybe?
14:58 timotimo (gdb) print MVM_dump_backtrace(tc)
14:58 timotimo at <unknown>:1  (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:count-only)
14:58 timotimo from gen/moar/m-CORE.setting:13144  (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:elems)
14:58 timotimo from triangle-numbers.p6:9  (<ephemeral file>:)
14:58 timotimo i can try running it in valgrind to see if it messes with some data
14:59 timotimo that'll take forever, of course.
14:59 jnthn yeah
14:59 jnthn That should probably never be NULL for something on the call stack...
15:36 timotimo valgrind only reports the invalid read that also triggers the segfault, it seems like
15:51 domidumont joined #moarvm
16:14 rurban_ joined #moarvm
17:34 patrickz joined #moarvm
17:38 raiph joined #moarvm
18:00 cognominal joined #moarvm
19:16 FROGGS joined #moarvm
20:01 zakharyas joined #moarvm
20:57 raiph left #moarvm
21:41 timotimo https://www.youtube.com/watch?v=P3AyI_u66Bw  -  "removing the python GIL"; someone's working on a project called "gilectomy" (used to be "Confuse-A-Cat"), and it looks interesting
21:44 timotimo it seems like that approach adds one user-space lock per list, and per dict, and so on
21:53 timotimo ouch. atomic incr and decr on every single object
21:53 timotimo makes it incredibly slow compared to cpython with the gil
22:38 arnsholt timotimo: Yeah, that's the problem with removing the GIL
22:39 arnsholt The CPython team look pretty committed to refcounting for the GC, both since having the implementation internals being simple is a goal for them as well as the fact that breaking *all* of the C extensions would be pretty crap
22:46 timotimo that's also explained in that very talk :)
22:55 arnsholt Yeah, he covers it very well
22:55 arnsholt It'll be interesting to see what they come up with to kill off the GIL
22:56 timotimo yup
22:56 arnsholt I think they'll probably figure it out eventually, but I am pretty curious how they're going to do it
23:05 timotimo yeah
23:05 timotimo i wish pypy's STM effort would have gotten further by now
23:05 timotimo or even by last year. or two years ago.
23:06 timotimo before i came over to perl6 i was quite the pypy fanboy :)
23:06 timotimo and i still think their project is just absolutely awesome
23:06 timotimo i do find rakudo a bit simpler to develop for, though
23:06 timotimo at least by now :D
23:07 timotimo rpython had some really difficult to figure out failure modes
23:07 timotimo or maybe i was just an expert at messing up in all different kinds of ways
23:15 arnsholt PyPy is awesome
23:15 arnsholt It saved my skin on some Python code a while back
23:16 arnsholt Actually, one of the PyPy devs dropped by #perl6 at some point, trying to convince us that Rakudo should've targetted rpython rather than JVM/Moar
23:16 timotimo well, i kind of asked him about advice
23:18 arnsholt Ah, right

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