github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:11 Kaiepi joined 00:45 patrickz joined 00:48 patrickb left 00:53 lucasb left
MasterDuke huh. running rindolph's example with 2018.12 gives 5,262,372 calls to `identity`, but HEAD gives 6,473,672. the profiles are relatively similar otherwise 01:02
01:51 patrickz left 02:40 Kaiepi left 02:41 Kaiepi joined 04:45 AlexDani` joined 04:50 AlexDaniel left 04:51 AlexDani` is now known as AlexDaniel
AlexDaniel samcv: what about now? Any ETA? BTW we should probably call it 2018.03 :) 05:26
samcv AlexDaniel, should be pretty soon 09:01
we can call it 2018.03 if you want
working on the changelog now 09:02
09:03 MasterDuke left 09:32 Kaiepi left 10:17 brrt joined 10:28 brrt left 11:42 Kaiepi joined 11:50 brrt joined
samcv jnthn, how do you want me to explain the PEA and new bytecode format 12:02
otherwise i have the changelog mostly ready to go
brrt do we have a new bytecode format? 12:05
samcv well. for this release- 12:06
idk version 6
idk if it's activated yet though
timotimo i believe it's there so that lexicals that have been lowered to locals retain their names
brrt aha 12:15
12:30 brrt left 13:11 patrickb joined 13:20 lucasb joined
timotimo samcv: maybe for PEA try something like "new partial escape analysis allows objects to be replaced by registers if they only escape sometimes"? that's not worded very well and probably doesn't fit the style of the changelog? 15:09
16:05 Kaiepi left
AlexDaniel samcv: yeah 2018.03 is probably the right name for it… I'm not going to do another one this month anyway 17:02
17:14 brrt joined 17:19 MasterDuke joined 17:20 MasterDuke left, MasterDuke joined
MasterDuke timotimo: do you know anything about src/core/continuation.c ? 17:50
timotimo barely 17:58
MasterDuke did you see when i was asking jnthn about gather/take and he mentioned an optimization might have been lost? 17:59
he said something about adding some instrumentation to continuation.c to diagnose, but i'm looking at it and nothing is jumping out at me 18:00
m: my $s = now; my $a = gather for ^500_000 { take $_ }; say now - $s; $s = now; say $a.elems; say now - $s
camelia 0.0014672
500000
2.532751		 18:01
MasterDuke m: my $s = now; my $a = gather for ^500_000 { take $_ }; say now - $s; $s = now; say $a.eager.elems; say now - $s
camelia 0.00143321
500000
2.8058064
18:01 Kaiepi joined
MasterDuke if i understood him correctly, the second should have been faster 18:01
timotimo mhm 18:05
yeah, if we eagerly exhaust the gather operator, it'll just run the code with an implementation of "take" that just pushes into the resulting list and never does continuationy stuff at all
at least that's what i think it does
the instrumentation he mentioned might just be fprints to see how often the continuation ops are called? 18:06
MasterDuke m: my $s = now; my $a = gather for ^500_000 { take $_ }; say now - $s; my int $b; $s = now; $b = $b + 1 for $a.list; say $b; say now - $s 18:08
camelia 0.001417
500000
3.1743836
MasterDuke hm, that's a little longer than just the .elems call, but might just be the math 18:09
timotimo do i want to investigate why my own implementation of readInt64 outperforms @thebuf.read-int64 + splice-ing off the first 8 bytes? 18:10
nine I'd like you to :) 18:14
timotimo nnnnoooooooooooo
:P
could just be that my own implementation is directly with nqp ops 18:15
and .read-int64 is a method call that might not be inlined or something
MasterDuke huh, a profile of all three versions shows that push-all (src/core/Any-iterable-methods.pm6:405) isn't getting jitted. but a spesh log only has one "bailed completely" and that's in `SET_BLOCK_OUTER_CTX` 18:16
timotimo OK, first of all the read-int64 method isn't jitted at all because it stumbles over param_op_o
18:19 domidumont joined
timotimo and the splice method isn't inlined because it has a :noinline op (which may or may not be the getlexref it has) 18:19
so in conclusion, my own implementation has no method calls left inside it and is pretty much perfectly jitted 18:20
whereas the other implementation has not only the read-uint64 (or read-int64) with "just" fastinvoke, but also the splice method call
MasterDuke weird, push-all has 500001 entries in the profile, but is only mentioned once in the spesh log: `Latest statistics for 'push-all' (cuid: 1796, file: SETTING::src/core/Any-iterable-methods.pm6:405) Total hits: 1 OSR hits: 2` 18:22
never shows up againt
brrt what bugs me about gather/take is that it isn't a compile-time transformation 18:23
MasterDuke brrt: into an Iterator?
brrt for example 18:24
timotimo you mean turning the code into continuation-passing style broken up everywhere there is a "take"? 18:29
18:30 bartolin left, bartolin joined
brrt for another example, yes 18:30
:-)
timotimo how would it be in the other case?
it already takes the block and stashes it into an iterator object as far as i know? 18:31
brrt well, why does that have to be a reified object?
timotimo because state? 18:32
brrt that can be compiled into (unnamed) local variables 18:33
maybe there's something about perl6 that makes this impossible though
timotimo it'll have to be state variables bound to some block, right? 18:34
MasterDuke brrt: any idea why this particular example isn't jitting?
brrt I think so timotimo
what example MasterDuke
MasterDuke m: my $s = now; my $a = gather for ^500_000 { take $_ }; say now - $s; $s = now; say $a.elems; say now - $s 18:35
brrt (and the general answer is 'no, but the spesh log should)
camelia 0.0014138
500000
2.4203322
MasterDuke m: my $s = now; my $a = gather for ^500_000 { take $_ }; say now - $s; $s = now; say $a.eager.elems; say now - $s
camelia 0.00151292
500000
2.52303345
MasterDuke m: my $s = now; my $a = gather for ^500_000 { take $_ }; say now - $s; my int $b; $s = now; $b = $b + 1 for $a.list; say $b; say now - $s
camelia 0.0013835
500000
4.1368095
MasterDuke brrt: the spesh log only shows one "bailed completely", and that's in `SET_BLOCK_OUTER_CTX` 18:36
brrt and... it doesn't say why?
or what instruction?
it ought to annotate that to a specific instruction usually
MasterDuke # JIT: bailed completely because of <ctxouter>
brrt well, there you go
I don't recall the exact reason, but there was a reason ctxouter didn't work. 18:37
MasterDuke but why is push-all (what the profile shows isn't getting jitted), only mentioned in the spesh log once?
brrt although, I also recall that jnthn wrote an interface to make it work
timotimo look closer, brrt; that bail is in what should be an unrelated function
brrt but, I don't know which of those should be associated and which should not 18:38
if it's not actually speshed, then it surely won't be JITted either 18:39
MasterDuke but why wouldn't it be speshed? the profile says 500k entries for it 18:40
brrt idk
timotimo i hope the profiler instrumentation doesn't confuse it 18:41
MasterDuke but i made the spesh log when not profiling 18:42
timotimo: or are you saying it was in fact only called once (like the spesh log shows), not 500k times like the profile shows? 18:43
timotimo maybe when profiling the decisions it made regarding jitting or inlining changed? 18:45
MasterDuke timotimo: this seems like a good place to try the remote debugger support in comma 18:46
timotimo that doesn't know anything about the inner workings of the jit, though? 18:47
at some point i hope the remote debugger will allow spesh to be introspected somewhat, but that point is not there yet
MasterDuke but i can at least confirm that that push-all is being called more than once without recompiling rakudo, right? 18:48
timotimo oh 18:49
yeah, that's true
i'm not sure if Comma offers the "count but don't suspend" behavior for breakpoints
MasterDuke hm, not sure how to run a script 18:50
ok, got it running. how do i set a breakpoint inside rakudo? 18:52
timotimo probably possible to just have a run configuration in any unrelated project and point it to the script file
oh, huh, actually that's a very good question
yeah, i'm not sure if there is a way unless you have the file in the right spot inside your program 18:56
probably relative to the script's working directory path?
personally, i always have to turn on debugspam to get the filenames, but later on there really ought to be a matching API 18:57
whether it be "moar sends filenames as they become known and the client can decide whether to react to them or not" or some kind of globbing implemented in moar itself
MasterDuke not sure what you mean by "have the file in the right spot inside your program"? you mean set a breakpoint on "../../rakudo/src/core/<foo>.pm6" for example? 18:59
also, i started suspended, but the run/resume button is greyed out 19:02
timotimo you will need a folder named "SETTING::src" where things live so that the path matches between what the debugserver has and what comma offers 19:07
MasterDuke ah, guess i'll just make that a symlink to my rakudo sources 19:09
timotimo i hope that works :)
try setting the MDS_PROTOCOL env var in the run configuration
that ought to let you know what file names/paths are being used by both sides
MasterDuke ok, i see more output. but all the debug command (e.g., step over) are greyed out 19:12
timotimo that's weird
MasterDuke this is what i see in the console gist.github.com/MasterDuke17/6f59b...144fb99e67 19:13
timotimo right. now why wouldn't comma be able to debug stuff? it already successfully connected so it can't be that 19:19
MasterDuke things seem to work if i don't start suspended 19:25
timotimo i hope it doesn't try to use a full path for the SETTING:: stuff 19:30
MasterDuke i tried adding SETTING::src symlink in the project directory, i can open up files, but a breakpoint i added isn't getting hit 19:31
created new file entry at 0 for /home/dan/CommaProjects/gt/SETTING::src/core/Any-iterable-methods.pm6 19:32
brrt question: do I convert all conditional forms to a single 'cond' construct. or, do I not 19:36
the pro: a single 'cond' is easy to analyze
well, somewhat easy
19:37 brrt left
timotimo MasterDuke: damn. then you'll have to use the commandline debugger for now :( 19:39
MasterDuke ah well, hopefully a feature to be added eventually 19:40
19:40 brrt joined
timotimo will have to think of a UI for it that makes sense, though perhaps it'll actually just allow you to open core setting source files if your "SDK" comes with sources 19:41
brrt the con: I need to be clever in the emitting of the conditional targets, if they are duplicated
timotimo and offer to pull the sources from github if it doesn't
MasterDuke huh! recompiled rakudo with a print at the top of that print-all. only prints once 19:42
timotimo well, that's ominous 19:43
MasterDuke and still only prints once when being profiled, but the profile says 500k entries 19:45
timotimo can you breakpoint it in gdb? 19:47
like, using sin() or something like that?
hm. though the next step would be to dump its bytecode, i'm not sure if that'll actually hlep
19:49 domidumont left 19:50 brrt left 19:52 greppable6 left, releasable6 left, unicodable6 left, nativecallable6 left, shareable6 left, committable6 left, squashable6 left, reportable6 left 19:53 evalable6 left, evalable6 joined, domidumont joined 19:59 domidumont left
MasterDuke timotimo: MVM_dump_bytecode(tc) in push-all? 20:13
gist.github.com/MasterDuke17/4ebde...17dfd3b3d6 20:16
timotimo no prof ops at all, huh? 20:35
MasterDuke oh, that wasn't while profiling. i can run again with 20:36
timotimo might also be interesting to compare the two
i see it does osr. does it also deopt a lot according to the profile?
MasterDuke gist updated 20:37
pull-one SETTING::src/core/Rakudo/Iterator.pm6:1765 498271 pull-one SETTING::src/core/Rakudo/Iterator.pm6:1881 1 20:38
timotimo that's deopts?
MasterDuke yeah
timotimo and OSRs? 20:39
MasterDuke push-all SETTING::src/core/Iterator.pm6:55 498195
timotimo OK, maybe it counts OSRing as entries 20:40
there's something to log deopts, it could help figure out how far it gets in the bytecode before it hits the deopt
i.e. if it only does like five ops before it's deopted again
MasterDuke src/spesh/deopt.c:7:#define MVM_LOG_DEOPTS 0 20:41
timotimo that should be the one 20:42
MasterDuke gist updated 20:44
timotimo was it push-all that we thought wasn't being jitted or was it pull-one? 20:45
MasterDuke push-all
push-all is the one that also shows 500k entries in the profile, but is actually only being called once 20:46
timotimo so it does jit push-all, it just doesn't count it
the spesh log would have info about the deopt index 396 that it's complaining about, but i don't know under what circumstances that message would appear 20:47
MasterDuke reran with a spesh log, so the number changed. `Latest statistics for 'add-option' (cuid: 186, file: gen/moar/stage2/NQPHLL.nqp:2382)` 20:49
20:49 reportable6 joined, committable6 joined
timotimo that was grepping for 186? 20:49
20:50 greppable6 joined
MasterDuke there are other hits, looking for anything in particular? 20:50
20:50 shareable6 joined, unicodable6 joined 20:51 nativecallable6 joined, releasable6 joined 20:52 squashable6 joined
timotimo for the deopts of pull-one and push-all we would have to find an annotation in pull-one's or push-all's bytecode 20:53
MasterDuke with that id?
timotimo should be 1396 and 886 20:54
the cuuids or cuids
i think we're not using one or the other uniformly
MasterDuke i think cuuid is just in some method names 20:55
`Latest statistics for 'cuuid-idx' (cuid: 94, file: /home/dan/Source/perl6/install/bin/../share/nqp/lib/MAST/Nodes.nqp:1059)`
timotimo OK
MasterDuke huh. the deopt log is different when i also was creating the spesh log 20:56
doesn't have this line: ` 498161 Recreated frame 'pull-one' (cuid '1396')`
timotimo spesh log printing slows down the spesh thread, but it shouldn't be that much 20:57
MasterDuke man, a whole lot of things had `Latest statistics for ...` 450-457 times 21:01
of which 1396 was one 21:02
` 451 Latest statistics for 'pull-one' (cuid: 1396, file: SETTING::src/core/Rakudo/Iterator.pm6:1765)`
timotimo but no before/after?
MasterDuke there is a before/after 21:03
timotimo with a capital letter, though i guess you tried that 21:04
MasterDuke they're not too big, want to see them? 21:05
timotimo OK why not
MasterDuke gist updated 21:07
timotimo i think we may have been talking of different things, haha 21:10
MasterDuke btw, should we create templates for those prof_* ops? looks like they do have lego jit implementations
??
timotimo oh, yeah why not, they are probably trivial
can you also get the push-all one? 21:12
MasterDuke the before/after?
timotimo yeah 21:13
it should also have "inlining graph pull-one"
MasterDuke there's only one, and it's a different push-all
timotimo oh
i think i'm too headachy to get behind this 21:14
MasterDuke SETTING::src/core/Iterator.pm6:55, not SETTING::src/core/Any-iterable-methods.pm6:405
but it wouldn't get spesh because it's only called once, right? 21:15
*speshed
timotimo if it has an osrpoint that gets hit often, it would get speshed/jitted
MasterDuke i feel like i should create a moarvm issue for this 21:32

Powered by Cro and the Raku® Programming Language.

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

Thank you!