github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:09 lizmat_ joined 00:12 lizmat left 04:45 lizmat_ is now known as lizmat 05:23 lizmat left 05:54 lizmat joined 06:01 brrt joined 06:11 lizmat left 06:15 domidumont joined 06:17 krunen left, krunen joined 06:38 lizmat joined 06:53 patrickb joined 07:43 brrt left 07:54 lizmat_ joined 07:57 lizmat left 07:59 zakharyas joined 08:15 lizmat_ is now known as lizmat 08:45 zakharyas left 09:03 zakharyas joined 09:17 sena_kun joined 10:27 brrt joined 11:04 zakharyas left 11:08 squashable6 left 11:10 brrt left, reportable6 left, shareable6 left, greppable6 left, committable6 left 11:11 greppable6 joined, squashable6 joined 11:12 reportable6 joined, committable6 joined 11:14 shareable6 joined 11:54 brrt joined 11:57 brrt` joined 11:59 brrt left 12:37 domidumont left
Geth MoarVM: Kaiepi++ created pull request #1132:
Fix the CStr REPR's copy_to function		 12:38
12:50 domidumont joined 12:52 domidumont1 joined 12:55 domidumont left 12:57 zakharyas joined 13:01 brrt` left, brrt` joined
dogbert11 o/ 13:23
is the following message a sign of memory corruption or something else? MoarVM panic: Illegal Gen2 -> Nursery in caller chain (not in inter-gen set)
13:24 sena_kun left
jnthn Yes, something like 13:24
13:25 sena_kun joined
dogbert11 valgrind is unfortunately silent in this case although the panic persists 13:25
jnthn Well, it can be missing write barriering or some such also maybe 13:26
dogbert11 I get it when running t/04-nativecall/23-incomplete-types.t with MVM_GC_DEBUG=1
this is a recently added test file 13:27
jnthn That's also a chance the check is a bit over-zealous...
oh no
"not in inter-gen set" means it's certainly a problem
13:29 brrt` left
dogbert11 it looks like this in gdb FWIW: gist.github.com/dogbert17/7fb67166...c9b365e39d 13:32
hah, timotimos linkify script is really cool 13:33
timotimo glad to hear it :) 14:05
Kaiepi what are the unmanaged_size functions for in REPRs? 14:26
jnthn Amount of memory that it has allocated that isn't out of the GC pool 14:28
14:28 domidumont joined
jnthn For example, for an array only the header is in the GC's nursery or gen2 store, and the body of the array is allocated using other memory management 14:29
Kaiepi which part of the array would be unmanaged? the body? 14:31
14:31 domidumont1 left
jnthn yes 14:31
Kaiepi ah ok
would CStr's c strings be considered unmanaged since they never get any refs assigned to them and get freed manually from gc_free? 14:33
timotimo hold on, the MVMArrayBody isn't the unmanaged size 14:35
if you're thinking of that
you can think of "anything we malloc or mmap explicitly, that's unmanaged size"
and we try to count it only one time, though that's not always easy to guarantee
jnthn Kaiepi: Yes, that would count 14:37
Kaiepi aight, thanks
timotimo unmanaged_size was introduced when the heap snapshot profiler got made 14:40
15:26 zakharyas left 15:37 patrickb left
jnthn m: say 14521722665 / 15353500781 15:43
camelia 0.945824855981
jnthn Hmmm....I'm not sure I believe these numbers...
Oh, duh...I picked a benchmark with randomness in it :/ 15:44
Didn't notice until now
15:45 sena_kun left
jnthn And now I've got realistic numbers, my opt seems not to be one? :/ 15:53
urgh, I'm getting wildly different callgrind numbers between runs :/ 16:02
That makes it useless
I've got MVM_SPESH_BLOCKING=1 set 16:03
Wondering if it's hash randomization somehow 16:04
nwc10 step away from the keyboard and visit the beer fridge? 16:06
(you should ignore this suggestion in you're having a dry day) 16:07
jnthn It was hash randomization... 16:08
*sigh*
nwc10 oh gosh. why? (different CPU counts in just the hash code, or does it have ripple effects outwards?) 16:09
jnthn I don't know; I guess in theory it could cause different numbers of collissions and thus even affect growth rates? 16:10
TimToady maybe we have some bad functions that put a bunch into one slot? 16:11
jnthn What's a bit annoying is that just changing the MVM_HASH_RANDOMIZE to 0 isn't enough, though I'm going to fix that.
TimToady: I guess it's possible, though I suspect it's just fallout from the randomization 16:13
samcv++ put the randomization in, and probably would guess what might be going on better than I can :) 16:14
m: say 16172514963 / 16501633892 16:15
camelia 0.980055373234
jnthn 2% feels righter for the change I've done
jnthn makes sure the numbers are really stable now :)
I've been looking over various profiles and...our invocation performance was never that great, but now we've optimized enough other stuff to the point that it looks relatively horrible. :) 16:16
So I'm looking at what we can do to decrease the cost there 16:17
TimToady suspects dynvar lookup is getting "worse" in the same way 16:20
16:22 sena_kun joined
jnthn Yay, results are repeatable 16:23
2% of CPU cycles off by not setting up the arg processing context for frames that are specialized and so don't need one 16:24
(If we deopt, we create it then)
timotimo :+1: 16:41
jnthn Spectest seems happy
nine jnthn: what's the other thing one has to do to get rid of hash randomization? I think I even knew at some point but forgot 16:44
jnthn A tweak in moar.c, but I'm about to push a commit that means changing the #define is enough :) 16:45
timotimo i'm amused how close to 2% that ended up being in that last calculation 16:46
jnthn Yeah, so was I
Geth MoarVM/frame-opts: 6f67d8760a | (Jonathan Worthington)++ | 12 files
Only create arg processing context if needed

Most specialized frames do not need it, since they rewrite their argument processing code into something far cheaper. We can also save the cost of cleaning it up afterwards. On a benchmark doing quite a lot of non-inlinable calls, this saved ~2% of the total CPU cycles, as measured by callgrind.		 16:49
MoarVM/frame-opts: ac8c3fc1b6 | (Jonathan Worthington)++ | src/moar.c
Make MVM_HASH_RANDOMIZE properly control hash rand

Before, if one set it to 0, some randomization could still happen. The sure-fire way to make sure that doesn't happen is to just fix the hash secrets to 0 also.
jnthn m: say 16172514963 / 16152422888 17:17
camelia 1.001243904716
jnthn oops, wrong way around
m: say 16172514963 R/ 16152422888
camelia 0.998757640661
jnthn (A tiny improvement :)) 17:18
Though the first machine I spent a lot of time programming on ran at 25 MHz, and this saving would have been nearly a second of CPU time for it :P
Geth MoarVM/frame-opts: 8ae4b61462 | (Jonathan Worthington)++ | src/moar.c
Make MVM_HASH_RANDOMIZE properly control hash rand

Before, if one set it to 0, some randomization could still happen. The sure-fire way to make sure that doesn't happen is to just fix the hash secrets to 0 also.		 17:19
jnthn MasterDuke++ noticed a mistake in that commit :)
Geth MoarVM/frame-opts: 6c1c015641 | (Jonathan Worthington)++ | 8 files
Avoid having to NULL ->extras on each frame

By using ->flags instead. This saves us at least one CPU instruction per call frame creation.		 17:21
jnthn dinner & 17:30
17:30 domidumont left 18:03 lizmat left 18:43 brrt` joined 18:51 lucasb joined 19:35 patrickb joined
brrt` good * 19:38
nwc10 good *, brrt` 19:51
jnthn o/ 20:01
brrt` ohai nwc10, jnthn 20:12
20:22 brrt` is now known as brrt 20:41 lizmat joined 21:10 brrt left 21:13 Kaiepi left 21:24 Kaiepi joined 22:05 squashable6 left, squashable6 joined 22:10 lucasb left 22:36 patrickb left 22:45 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!