github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:29 reportable6 joined 01:31 MasterDuke left
mtj hi folks.. 02:19
timotimo, i just noticed the disabled appveyor build for moarvm, seems to be succeeding now :) 02:20
ci.appveyor.com/project/timo/moarvm-5bpx6
'Failed a year ago in 4 min 39 sec'
...if you force a build now, it should succeed 02:21
03:20 Kaypie left 03:22 Kaiepi joined
mtj github.com/KohaAloha/MoarVM 03:26
^.. thats an example of a passing build
04:48 Kaiepi left 05:23 squashable6 left 05:28 squashable6 joined 06:12 sena_kun joined 06:18 domidumont joined 07:04 robertle_ joined 07:23 anatofuz joined 07:50 zakharyas joined 09:37 domidumont left
jnthn people.eecs.berkeley.edu/~rohanpad...vmil19.pdf 10:06
lizmat is that interesting for the MoarVM case? raiph seemed to say it wasn't in the end ? 10:15
jnthn Oh, I didn't know it'd been discussed anywhere already :) 10:16
lizmat www.reddit.com/r/perl6/comments/d1...ing_paper/
I didn't mention it in the P6W because raiph in the end felt it was just noise
(from him)
jnthn I didn't read it carefully enough yet, *but* I think the `given $foo { when T1 { } when T2 { } ... }` style things could benefit from it. 10:18
otoh, those have a buttload of overhead besides the type check right now...
lizmat but shouldn't have that overhead in light of future opts, no ? 10:19
jnthn Correct, which'd presumably make the `istype` the bottleneck 10:22
10:59 robertle_ left 11:01 robertle_ joined
Guest15407 jnthn: could this be something something? programming-journal.org/2020/4/1/ Reference Capabilities for Safe Parallel Array Programming 11:18
only one 'something' is enough :)
11:21 domidumont joined 11:24 sena_kun left 11:41 zakharyas left 12:16 domidumont left 12:35 anatofuz left 12:55 lucasb joined 13:08 anatofuz joined 13:11 domidumont joined 13:26 zakharyas joined
timotimo if the heapsnapshot pass were to take place before stuff from the marking phase gets cleaned, we'd have essentially a bit of extra space in every object that would let us store the object's collectable index right there, while we follow the forwarder to call the gc_mark or explain_refs functions 13:30
13:31 anatofuz left
timotimo that should let us completely get rid of "saw" and "seen" 13:32
but maybe first i'll check what a cache for object address to type/collectable index would do 13:33
Guest15407 timotimo: do you think it's time to upgrade to libuv 1.32? 13:34
timotimo i didn't check the changelog, but it's probably a good idea in any case 13:37
Guest15407 Do you think we can do what we did before, i.e. check out the new version and then 'git add' the libuv dir? 13:39
timotimo probably 13:40
Guest15407 If so I can whip up a PR unless someone beats me to it :)
13:48 lizmat left
timotimo a simple cache simulation says with an 8 slot cache for STABLEs (address to index) there'd be a 92% hit rate in my case here 13:51
not sure why, but for type objects it's only 80% 13:52
for objects the hit rate is just 41% :( 13:55
14:00 Kaiepi joined
jnthn timotimo: Hmm...I wonder if that'd give us a difference in the inter-gen set... 14:03
timotimo: As in, it'd tell us what's in in pre-cleanup?
timotimo we'd still be doing a proper mark pass though, wouldn't we? 14:05
oh, though all the roots and such will also already have been updated at a much earlier point
how much faster do you reckon will a cache with 64 slots and simple rotating insert position be compared to looking through the "seen" hash? 14:07
jnthn Dunno. Is this thing bloomable? 14:08
Maybe seen hash already does that though
timotimo i don't think uthash has something like a bloom filter 14:09
and even if the bloom filter says "it's not there", the value still has to be put into the hash in the right spot 14:16
gist.github.com/timo/c94bd42f15e29...66134cf914 - here's the hit rates for caches of different sizes for the different kinds of collectables that the heap snapshot profiler has 14:23
i wonder what happens if the objects are further divided by whether they're in the nursery or in gen2 14:26
huh, there's only about 500 lookups for gen2 objects in here anyway 14:30
14:32 sena_kun joined
Guest15407 nine: interested in a distraction? 14:40
timotimo for completeness sake, i'll run a cache simulation with one cache for everything 14:48
ooooh, the heap snapshot profiler could actually write out the heap snapshot in a separate worker thread and continue running the user program at the same time 15:09
though depending on how it's managed, it'll either still cause pauses or potentially infinitely grow in memory usage
i.e. either it'll have a cap on how many heap snapshots are queued, then it'll pause the main program 15:10
or it'll just happily queue up more and more and more work on the worker thread
15:19 robertle_ left
nine Guest15407: you've got a good one? 15:21
timotimo seen is still at 10% in perf's report o_O
15:23 zakharyas left 15:25 zakharyas joined
timotimo oh, nice, writing out the heap snapshot is actually faster than taking the snapshot 15:26
so it wouldn't actually get backed up if this case generalizes
that also means that the time that the program is paused while taking a heap snapshot will not be less than half 15:27
15:28 anatofuz joined 15:38 domidumont left
timotimo what the heck, the performance of the caches is abysmal in actual use 15:56
dogbert17 nine: gist.github.com/dogbert17/f396ed9a...7f26227232 16:01
16:03 anatofuz left
dogbert17 nine: the file is t/04-nativecall/13-union.t and the nursery size 768 16:03
timotimo ha! now the cache is doing its job 16:09
16:12 lizmat joined
Geth MoarVM: dogbert17++ created pull request #1173:
Update libuv to version 1.32.0		 16:13
dogbert17 tada
timotimo how in the heck does this program end up with not-string-objects in one CU's strings list >:( 16:20
robertle dogbert17: have you seen any weirdnesses with this, or perhaps with earlier versions of libuv? we are seeing problems in debian, where we use the OS-version, 1.31.1 currently. and that version seems to have problems when used teh way moar does, something around it's choice of statx calls and other variants, leading to it not correctly recognmizing whether a path exists or not... 16:21
tellable6 2019-09-09T15:09:07Z #perl6-dev <AlexDaniel> robertle please let me know if what we have with stage0 is ok for debian or not. I created this ticket github.com/perl6/problem-solving/issues/100
2019-09-09T15:09:14Z #perl6-dev <AlexDaniel> robertle Basically, the upstream guide talks about compiling for other architectures, but we don't have this problem. The only problem is purity of the build itself (“Reflections on Trusting Trust” stuff)
robertle haven'tt got more details yet, hope to do more digging later today
but would be interested if you have encountered anything
also spotted M#1172 in the process :) 16:22
synopsebot M#1172 [open]: github.com/MoarVM/MoarVM/issues/1172 possible uid/gid confusion
timotimo aaaand it's the core setting
i can't reproduce the bug with spesh being disabled 17:18
17:20 MasterDuke joined
nine dogbert17: as distractions go, this was only of mediocre value ;) 17:20
Geth MoarVM: d76ebbe49a | (Stefan Seifert)++ | src/6model/reprs/CUnion.c
Fix possible memory corruption in CUnion's get_attribute

An untimely GC run may move *root before we get to assign the newly created object into the child_objs slot. This could cause us to over write unrelated memory. Fix by MVMROOTing root.
nine Well actually it took exactly the time I had... off to get some exercise now 17:21
17:38 travis-ci joined
travis-ci MoarVM build errored. Stefan Seifert 'Fix possible memory corruption in CUnion's get_attribute 17:38
travis-ci.org/MoarVM/MoarVM/builds/583279347 github.com/MoarVM/MoarVM/compare/2...6ebbe49ada
17:38 travis-ci left 17:42 zakharyas left 17:58 anatofuz joined 18:32 anatofuz left
dogbert17 nine: damn, I thought that would be a tricky problem :) 18:45
Geth MoarVM: MasterDuke17++ created pull request #1174:
Silence some clang warnings		 18:55
19:00 Kaypie joined, Kaiepi left 19:02 anatofuz joined 19:09 Kaypie is now known as Kaiepi 19:10 AlexDaniel left 19:11 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 19:16 anatofuz left 19:30 Ven`` joined
dogbert17 heh, a SEGV 19:37
timotimo: what do you make of this? gist.github.com/dogbert17/bd5a41e0...d8a1536915 19:41
19:41 AlexDaniel left, AlexDaniel joined, AlexDaniel left, AlexDaniel joined
timotimo that's nully 19:43
dogbert17 yeah 19:44
timotimo i'd say rr it %)
dogbert17 32k nursery this time so not too small
hahaha
timotimo rrawr
"RR And Wait for Results" 19:45
MasterDuke any reason not to merge github.com/MoarVM/MoarVM/pull/1174 ?
dogbert17 you know anyone with an Intel CPU :)
timotimo another bug has been kicking my ass today 19:53
dogbert17 another SEGV? 19:54
timotimo more than just one
dogbert17 oops 19:55
timotimo well, it could be just one, but i see distinct symptoms
dogbert17 and the SEGV itself don't give you any ideas?
timotimo one is that a decidedly not-a-string object gets into the strings list of a compunit 19:56
dogbert17 corruption
have you tried the GC debug flag? 19:57
MasterDuke timotimo: that seems like a perfect rr use case, right?
19:57 lizmat left
timotimo yup 19:57
the object itself, the string, ends up on the gen2 freelist
that's not easy to figure out with rr because watchpoints require a lot of manual shuffling around of addresses to figure out when that happens, but it's usually just "when gc has finished" 19:58
dogbert17 now here's a cool error message which I have nevere seen before 19:59
moar: tpp.c:87: __pthread_tpp_change_priority: Assertion `previous_prio == -1 || (previous_prio >= fifo_min_prio && previous_prio <= fifo_max_prio)' failed.
19:59 lizmat joined, lizmat left
dogbert17 timotimo: can you backtrack your latest changes? 20:05
timotimo "backtrack"?
dogbert17 go back in the commit history I mean 20:06
timotimo oh, right
aha 20:15
* ee18678e9 - (HEAD) Update "Features" part of readme (10 days ago) <Timo Paulssen> 20:16
crashes here already
dogbert17 sounds like progress 20:19
timotimo it's the same problem, too.
string number 15 in this CU is actually a MAST::Lexical
i'm tired of this bug for now
dogbert17 it can probably rest for a bit 20:20
timotimo do you have an interesting workload that changes how it uses memory over time so i can get actually interesting graphs out of the heap snapshot analyzer?
dogbert17 hmm
timotimo all the ones i have are basically flat
nwc10 timotimo: *this* time my beer fridge was obstructed by a shopping bag of shower gel or similar, which is meant to get onto the shelves near it. I hope your beer fridge (or equivalent) is in better shape
timotimo cdn.discordapp.com/attachments/614...nknown.png 20:21
dogbert17 not as exciting as it could be :)
timotimo: perhaps this one - github.com/rakudo/rakudo/issues/3114 20:23
timotimo how many gc runs does that do ... 20:28
how often does it say "evaluating"? 20:29
like on average?
20:29 sena_kun left
dogbert17 it's a bit random, I have seen evaluating go as low as two and up to 30-40 20:30
timotimo 32022969 484M -rw-r--r--. 1 timo timo 484M Sep 10 22:30 /tmp/shmup.mvmheap
not terribly exciting 20:31
dogbert17 oh no 20:32
timotimo 187 snaps
cdn.discordapp.com/attachments/614...nknown.png 20:40
don't want to know how often the gc runs during core setting compilation :) :) 21:11
21:12 anatofuz joined
MasterDuke learn anything useful from it? 21:17
timotimo from what?
MasterDuke the graph. i assume you were taking heap snapshots during core compilation? 21:18
timotimo ah, no, that picture was from the rakudo ticket dogbert17 linked to 21:19
i'm just taking snapshots of core setting stage parse, i'm at 580 megs so far
MasterDuke how much does that slow it down? 21:23
timotimo quite a bit 21:24
it looks like immediately after a heap snapshot finished writing it starts taking the next one
cdn.discordapp.com/attachments/538...nknown.png 21:25
i ctrl-c'd the heap snapshot taking
amusingly i hit 198 snapshots without looking 21:26
MasterDuke that looks a little more interesting 21:27
timotimo i was wishing for something where bars go up *and* down ;)
i told my grant manager yesterday that i'd have something on my blog "today or more probably tomorrow" 21:31
that "tomorrow" is almost over and all i've been doing is hunt that disgust bug
MasterDuke doh
timotimo the only thing the heap snapshot profiler inside moarperf could do until a few days ago was give you a list of the snapshots in a file and letting you cause them to be parsed (by way of one button per snapshot) 21:33
before i did another little refactoring it now even showed parsing progress
MasterDuke nice 21:35
timotimo you can't get any data out of it yet except these graphs 21:36
they'll of course get labels, too
22:06 lizmat joined 22:08 Ven`` left
AlexDaniel MasterDuke: “some clang warnings” there are more? 22:22
MasterDuke AlexDaniel: yeah, i think all `warning: control may reach end of non-void function [-Wreturn-type]` 22:23
AlexDaniel MasterDuke: might as well fix these too? :) 22:25
MasterDuke those might be more complicated and might require more invasive changes. i think the existing PR is pretty much a no-brainer 22:27
Geth MoarVM: 8e7e121035 | (Daniel Green)++ | 5 files
Silence some clang warnings
 22:28
MoarVM: 15a8725e33 | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | 5 files
Merge pull request #1174 from MasterDuke17/silence_some_clang_warnings

Silence some clang warnings
AlexDaniel well, I hope so, last time we did something like this I recall issues with %ld or something when using some compiler 22:29
was it windows something something? I don't remember :)
timotimo there's constants that give you "the right" thing
PRiu64 or something like that 22:30
it's used in many spots already
but it's so much more to type ;)
22:33 anatofuz left 23:05 lucasb left 23:08 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!