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.
00:02 reportable6 left 00:05 reportable6 joined 01:32 lizmat_ joined 01:35 lizmat left 01:41 frost joined 02:53 linkable6 left, evalable6 left, evalable6 joined 02:55 linkable6 joined 03:20 ggoebel left 03:48 RakuIRCLogger left 05:24 linkable6 left, benchable6 left, quotable6 left, evalable6 left, squashable6 left, reportable6 left, greppable6 left, bloatable6 left, unicodable6 left, releasable6 left, statisfiable6 left, bisectable6 left, nativecallable6 left, coverable6 left, committable6 left, sourceable6 left, tellable6 left, shareable6 left, notable6 left, quotable6 joined, tellable6 joined, squashable6 joined 05:25 nativecallable6 joined, benchable6 joined 05:26 bloatable6 joined 05:27 coverable6 joined
Nicholas goo *able6, #moarvm 05:51
nine is it already tomorrow? 05:56
06:04 reportable6 joined 06:24 statisfiable6 joined 06:25 releasable6 joined, bisectable6 joined 06:34 kjp left, TempIRCLogger left, MasterDuke left, discord-raku-bot left, leont left, Nicholas left 06:56 kjp joined, TempIRCLogger joined, MasterDuke joined, discord-raku-bot joined, leont joined, Nicholas joined 07:23 discord-raku-bot left 07:24 discord-raku-bot joined 07:25 evalable6 joined 07:26 notable6 joined 08:09 lizmat_ left, TempIRCLogger left, lizmat joined 08:10 TempIRCLogger joined, Geth left 08:11 Geth joined 08:24 squashable6 left 08:25 greppable6 joined, linkable6 joined, committable6 joined 08:26 squashable6 joined, unicodable6 joined
Nicholas nine: I'm unsure about the singularly at midnight, but other than that, it's never yet tomorrow, but s' is always morning. 08:38
and sometimes ASAN is excited 08:39
09:02 ggoebel joined 09:11 patrickb joined
jnthnwrthngtn japhb: It can be true that multiple *codepoints* need considering around the join point, but only one *grapheme* either side of it. 09:18
nine jnthnwrthngtn: I should find some time this evening. If you beat me to it, feel free :) 09:21
09:26 shareable6 joined 09:27 sourceable6 joined
jnthnwrthngtn japhb: Also, looks like we could hoist those lines as suggested, yes, and it may be a little cheaper 09:27
moon-child just curious, does moar do loop invariant motion? Or should I do it by hand? 09:29
jnthnwrthngtn Doesn't do that yet 09:30
09:30 linkable6 left
jnthnwrthngtn argh, not enough coffee... 09:31
Chose squash merge, stared at the commit message I should edit, then hit the button to merge it, then realized I didn't edit it...
moon-child hehe 09:32
Nicholas git push --force-more-coffee ? 09:46
lizmat
.oO( where's the PR? and what about --force-more-tea? :-)
 09:52
lizmat wishes she could still handle coffee every now and then 09:53
10:00 MasterDuke left 10:33 ggoebel left, linkable6 joined 10:41 squashable6 left 10:43 squashable6 joined 10:49 ggoebel joined 12:02 reportable6 left 12:42 linkable6 left 13:05 reportable6 joined
[Coke] did not like the experiment he ran to go drink no more than decaf for several months. (trying to see if my pulse went down: it did not) 13:13
13:23 frost left 13:44 linkable6 joined 14:50 Altai-man joined 14:52 Altai-man left 15:04 rypervenche left 15:21 rypervenche joined
nine Quiz of the day: which one is more low level? nqp::can(...) or ^find_method(...)? And which of those two is faster? 15:53
lizmat I've always understood nqp::can to be lower 15:54
I would also assume nqp::can is faster
but it probably isn't (anymore anyway :-)
15:58 patrickb left
timo well, i recommend tryfindmethod instead :P 16:08
nine Spoiler alert! 16:11
timo newdisp had a bit of a hand in this, right? can and ^find_method? 16:12
i mean, having an nqp:: in front seems like it would be more low-level, but it robably turns into a disatch program call now?
nine In fact, nqp::findmethod, nqp::tryfindmethod and nqp::can all compile to roughly the same code, i.e. a lang-find-meth dispatch. Both NQP and Raku use the nqp-find-meth which will eventually call $how.find_method 16:13
So arguably ^find_method is actually more low level, as those nqp desugars all wrap it. But, nqp-find-meth uses the dispatch cache, so it can actually still be faster. 16:14
16:14 MasterDuke joined
MasterDuke i compiled CORE.[cde] --full-cleanup under valgrind. e and d had no leaks, but c did. looks like they're all disp program recording related gist.github.com/MasterDuke17/b3331...ace62dad99 16:18
17:06 MasterDuke left 17:13 brrt` joined 17:14 brrt` is now known as brrt
Nicholas good *, brrt 17:15
brrt good * Nicholas 17:16
17:20 brrt left 17:23 MasterDuke joined
MasterDuke anyone have an idea for something smaller/shorter/faster to repro that disp program recording leak? 17:24
18:02 reportable6 left 18:03 reportable6 joined
MasterDuke ah ha. t/moar/53-dispatch.t repros it 19:29
19:52 squashable6 left 19:53 patrickb joined 20:45 patrickb left 20:46 squashable6 joined
lizmat I just noticed that since new-disp the startup of the logs server is *much* slower, but that seems to be caused for a large part by not using all CPU's as before 20:48
is anybody else seeing that ?
CPU usage used to be at 800% or so, now it's hanging around 150% (aka only using 1.5 CPU) 20:49
instead of all 8
it feels like it is no longer racing at all :-( 20:54
lizmat kills the full loading of the logs server after waiting for 15 minutes
by this rate, it's going to take an hour to load everything 20:55
lizmat calls it a day& 20:57
[Coke] I know we heard startup was slower in general, but I don't remember it due to non-concurrency 20:59
timo i'd probably reach for Log::Async in such a case 21:16
jnthnwrthngtn That or Log::Timeline to try and visualize it, but also interesting to RAKUDO_SCHEDULER_DEBUG=1 to see if it's starting enough threads 21:45
I've no idea whatsoever why we might see such a result after new-disp though
22:03 evalable6 left, linkable6 left
Geth MoarVM: MasterDuke17++ created pull request #1562:
Fix two leaks missed by --full-cleanup		 22:09
22:18 ggoebel left
lizmat jnthnwrthngtn: running it with -Msafe-snapper, it looks like it only ever started *2* affinity threads 22:33
hmmm... but the general worker threads is 62 ??? 22:34
hmmm... on the old server (running pre-new-disp) the number of general worker threads was also 62 22:37
that has 4+4 cores... and CPU usage during startup is about 550%, aka 5.5 CPU cores 22:38
and on my 8+8 core machine (on new-disp) essentially the same code only takes about 150% (aka 1.5 CPU) 22:40
22:51 ggoebel joined 22:56 ggoebel left 23:03 evalable6 joined
jnthnwrthngtn lizmat: Hmm, that's surprising. Would be interesting to get to the bottom of that; it may also explain some other (less noticeable) slowdown I observed 23:15
timo can probably attach a gdb and grab backtraces from all threads; probably want the raku-level backtraces to see where they are waiting if they all wait, right? 23:17
Geth MoarVM: 039cc58442 | (Daniel Green)++ | 2 files
Fix two leaks missed by --full-cleanup
 23:19
MoarVM: e81e6878bb | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1562 from MasterDuke17/fix_two_memory_leaks

Fix two leaks missed by --full-cleanup
jnthnwrthngtn timo: Yeah, though I could run it in the comma debugger to see that. :) 23:21
timo a-ha! :)
jnthnwrthngtn Wonder if we accidentally introduced some lock somewhere that creates more contention than intended, but I really can't think where
timo if you can easily restart it with the debugger turned on and get the same behavior, yes
jnthnwrthngtn Dispatch program recording is OCC 23:22
There are locks in callsite intern handling but iirc only when we need to extend it, and even then it'd only affect the phase where we're setting up dispatch programs 23:23
timo right, all that new-disp does should be a-few-times-per-callsite anyway
jnthnwrthngtn sleep o/ 23:32
timo night 23:35
23:57 ggoebel 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!