github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:04 evalable6 joined 01:05 p6bannerbot sets mode: +v evalable6
japhb just donated to the Perl 6 Core Development Fund earmarked for MoarVM & Rakudo work. Hopefully there are still some active grants, or will be more soon. :-) 03:53
AlexDaniel japhb++ 05:06
yeah, there was this exciting proposal recently: news.perlfoundation.org/2018/12/gra...rl-6-.html 05:08
I'm kinda hoping that Kaiepi will do the same wonderful things to networking that samcv did for unicode support :) 05:09
05:30 Ven`` joined, p6bannerbot sets mode: +v Ven`` 05:36 Ven`` left 12:21 leont joined, p6bannerbot sets mode: +v leont 14:01 Ven`` joined, p6bannerbot sets mode: +v Ven`` 14:03 domidumont joined 14:04 p6bannerbot sets mode: +v domidumont
timotimo so jnthn, i've looked briefly into why sub a(--> int) { 42 } being called in a for loop is slower than without the type annotation, and i think perhaps it has something to do with the fact that the log shows only one empty type tuple for the calling frame; i thought the return type was also supposed to be logged, but perhaps some intersection of native return and sinking is causing trouble?! in any case, 14:19
slowness comes from 2x sp_speshresolve being left in the specialized version of a
an idea what i should look into?
the performance regression was bisected to a moarvm bump that has the "log return types in the caller's frame" change to spesh logging
jnthn timotimo: Yes, I'd already mentioned it was due to unresolved spesh plugins on the ticket. And that is in turn because it's making a certain specialization, not an observed type one. Question is why it's doing that. 14:23
timotimo d'oh, that makes sense 14:24
i managed to miss the reply on the ticket :| 14:25
jnthn I guess if there are only 3 MoarVM commits in the bump, working out which one did it should be easy enough 14:27
14:27 Ven`` left
timotimo well, "don't do worthless type specializations" sounds a lot like "this could be why it does a certain specialization only" 14:28
so, some ops not having :specializable could be a thing
timotimo has a quick look 14:29
jnthn afk for a bit, probably going to rest today and get back into things from tomorrow :) 14:30
timotimo well, speshresolve is the one obvious one but it's already marked specializable
so there are definitely specializable ops in there
aha 14:31
"the body contains no specializable instructions", eh?
14:32 Ven`` joined, p6bannerbot sets mode: +v Ven``
timotimo i have a thought 14:44
speshresolve is part of a sequence, and the check for a spesh-able instruction doesn't seem to be triggered for those 14:45
Geth MoarVM: 473324ee38 | (Timo Paulssen)++ | src/core/validation.c
Notice Specializable Instructions Everywhere In Bytecode

otherwise extremely simple frames will end up not getting their spesh plugins specialized, for example
   sub a(--> Int:D) { 42 }; for ^100_000 { a }
Fixes rakudo/rakudo#2573		 15:04
synopsebot RAKUDO#2573 [closed]: github.com/rakudo/rakudo/issues/2573 [audit entire codebase for such issues][consistency] Adding a return type slows execution down
timotimo funny that this would only ever really show differences in frames so small they could mostly only be part of microbenchmarks :D 15:08
jnthn And even there, zero-parameter frames are somewhat unusual :) 15:17
timotimo++
15:19 domidumont left 15:20 domidumont joined, p6bannerbot sets mode: +v domidumont
dogbert11 under what circumstances, if any, can you expect to get the following message: continuationinvoke expects an MVMContinuation 15:21
15:22 domidumont left
dogbert11 the triggering code is located here: github.com/MoarVM/MoarVM/blob/mast...ion.c#L150 15:22
I get it when running github.com/perl6/roast/blob/master...ress-6.d.t on an RPi 2 15:24
timotimo were you able to get the actual REPR and debug_name of the object it got? 15:25
dogbert11 yes, it was a 5, I believe that is P6Opaque 15:26
it doesn't happen every time 15:27
timotimo "a 5"? :) 15:28
like the integer 5?
dogbert11 like this: (gdb) p REPR(cont)->ID
$1 = 5
the expected value is 27 15:29
timotimo oh 15:30
well, REPR(cont)->name could also be good :)
dogbert11 aha, good to know
timotimo and MVM_6model_get_debug_name(cont) is also good
and perhaps it's a container and you can look into it with MVM_dump_p6opaque
(which sometimes crashes) 15:31
dogbert11 aha, let me connect my RPi 2 again and retest
I must be missing something here: (gdb) p MVM_dump_p6opaque(cont) 15:34
Too few arguments in function call.
timotimo may need tc first 15:35
dogbert11 yeah, thx: Scalar.new(#`(from Scalar) $!descriptor=ContainerDescriptor.new(#`(from ContainerDescriptor) $!of=(Mu), $!name='$continuation', $!default=(Any), $!dynamic=0), $!value=(Any))
timotimo ok, so if this output is to be believed, it has nothing in it
dogbert11 which is suspecious 15:36
bad spelling, sigh
would running with --ll-exception help 15:37
timotimo suspeshious
probably not, you'll usually get the same from MVM_dump_backtrace
15:39 lucasb joined, p6bannerbot sets mode: +v lucasb
dogbert11 timotimo: gist.github.com/dogbert17/fccc667f...293c28f16a 15:40
timotimo it'd be more helpful if we could figure out where this value came from 15:41
which is hard without something like rr
does rr run on a raspi2?
dogbert11 don't know although I suspect that it doesn't
I guess it would be better if I managed to replicate this under Linux but as of yet I haven't been able to 15:42
15:43 domidumont joined 15:44 p6bannerbot sets mode: +v domidumont
timotimo true 15:44
15:46 robertle joined 15:47 p6bannerbot sets mode: +v robertle
dogbert11 doesn't fail on Linux. It's getting really hard to find bugs in MoarVM but I guess that's a good thing :) 15:50
16:12 leont left 17:07 Ven` joined 17:08 p6bannerbot sets mode: +v Ven` 17:13 Ven` left 17:49 lucasb left 18:50 zakharyas joined 18:51 p6bannerbot sets mode: +v zakharyas 19:04 leont joined, p6bannerbot sets mode: +v leont 19:08 lizmat left 20:12 domidumont left 20:25 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 20:34 Kaiepi left 20:35 Kaiepi joined 20:36 p6bannerbot sets mode: +v Kaiepi 20:47 lizmat joined, p6bannerbot sets mode: +v lizmat 21:09 zakharyas left 22:29 Ven`` 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!