github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:04 Kaiepi left, Kaiepi joined 00:10 anatofuz left 00:11 anatofuz joined 00:15 anatofuz left 00:45 anatofuz joined 00:48 anatofuz left, anatofuz joined 02:35 AlexDani` joined 02:39 AlexDaniel left 02:45 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 02:52 anatofuz left 02:53 anatofuz joined 02:57 anatofuz left 02:58 anatofuz joined 03:08 AlexDaniel left 04:39 anatofuz left, anatofuz joined 04:40 anatofuz left, anatofuz joined 04:43 anatofuz left 04:44 anatofuz joined 04:46 sena_kun joined 04:48 anatofuz left 04:59 anatofuz joined 05:12 robertle left 05:34 sena_kun left 05:35 anatofuz left 05:37 anatofuz joined 05:55 brrt joined 06:19 domidumont joined 06:22 anatofuz left 06:25 anatofuz joined 06:26 brrt left 06:45 brrt joined 07:12 robertle joined 07:27 brrt left 07:40 anatofuz left 07:55 zakharyas joined, anatofuz joined 08:15 sena_kun joined 10:06 anatofuz left 10:07 anatofuz joined, anatofuz left, anatofuz joined 10:22 anatofuz left 10:23 anatofuz joined 10:27 anatofuz left 10:47 brrt joined
brrt \o 10:50
nwc10 o/ 10:52
brrt I'll try to debug what's going wrong in the qregex test case today. I think I have a decent theory on why annotations with distinct deopt target addresses end up on the same guard, and it'd be annotation movement as we delete opcodes 10:56
I'm not entirely sure whether I want to pursue that further
... the qregex test case inlines 15 frames or so :-o 11:08
you'd be surprised the regex engine is still slow after all this
hmm. the qregex has an inlinee graph, that has two annotations with different target addresses 11:10
so maybe it is worth addressing after all
timotimo wanna share the spesh graph before/after + inlines of that one?
brrt uh.... 11:11
sure
gist.github.com/bdw/0f898d754f8f0d...2ce605dea1 11:14
timotimo just so i can be proud of spesh
brrt the change I'm doing, is moving the sp_guard* ops from having the deopt_target as argument, to the deopt_idx as argument 11:15
timotimo oh no the browser tab is hanging
brrt has recently started using firefox again and has had this problem relatively fewer
less often, I should say
nine So....why _is_ the regex engine still slow? 11:16
timotimo in some cases we're comparing the perl6 regex engine against specialized methods in other languages 11:17
like in the /^foo/ vs .starts-with("foo") case
brrt nine: of the top of my had, 11:18
- a bunch of other languages defer to PCRE, and PCRE is ancient, crufty, low-level and fast, and we're competing with a HLL implementation
*head
- we have a string implementation that is not necessarily the most suitable for a regex implementation (it is relatively expensive to just pick one character or to iterate over all because we have abstracted access) 11:19
- our regex engine allows in general, arbitrary code to run (the benefit of having the HLL implementation) 11:20
nwc10 oh, also, at $ork, it turned out that for the $ork regexs and $ork data, PCRE was about 7 times as fast as re2
not that that matters *that* much to *this* discussion
brrt has been reading re2 a bunch and was impressed by the quality of code
nwc10 I didn't go into the code. I only read the headers and wrote enough of a wrapper to use it 11:21
But all the work stuff is internal, so "constant time bounded" constraints aren't *that* important to us becase 11:22
timotimo we were going to have guards on the storage type of strings in spesh in order to make grapheme access faster
nwc10 1) we don't have lots of nasty people trying to DOS us
timotimo and we're already turning stranded strings into arrayed strings
nwc10 2) anyone in the office who does accidentally do something slow won't be able to save it, because the system will time out before it gets to render the "Save" button on the page :-)
it's self-selecting
timotimo haha! :D 11:23
brrt then it's not really a bug of course :-) 11:24
it's a feature
Geth MoarVM/expr-jit-devirtualize: 8 commits pushed by (Bart Wiegmans)++ 11:28
brrt rebase coming up
11:29 zakharyas left
brrt git bisect conclusively proves I screwed up during the deopt_idx refactor :-( 11:38
timotimo oh no
brrt but how... 11:45
timotimo cdn.discordapp.com/attachments/614...nknown.png 12:32
moarperf showing highscores of heap snapshot stuff 12:33
jnthn timotimo: That shows growth in numbers of certain things on the heap? 12:34
timotimo aye 12:41
which type or frame is which line is available information, just not presented just yet
also, obviously there ought to be color differences 12:42
and now you can up the number of lines displayed at the same time, too
12:45 reportable6 left 12:50 reportable6 joined
timotimo not finding a way to give the charts a background color :\ 12:52
when adding a CartesianGrid component i can get it, then i can - if i want - make it just not draw any lines 12:54
how do i colors 12:55
jnthn hot pink all the things! 13:02
13:04 anatofuz joined
timotimo cdn.discordapp.com/attachments/614...nknown.png - tooltips show the names and exact "scores" 13:06
the "select a snapshot" widget is super terrible; it's literally just a very long list of all the snapshots with a "Request" button 13:07
makes for a lot of scrolling
cdn.discordapp.com/attachments/614...151504.mp4 - tooltips working just great 13:17
13:33 zakharyas joined
timotimo unfortunately, reading the highscores of 200 snapshots actually takes a little while :\ 13:54
13:57 anatofuz left
timotimo gotta make it output partial data in regular intervals at some point 13:59
cool, by asking it to read the size of the segment instead of the size that zstd recommends for one input read blop it got almost 3x faster per piece 14:26
still too slow tho 14:35
14:45 brrt left
timotimo about 2 × 0.3s for each snapshot to decompress the highscore stuff :\ 14:55
i'd really like a 10x improvement for all the zstd decompress code; there's loads of overhead 14:56
HOLY SHIT 15:03
i wanted 10x, i got at least 10x more than i asked for 15:08
lizmat that sounds pretty cool
timotimo only inside of Compress::Zstd 15:09
for decompressing
15:11 domidumont left
timotimo now if only the memory usage wouldn't go up so high when parsing whole snapshots even when "forget" is called on them 15:31
lizmat anyone interested in a repeatable: MoarVM panic: Heap corruption detected: pointer 0x7fc440134d10 to past fromspace ? 15:33
timotimo it can go on the pile %) 15:34
lizmat ok... then I'll just fix the underlying issue :-)
Guest15407 lizmat: give it to nine 15:38
lizmat too late
Guest15407 nooooo 15:39
:)
japhb timotimo: Am I reading that right? You found some way to make the decompression 100x faster for your use case? 15:49
timotimo only because it was extremely slow
tadzik :) 15:50
only becuase you are extremely humble!
timotimo github.com/timo/Compress-Zstd/comm...4a798c4017 15:51
japhb timotimo: Also, if you want something that grows and shrinks in memory usage -- try github.com/ab5tract/Terminal-Print...attacks.p6 (and if you need one that is more aggressive in multithreading than that one, I've got a private copy that will do that too).
timotimo no it was literally extremely slow
oh yes!
that's lovely
tadzik ah, lowlevelness :)
timotimo MoarVM panic: heap snapshot found a non-string in get_vm_string_index 15:52
DAMN IT
well, at least it happens not only in my GTK program
japhb timotimo: Actually, I'm curious which part of the high-level code was slowing it down. I have a sneaking suspicion it was the .Array coercion. 15:53
timotimo you can try it yourself, the buffer was a CArray, $foo was a "my int @blah" 15:54
japhb $foo? 15:56
timotimo er, the thing being .append-ed into 15:57
16:33 robertle_ joined 16:44 lucasb joined
Kaiepi timotimo, by how much am i supposed to reduce the nursery size in src/gc/collect.h? 17:29
timotimo depends on how long you want to wait 17:30
2 kilobytes?
jnthn: would be glad if you could merge this pull request: github.com/jnthn/p6-concurrent-progress/pull/1 17:39
moarperf depends on it
17:45 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 17:46 zakharyas left
Kaiepi testing async sockets with MVM_GC_DEBUG defined to 3 came up with a bunch of small mistakes, good thing it didn't end up being merged as is 19:01
timotimo \o/ 19:02
Kaiepi what does "Invalid owner in item added to GC worklist" mean? i think i worked out how you fix it, but idk why what i'm doing works 19:16
dogbert17 .seen nine
tellable6 dogbert17, I saw nine 2019-09-12T11:16:22Z in #moarvm: <nine> So....why _is_ the regex engine still slow?
timotimo Kaiepi: could be memory corruption, perhaps rooted something that's not an MVMCollectable 19:17
dogbert17: want to proofread my blog post? :) 19:18
wakelift.de/p/3b104399-50d2-4792-b9...94e074e96/
Kaiepi in one case i was rooting an MVMAsyncTask when idt i was supposed to be
dogbert17 timotimo: sure
timotimo rooting uninitialized variables is also bad 19:19
MasterDuke timotimo: nice post 19:24
dogbert17 timotimo: I think the blog post looks good 19:25
timotimo: I suspect there's a bug in github.com/MoarVM/MoarVM/blob/mast...ops.c#L468 19:29
I get I SEGV which sort of points towards this function 19:31
MasterDuke would anything from thume.ca/2019/07/29/shenanigans-wit...sh-tables/ be useful/relevant for moarvm? 19:32
19:40 zakharyas joined 19:47 Kaiepi left 19:53 Kaiepi joined 20:04 Kaiepi left, Kaiepi joined
Kaiepi test script works now, time to see which roots i can get rid of 20:15
20:34 zakharyas left 20:39 robertle_ left 20:45 sena_kun left
Kaiepi so i have a function that's called from within an MVMROOT that roots one of the same objects it's rooting, but if i try to get rid of it i get a bus error. why is that? 20:47
Geth MoarVM/expr-jit-invoke: 6b047c325f | (Bart Wiegmans)++ | 4 files
[JIT] Implement invoke sequence in expr JIT
 21:01
MoarVM/expr-jit-invoke: fc5dc1d12c | (Bart Wiegmans)++ | src/jit/graph.c
[JIT] Eliminate special consume_invoke opcode

Except for nativecall_invoke, we no longer need this part of the legacy JIT.
MoarVM/expr-jit-invoke: fb2f81801a | (Bart Wiegmans)++ | 7 files
[JIT] WIP on nativeinvoke in the expression JIT
 21:02
MoarVM/jit-expr-optimizer: 4 commits pushed by (Bart Wiegmans)++ 21:06
21:11 dogbert17 left
Kaiepi one side effect of fixing the gc-related stuff for async sockets seems to be that their performance is much more stable (at least with the script i'm testing with) 21:13
now it binds and connects at a consistent rate, rather than randomly stopping like before 21:15
MasterDuke nice 21:17
jnthn timotimo: Commented on the PR. BTW, where is the latest heap snapshot format documented, and is it relatively stable now? 21:21
21:26 AlexDaniel left, AlexDaniel joined 21:27 AlexDaniel left, AlexDaniel joined, anatofuz joined 21:39 brrt joined
brrt I think i've solved the qregex regression in the deopt branch 21:40
timotimo jnthn: the format has different "sections", two of which contain json so they're "extensible", the others are all long lists of integers (in their native format, did not bother putting in endian-switching yet, but definitely should), those are zstd-compressed, and then there's the TOCs, which are two levels nested at the moment; i think the format will stay stable for a while, and in one of the json blobs 21:46
there's a "subversion" field that i shall be using
i'll write up a proper specification for you :)
Geth MoarVM/expr-jit-devirtualize: 2db874c0b2 | (Bart Wiegmans)++ | src/jit/graph.c
[JIT] Use correct deopt index for guard opcodes

Due to annotation migration (I think) we can have multiple deopt annotations on the same opcode, even a guard opcode, and they don't even always have to point to the same deopt target. But we should use the deopt target that was chosen when the guard was introduced, which is just the one that's the opcode argument.
Indeed, that's mostly the point of this set of patches. This fixes the NQP qregex testcase.
timotimo brrt: well done! 21:47
brrt :-) 21:49
we may want to look at annotation migration at some point
timotimo there's also the possibility to merge deopt targets by going backwards through any operations that don't have any side-effects 21:52
brrt hmm 21:58
22:10 anatofuz left
jnthn timotimo: Thanks, would love to have a proper spec. 22:14
I Have Plans. :)
brrt .seen pamplemousse 22:15
tellable6 brrt, I saw pamplemousse 2019-09-04T13:09:36Z in #moarvm: <pamplemousse> Hi timotimo
jnthn brrt++ # deopt
brrt jnthn: I hope to have them in the expression JIT tomorrow... but I kind of need sleep now :-) 22:16
22:16 brrt left 22:24 lucasb left 22:33 anatofuz joined 23:31 anatofuz left, anatofuz joined 23:32 anatofuz left 23:37 anatofuz joined 23:41 anatofuz left, anatofuz joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!