Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-05-08

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

All times shown according to UTC.

Time Nick Message
01:06 colomon joined #moarvm
02:22 colomon joined #moarvm
07:04 domidumont joined #moarvm
07:09 domidumont joined #moarvm
09:17 Ven joined #moarvm
11:06 Ven joined #moarvm
11:52 colomon joined #moarvm
12:01 vendethiel joined #moarvm
12:04 colomon joined #moarvm
12:45 Ven joined #moarvm
12:57 colomon joined #moarvm
13:15 zakharyas joined #moarvm
13:24 colomon joined #moarvm
13:39 colomon joined #moarvm
14:06 ZoffixWin joined #moarvm
14:07 ZoffixWin Hey. Someone told me I need some sort of flag to enable before attempting to use valgrind, because I'd get false positives otherwise.... what's that flag and how do I set it?
14:08 timotimo you just have to run moar with --full-cleanup
14:15 ZoffixWin I actually see perl6-valgrind-m in rakudobrew bin
14:15 timotimo yeah
14:15 timotimo but it doesn't set --full-cleanup
14:15 timotimo because nobody put it in yet
14:15 timotimo *hint hint*
14:16 ZoffixWin But I've no idea how to put in --full-cleanup. All these scripts are some sort of a Perl 5 script :/
14:17 ZoffixWin nm
14:18 timotimo just cat it and run it by hand
14:24 ZoffixWin Adding --full-cleanup produces segmentation fault: https://gist.github.com/zoffixznet/c9951c32dbb4dfa07cd2d32bef733f73
14:26 timotimo where is that segmentation fault? :o
14:27 timotimo aaw, you have your moar built without --debug
14:27 ZoffixWin Oh
14:28 timotimo turns out we destroy the nfg stuff after the fixed size allocator got destroyed
14:28 timotimo so when i move fsa_destroy after nfg_destroy, it should not give you any errors any more.
14:29 * timotimo tries it out
14:29 timotimo great, it doesn't give any errors any more
14:30 * ZoffixWin has no idea what any of that means...
14:30 dalek MoarVM: f98914f | timotimo++ | src/moar.c:
14:30 dalek MoarVM: the NFG uses the FSA, so have to destroy FSA after NFG.
14:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f98914f8e7
14:30 timotimo :)
14:30 timotimo just that the error was helpful and very simple
14:31 timotimo but also rather harmless
14:31 ZoffixWin So, do I still need to rebuild with --debug to get --full-cleanup to work?
14:31 ZoffixWin Or is the fix you just pushed the fix for the segmentation fault?
14:31 timotimo no, but it'll give better tracebacks in valgrind
14:32 timotimo it fixes the errors you got, yeah
14:32 timotimo was it really a segmentation fault?
14:32 ZoffixWin I see 'Segmentation fault' on this line: https://gist.github.com/zoffixznet/c9951c32dbb4dfa07cd2d32bef733f73#file-bash-L20
14:32 timotimo oh! haha
14:32 timotimo that's just for saying the banner up top
14:33 timotimo that one didn't need --full-cleanup, but it's probably fixed now
14:35 timotimo thanks for the tip in any case :)
14:51 Ven joined #moarvm
15:29 dalek MoarVM: be10119 | timotimo++ | src/moar.c:
15:29 dalek MoarVM: close dynvar log filehandle in instance destroy
15:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/be10119506
15:29 dalek MoarVM: e240e75 | timotimo++ | src/moar.c:
15:29 dalek MoarVM: cross thread write logging has a mutex. close it.
15:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e240e75323
15:29 timotimo ^- not worth a lot, but cheap to do
15:37 timotimo the heap collection subsystem doesn't offer a way to destroy the data without creating the output yet; we might want to have a "cancel heap snapshot mode" function that just destroys the heap snapshot data that belongs to an instance
16:06 cognominal joined #moarvm
17:44 cognominal joined #moarvm
19:04 moritz https://www.reddit.com/r/ProgrammingLanguages/comments/4i8t3f/is_luajit_ir_a_reasonable_target/ looks like it could do from some input from MoarVM deleopers :-)
19:05 moritz erm, that no grammar
19:05 moritz some input would be beneficial to that thread :-)
19:07 geekosaur s/do from/do with/ ?
19:08 timotimo well, we only use dynasm, which is a shared dependency between our stuff and luajit's stuff now
19:08 timotimo the luajit IR isn't really similar to what we target, i don't think
19:09 moritz oh
19:09 jnthn Also, luajit doesn't use dynasm for its JIT, afaik, just for its hand-coded interpreters.
19:10 jnthn (I think this is true of luajit 2, and luajit 1 did use dynasm for its JIT also)
19:12 timotimo oh, interesting
19:37 zakharyas joined #moarvm
21:56 timotimo MadcapJake: do note, however, that the multi-core version spends about 50% total time contending for a lock on one of our allocators
21:58 MadcapJake could you elaborate a bit? Is this the $input-channel.list that you're speaking of?
21:58 timotimo no
21:59 timotimo just internal stuff. the thing in question here is the Fixed Size Allocator, which we currently use to allocate every single call frame
22:00 timotimo so basically, the threads are fighting to be allowed to invoke subs
22:00 timotimo if we could be invoking less stuff, i.E. have fewer curlies or somehow make the optimizers better able to inline stuff, it wouldn't be as bad
22:00 timotimo alternatively, we wait for jnthn's current refactoring work. on this particular code, the partial refactor still crashes.
22:05 MadcapJake interesting! Nice to hear the current refactor will address this.  Though I'm not quite grasping how.
22:14 timotimo want me to explain what jnthn is up to?
22:15 timotimo his own blog posts can probably explain better than me, but i can answer questions
22:21 MadcapJake i've read them actually, but I've not quite comprehended them :) isn't the big idea that call frames will be gc-able and reference counting will go away? (probably way off on that :P)
22:28 timotimo right, but with the added thing that whenever we know for a fact that a bunch of frames will all be ref-counted-1, we can have them in a cheaper storage than GC-managed
22:28 timotimo and only when a frame escapes, it'll be migrated to GC storage
22:30 timotimo that'll also likely mean we'll be allocating things in a per-thread rather than shared pool
22:30 timotimo meaning all the contention in multi-threaded situations will also go away
22:31 MadcapJake wow nice!
22:49 diakopter joined #moarvm
22:53 timotimo well, of course not all, as in all
22:54 timotimo but the big one will be gone. the one where every new call frame has to go through one central resource

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