github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:22 sena_kun joined 01:23 Altai-man_ left 03:08 linkable6 left, evalable6 left 03:10 evalable6 joined 03:11 linkable6 joined 03:21 Altai-man_ joined 03:23 sena_kun left 05:22 sena_kun joined 05:23 Altai-man_ left 07:21 Altai-man_ joined 07:23 sena_kun left 08:35 Geth_ joined, Geth left 09:05 Voldenet joined, Voldenet left, Voldenet joined 09:22 sena_kun joined 09:24 Altai-man_ left
nwc10 good *, #moarvm 09:27
timotimo heyo nwc10 10:46
11:20 Kaiepi left 11:21 Altai-man_ joined 11:24 sena_kun left 11:25 Kaiepi joined 12:11 Kaiepi left 12:13 Kaiepi joined 12:21 brrt joined
brrt ohai #moarvm 12:21
Altai-man_ Anyone around to explain me what can I use to catch why github.com/MoarVM/MoarVM/blob/mast...rp.c#L2529 fails in my very non-golfable code?
brrt, o/
brrt hi Altai-man_
I could tell you I'd like to take a look, but I'm fairly sure I wouldn't be able to help much 12:22
Altai-man_ I'd borrow help even from a cat hand. :) 12:23
brrt show me the code pls 12:24
Altai-man_ brrt, would you hesitate if it requires doing some clonning? 12:25
Because there are a lot of code in different repos, but the error is 100% reliable. :S 12:26
the instructions are at github.com/rakudo/rakudo/issues/3579
brrt Altai-man_: I'm sorry, that is likely to take more time than I have today
Altai-man_ brrt, then never mind me, sorry for taking it. 12:27
brrt no problem at all :-)
I mean, it's always okay to ask, and on another day I might be able to help you
Altai-man_ Golfed it down to only require cro and golfed file, github.com/rakudo/rakudo/issues/3579 12:38
brrt Altai-man_++ 12:39
Altai-man_ m: use nqp; my $code = start { my $c := nqp::getcomp('Raku'); my $g := nqp::findmethod($c,'parsegrammar')($c); my $actions := nqp::findmethod($c,'parseactions')($c); $g.parse('', :p(0), :$actions); }; await $code; 12:56
camelia An operation first awaited:
in block <unit> at <tmp> line 1

Died with the exception:
existskey requires a concrete object (got a NQPMu type object instead)
in block at <tmp> line 1
Altai-man_ m: use nqp; my $code = { my $c := nqp::getcomp('Raku'); my $g := nqp::findmethod($c,'parsegrammar')($c); my $actions := nqp::findmethod($c,'parseactions')($c); $g.parse('', :p(0), :$actions); }; say $code;
camelia -> ;; $_? is raw = OUTER::<$_> { #`(Block|68023728) ... }
Altai-man_ 210 characters golf without extra dependencies is what I got. \o/
brrt that's not so bad 12:57
MasterDuke Altai-man_++
Altai-man_ But now I have no idea where to look next. 12:58
timotimo i've made a whole trip through the stages of grief regarding vectorization in moarvm 13:09
13:22 sena_kun joined
brrt tell us timotimo 13:23
13:24 Altai-man_ left
timotimo well, i started with my old branch that introduced a vectorapply op that does simple things like elementwise add or multiply two integer or num arrays 13:26
next up, loop fusing was really important to me, so that we can @a >>+<< @b >>*>> 5 in one go instead of two 13:27
but building a huge .c file with implementations of like sixty different formulas with type combinations of different-sized ints and nums would suck; it'd likely result in a humongous object file, and be much generating to do 13:28
but dynasm can emit mmx and sse ops
for that we'd need a tiny IR that nqp can toss at moarvm, which then compiles a piece of runnable code to apply to a bunch of VMArrays 13:29
to build something completely new sounds like a really bad idea
so i looked into orc, which i saw the last time i was on this topic, but didn't look any closer
it has both a text-based asm-like input format of its own, as well as a set of C functions you can call to put a program in their IR together 13:30
and then it generates the stuff at run-time if you want, or you use orcc to compile stuff ahead-of-time into .c files or whatever
but i think that doesn't have an optimizer of its own 13:31
so i looked into what llvm has in terms of vectorization stuff
let's just say "it's a lot"
so yeah 13:32
i'll just do nothing instead
the first step in this whole process is to pick apart and put together formulas that use many hypers, rather than immediately executing them 13:33
and when we have that, we can just as well start by writing out loop-fused and perhaps even tiled nqp code
so it doesn't have to go indirectly through, for example, self.infix and such, which may not be inlined
13:38 brrt left
Geth_ MoarVM: MasterDuke17++ created pull request #1267:
Let encode take a preallocated buffer		 13:41
13:48 Altai-man_ joined 13:51 sena_kun left
MasterDuke timotimo: any idea how to further debug or fix that profiler problem? 14:17
nine timotimo: reads like you've taken on a humongous task and made some decent progress on the initial research 14:33
timotimo flails helplessly 14:43
15:03 colomon___ joined 15:05 colomon_ left
MasterDuke there are a whole ton of bind_key's when building rakudo, and the vast majority of them end up taking the slow path in alloc_from_global. any idea why that would be (i.e., why they would have failed to take from the free list)? 15:27
15:49 sena_kun joined 15:51 Altai-man_ left
jnthn MasterDuke: Empty free list? 17:15
A lot of the hashes will almost certainly live for a long time because they're part of the QAST tree
sena_kun jnthn, around for taking a peek at a bug or just chillin'? 17:19
jnthn sena_kun: Mostly chilling. Hoping to receive dinner soon... :) 17:31
sena_kun jnthn, enjoy it, nine++ provided a workaround for this bizarre ticket. :) 17:32
jnthn Is it the existskey one? :)
sena_kun yeah 17:33
At least I've exercised in golfing and grepping rakudo sources. :) 17:34
17:48 Altai-man_ joined 17:50 sena_kun left
MasterDuke jnthn: bind_key calls the fsa here github.com/MoarVM/MoarVM/blob/mast...ash.c#L103 and a large number of the calls end up here github.com/MoarVM/MoarVM/blob/mast...loc.c#L174 18:40
19:01 patrickb joined 19:33 vrurg left, vrurg_ joined 19:36 vrurg_ left 19:39 vrurg joined 19:49 sena_kun joined 19:50 Altai-man_ left 19:52 vrurg_ joined 19:53 vrurg left 19:57 colomon___ left 19:58 colomon joined
nine Oh, we have VALGRIND_MEMPOOL_ALLOC annotations in place already? Those can be used by heaptrack by just adding a #include <heaptrack_api.h> 20:00
20:03 patrickb left
MasterDuke just tried that, not sure what would/should be different about the output, seems pretty similar 20:09
timotimo oh, really 20:14
MasterDuke you know, it's not just most, but heaptrack is showing *all* calls from bind_key going through `alloc_slow_path`
timotimo did you also turn on valgrind support using Configure.pl?
MasterDuke --valgrind
timotimo also, it's possible that the defines for valgrind support trample the heaptrack api stuff 20:15
wait, those are only defines if valgrind support is off maybe?
nine Oh wait, there's #ifdef HEAPTRACK_DEFINE_VALGRIND_MACROS
phabricator.kde.org/source/heaptra..._api.h$158
20:16 patrickb joined
nine So you also need to define that to get the heaptrack integration via valgrind macros 20:16
MasterDuke hm, i added `#define HEAPTRACK_DEFINE_VALGRIND_MACROS; #include "heaptrack_api.h"` to src/core/fixedsizealloc.c, but it still doesn't seem to have changed much 20:21
oh wait 20:22
before had 26.6m calls to allocation functions and 4.2m temp allocations. after had 43.9 calls to allocation functions and 3.5m temp allocations 20:24
oh, and after has more entries in peak contributions, most memory allocations, etc 20:26
so looks like it does help out some
20:28 vrurg_ left 20:29 vrurg joined
timotimo pasting stuff into the godbolt compiler explorer is tricky when everything uses MVMObject and MVMThreadContext 20:37
MasterDuke does it let you add any .h's? 20:40
timotimo not sure if it allows me to add multiple files at once 20:47
MasterDuke cat them all into one? 20:49
timotimo uargh :) :) 20:54
anyway. no vector ops being used in this one loop i'm just looking at. huh. 20:55
perhaps i'd have to put in a check that the addresses of the arrays are aligned sufficiently 20:56
MasterDuke just writing some "plain C" loops? or using liborc? 20:57
20:58 zakharyas joined
timotimo plain C 21:01
stolen from my vectorization branch
i see the big checks for proper pointer alignment that chloekek (iirc) mentioned the other day
oh, OK, i think i see what's wrong
the pieces are so far apart in the assembly that i just didn't see it 21:02
i don't see a way to go from a line in the assembler to a line in the editor or vice versa
all i see is when you hover one it'll highlight on the other side, but only in the part you've scrolled to, not in the minimap
d'oh
right-click -> scroll to source is one way
21:03 zakharyas left 21:41 patrickb left 21:48 Altai-man_ joined 21:50 sena_kun left 23:49 sena_kun joined 23:50 Altai-man_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!