Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
08:05 ingy left 08:07 ingy joined 09:12 sena_kun joined 09:18 sena_kun left
lizmat Is there a way to find out whether a global GC cycle has been done, or possibly: find out how many have been done? 10:48
reason I'm asking:
in ParaSeq (raku.land/zef:lizmat/ParaSeq) I'm trying to batch an optimum number of values to get the lowest wallclock usage 10:49
it takes the wallclock of previous batches, and then computes the "right" number of values to match a certain interval (.5 millisecs at the moment) 10:50
however, a global GC can easily take multiple milliseconds (judging from the stats that ParaSeq keeps) 10:51
which has a detrimental effect, because it will make it look like the batch of size X got too many values to process, so it will reduce the size of future batches 10:52
which increases wallclock when it shouldn't
so I'd like to adjust the wallclock seen for a batch if it can be determined it had a global GC in it 10:53
ideally of course, I'd like to see how much CPU a batch has used, but I'm lead to understand that's impossible to find out (generally) 10:54
FWIW, I hope to make ParaSeq versatile enough so that it can be made to power >>.foo 10:55
lizmat hopes she's not rubberducking herself
11:36 leont left 11:44 leont joined 12:15 leont left 12:17 leont joined
Woodi lizmat: disabling gc when needed ? looks like low level features are needed so maybe some paart of it need to be implemented in moar ? 12:57
lizmat no, I don't want to disable GC 12:58
I just want to know *when* it did a full GC
Woodi "to see how much CPU a batch has used": do moar have instructions count like real cpus ? :)
lizmat so I can account for it when calculating optimum batch sizes
Woodi I mean: pause gc and do work in beetwin 13:00
lizmat the work it is doing is causing the GC :-) so that isn't a solution :-) 13:01
Woodi hmm, ^Inf :)
lizmat I have a test case of a 840MB text file, and looking for a string in it 13:02
and the GC is causing the batch size to decrease significantly 13:03
Woodi I think in gc-based vm's gc's are meta - they should be invisible. so low level coding and co-operating with gc is simplest choice. or having predictible gc 13:04
lizmat I'm willing to cooperate with GC: I just want to know when it ran 13:08
13:40 nine left, nine joined
Woodi grep shows few things on gc_start :) but src/profiler/log.c can have some examples ;) 13:57
japhb lizmat: FWIW, I've wanted this for quite a while, because it's damn near impossible to tune for stable animation frame rates if you can't tell what caused a frame time jump 14:45
I wonder if "GC generation number" could be an exposed thing 14:46
Also, it's not clear that GC affects threads equally, so not knowing which threads did more work may be an issue too 14:47
Woodi but leaking implementation details into upper level languages can end badly. vm's are nice and simple when they are black boxes 15:12
...clien-server approach ? or syscals :) 15:18
lizmat japhb 15:48
japhb: if you run a profile, it knows how many GC runs there have been
so the info is in there somewhere
also: I think MoarVM's GC is currently "stop the world", so it would affect all threads equally I'd say 15:49
16:59 japhb left, japhb joined 18:12 sena_kun joined
japhb lizmat: GCs often have a stop the world phase and one or more concurrent phases. I don't remember how this maps out to MoarVM's GC (it's been too dang long since I looked at it) 18:29
lizmat fwiw, I would be happy if we could find out the *number* of GC runs 18:31
in a syscall
[Coke] github.com/MoarVM/MoarVM/blob/main...=1#L52-L57 - I feel we can use stronger language here. 20:04
Geth MoarVM/coke/readme: b5d6caf897 | (Will Coleda)++ | README.markdown
Remove notes about development, other compilers
 20:58
MoarVM: coke++ created pull request #1815:
Remove notes about development, other compilers		 20:59
21:54 lizmat_ joined 21:58 lizmat left 22:00 lizmat_ left 22:01 lizmat joined 23:03 sena_kun 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!