[00:37] *** AlexDani` joined [00:39] *** AlexDaniel left [01:59] *** Util left [02:22] *** Util joined [08:44] \o [08:49] sjn o/ [08:52] Coveaster hacking! \o/ [09:12] *** Altai-man_ joined [09:22] *** sena_kun joined [09:23] *** Altai-man_ left [09:37] *** angelds joined [11:20] *** angelds left [11:21] *** Altai-man_ joined [11:23] *** sena_kun left [11:35] *** AlexDani` is now known as AlexDaniel [11:35] *** AlexDaniel left [11:35] *** AlexDaniel joined [11:38] *** MasterDuke left [11:41] *** patrickb joined [11:48] *** MasterDuke joined [12:40] *** samcv left [13:22] *** sena_kun joined [13:24] *** Altai-man_ left [13:24] *** zakharyas joined [13:43] *** samcv joined [13:51] *** samcv left [13:53] *** samcv joined [14:20] *** zakharyas left [14:56] *** samcv left [14:56] *** samcv joined [15:21] *** Altai-man_ joined [15:23] *** sena_kun left [15:24] *** colomon left [15:26] *** colomon joined [15:36] *** colomon left [15:38] *** colomon_ joined [16:25] *** zakharyas joined [16:28] i think the profile dumper should probably stop when the recursion depth has exceeded like 20k [16:28] at that point you're very likely in a situation that isn't going well [16:42] timotimo: true. but i also feel like in some/most of those cases the actual code that the profiler is collecting info on is not great [16:49] it's more likely that it's still that nasty bug that causes loops to turn into infinite-depth recursion in the eyes of the profiler [16:57] is it strictly a bug in the profiler? [17:00] or some badly generated/optimized code that the profiler just doesn't handle well? [17:04] it's a bug that i haven't properly figured out, but if i have the right idea, it's that when generating the enter/exit instructions in the code, sometimes there's a path through the routine that skips the exit instruction on the way out [17:05] that sounds very plausible. might explain why when trying to compile big things like the rakudo build i never see it ending profiling [17:22] *** sena_kun joined [17:23] *** Altai-man_ left [18:30] *** vesper11 joined [18:30] who is bored enough to try putting liborc into moarvm? [18:30] it uses meson as its build tool, so have fun with that i guess [18:30] *** vesper11 left [18:31] but it offers an assembly-like language that it can compile to vectorized code targeted at the compile-time or run-time selected architecture, or you can put the programs together with regular C function calls [18:32] it'd be nice to have liborc as optional if it is to be included [18:33] and then having the nqp level check if liborc is there or not and have the alternative implemented simply in nqp [18:36] OTOH, composing a QAST in raku code and compiling it, then running it could already be a nice win for very big arrays being hyperopped [18:50] *** vesper11 joined [19:21] *** Altai-man_ joined [19:23] *** sena_kun left [19:29] oh my, a spesh mystery [19:40] do you have any dogs and/or meddling kids around to help solve it? [19:51] i've been barking up the wrong tree for a little there ... [19:52] MasterDuke++ [19:53] there we go. the self for this method wasn't restricted to :D, that's why the getattr couldn't be speshed [19:54] and it's a certain optimization, possibly because it's only got osr hits [19:55] what are you optimizing? [19:56] was looking a bit into our hyperop implementation [19:58] cool [19:59] if there were a nice little spot where i could say "we have an int array on both sides and a simple operator from the setting, so let's use a more optimized approach here" [20:00] and then i stumbled upon a getattr_o that was looking like it should have been optimized [20:00] and i didn't see why until i put in more debug info [20:01] now i'm storing an extra integer in spesh comment annotations that stores the order in which they were added [20:03] what does that tell you? [20:05] i wanted to make sure it was doing the one thing that i saw before the other thing that i saw [20:05] because i was being misled by buggy debug output :) [20:07] i'll post an example [20:07] https://gist.github.com/timo/f247d9ccef1fd36a2d0626e4a70400f4 [20:09] it also gives a hint for stuff that has been deleted by spesh, since the comment numbers will have a gap [20:10] theoretically i could save them up and display them after the graph with what they used to attach to [20:19] huh, interesting [20:48] *** zakharyas1 joined [20:50] *** zakharyas left [21:22] *** sena_kun joined [21:23] *** Altai-man_ left [21:30] *** zakharyas1 left [21:57] *** patrickb left [23:21] *** Altai-man_ joined [23:23] *** sena_kun left