00:16 flussence joined 00:47 colomon joined 00:48 tokuhiro_ joined, tadzik joined 01:48 tokuhiro_ joined 02:04 tokuhiro_ joined
hoelzro ugh 02:31
well, I figured it out
hoelzro made a newbie mistake
I handled the case where a new call capture was referring to a frame's callsite, but I wasn't handling the case where a capture was referring to another capture's callsite 02:32
02:45 vendethiel joined
timotimo oh? does that mean you're making progress? 02:54
hoelzro timotimo: yes! I should be pushing code to a branch shortly =) 03:02
just in time for my trip, too! I was not looking forward to having an incomplete solution hanging over my head 03:03
dalek arVM/patch-callsite-memory-leak: e304e68 | hoelzro++ | src/ (4 files):
Track whether or not a capture owns its callsite

This fixes a memory leak (RT #126183)		 03:06
hoelzro timotimo: does this seem sane to you? github.com/MoarVM/MoarVM/pull/274 03:07
we might want to do proper reference counting, but this seems to work ok
dalek arVM/defer-close-stdin: 4df2030 | hoelzro++ | src/io/procops.c:
Track process state when spawning children

This is prepare for a fix around closing standard input and race conditions		 03:30
MoarVM/defer-close-stdin: 3adb8e0 | hoelzro++ | src/io/procops.c:
MoarVM/defer-close-stdin: Re-enqueue close stdin request when process is unstarted
MoarVM/defer-close-stdin:
MoarVM/defer-close-stdin: Starting a process from Perl 6 using Proc::Async offers no guarantees
MoarVM/defer-close-stdin: that the process has had a chance to run once the start method returns;
MoarVM/defer-close-stdin: it just schedules the process to be started on the async worker thread.
06:25 FROGGS joined 06:26 Ven joined 07:35 Ven joined 08:33 Ven joined 09:45 cognominal joined 09:57 zakharyas joined 10:54 TimToady joined 11:01 colomon joined 11:11 colomon joined 11:21 Ven joined
[Coke] opened RT #126216, but it's probably a moarvm bug. 13:09
timotimo it could also be a violation of the contract that the profiler expects 13:13
for example, maybe when exit is called, nqp::leaveprofiler or what it's name is never gets called properly? 13:14
and then we're working off of data that's not properly finalized and also is still being written to?
just a theory
but this is how i'd go about debugging it: see if the profiler exit nqp:: op is called when exit is involved
13:41 Ven joined 14:24 Ven joined
hoelzro good morning #moarvm! 15:02
15:18 tokuhiro_ joined
hoelzro if anyone has time today, could I get some eyes on github.com/MoarVM/MoarVM/pull/274 and github.com/MoarVM/MoarVM/pull/275 , make sure it's good enough for master? 15:57
16:19 tokuhiro_ joined
timotimo i've briefly looked over the patch-callsite-memory-leak code and couldn't see anything wrong with it 16:20
but i didn't compile and/or run it
if it survives spec tests and perhaps even a nqp build under asan or something that'd be good enough for me :)
hoelzro I spectested it, and it did fine 16:32
timotimo in that case, why don't you go ahead and merge it in?: ) 16:34
:)
jnthn I'll try and have a look at the two later this evening
jnthn spent the day traveling, which was tiring 16:35
timotimo man who runs before car gets tired, man who runs behind car gets exhausted 16:39
jnthn :P
nwc10 Swedish rail, or something that actually goes foward? 16:41
timotimo an airplane, IIRC
jnthn Two planes 16:44
Preceded by a taxi and followed by a train
nwc10 two plans, one after the other, I hope. And not RAID-like failover 16:46
two plan*e*s
jnthn yes, indeed 16:47
timotimo maybe the planes coupled while mid-air like those planes that can re-fuel in the air 16:50
and then the passengers were funneled through a hose from one plane to the other?
jnthn The first managed to be a little early, and the second managed to be 10 minutes late - the perfect delay to make me rush through the airport to make the train (5 mins earlier and it's an amble, 5 mins later and I'd have not even bothered trying to make it)
The only do one train per hour from the airport to the city... 16:51
timotimo wow
nwc10 timotimo: you clearly haven't flow to interesting places (which is probably a good thing) 16:52
jnthn There's a bus every 15 mins or so, but it doesn't take the pretty route by the sea
16:52 Ven joined
jnthn And takes a little longer 16:52
nwc10 ie either *genuinely* interesting places, or airports Ryanair chooses
jnthn oh my, Ryanair... 16:53
nwc10 "there's a train hourly" is somewhat on the good side
hoelzro I'll merge the two after work tonight, providing no one objects
jnthn wonders why he's so hungry... 16:54
Mebbe I'll try and find the nice pub I discovered last time... 16:55
Interesting beers, posh burgers, and stout chocolate cake...what's not to like? Well, the prices, 'cus it's Norway. :)
Anyways, bbl &
17:30 FROGGS joined 17:50 Peter_R joined 17:53 vendethiel joined 18:18 Ven joined 18:21 tokuhiro_ joined 18:39 _itz joined 19:48 Ven joined 20:20 Ven joined 20:22 tokuhiro_ joined 20:29 arnsholt joined 20:31 Ven joined 20:51 hoelzro joined
timotimo jnthn: are you interested in me golfing the magical increase of gen2 roots that came when i was accessing an AoA outside of its correct boundaries? 21:04
jnthn timotimo: Yeah, but not now...I gotta get up to teach tomorrow :( 21:11
timotimo: I'd see if Failure is involved, and if so if it's to do with Failure holding an Exception which holds a stack trace, since frames tend to be to blame 21:13
Anyways, 'night o/
timotimo oh gnite jnthn 21:14
btw
41.38user 0.13system 0:41.95elapsed 98%CPU (0avgtext+0avgdata 207352maxresident)k
compared to:
50.25user 0.12system 0:50.77elapsed 99%CPU (0avgtext+0avgdata 204740maxresident)k
this is how my benchmark reacts to the setup block moving to its own private method
nativecall i mean
hoelzro timotimo: nice!
timotimo this is for rendering 500 "frames" 21:15
so the framerate is still not that great
but it's a noticable improvement
why it uses up more memory? i have no clue.
perhaps it's noise
hoelzro I've found a lot of memory noise in MoarVM 21:16
japhb timotimo: What's the time to finish the first frame?
timotimo you mean from program startup to first frame rendered? 21:17
japhb It's common to do [time-to-finish-first-frame] separate from [(num-frames - 1) / time-after-first-frame] 21:18
Yeah
Well, program *launch*, but same difference
timotimo 0.26944467 with the current rakudo/nom
0.25608250 with my change 21:19
japhb And then the other number would be (499 / (41.95 - 0.27)) I presume
timotimo but that could well be noise
japhb m: 499 / (41.95 - 0.27) 21:21
camelia ( no output )
japhb m: say 499 / (41.95 - 0.27)
camelia rakudo-moar ab7d96: OUTPUT«11.972169␤»
japhb OK, so 12 fps. Only need to get 5x faster. :-)
2.5x for a 30 fps game, and that ain't shabby. 21:22
timotimo ... the ... what?! 21:27
i ... what ?!?!?
the number of find_method calls has reduced to almost 0 21:28
3794.65ms was how much time find_method exclusively took; but i could even count the inclusive time here which is 4127.41ms
21:30 cognome joined 21:31 co-gnome joined
timotimo and i still don't know why CALL-ME doesn't get spesh'd 21:37
it must be because the callsite we're using for it flattens?
also, a very low percentage of calls to the min method are jitted, i wonder why that is 21:39
more than a hundred K calls, so "not called often enough" isn't the case at all 21:40
and i didn't find an abort message in the ji tlog
jitlog*
21:45 tokuhiro_ joined 21:58 lizmat joined 23:22 cognominal joined 23:30 cognominal_ joined 23:33 orbus joined 23:49 tokuhiro_ 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!