buggable 🎺🎺🎺 It's time for the monthly Accidental /win Lottery 😍😍😍 We have 2 ballots submitted by 2 users! DRUM ROLL PLEASE!... 00:00
And the winning number is 4! Congratulations to AlexDaniel-! You win a can of WD40!
samcv buggable, i want to win
timotimo you need to accidentally write a /win 123 command in the chat 00:09
but it better be a legitimate accident!
samcv /win 123 00:32
buggable samcv, Thank you for entering Accidental /win Lottery! The next draw will happen in -1 weeks, 6 days, 23 hours, 27 minutes, and 22 seconds
samcv oops
timotimo you have more than a hundred irc windows open? :o 00:33
samcv no 02:40
<timotimo> you need to accidentally write a /win 123 command in the chat
02:56 ilbot3 joined 04:13 TimToady joined 07:08 AlexDaniel joined 07:58 Util joined 08:21 mtj_ joined 08:30 releasable6 joined 08:52 zakharyas joined 09:27 Ven joined 09:30 robertle joined 10:04 brrt joined
lizmat good *, #moarvm! 11:00
timotimo: glad to see you got home safely
brrt good * lizmat
lizmat jnthn: if I have a a :degree(X) on a hyper, can the number of general-workers ever exceed that or not ? 11:01
assuming nothing else is going on
jnthn Yes, because batching/joining are also scheduled tasks 11:07
lizmat ok, just checking :-)
jnthn The degree is interpreted as the degree of parallelism of the stages that we can distribute, but excludes infrastructural things.
lizmat hmmm... if I run the snapper with 0.001 (as in 10x as much as the supervisor) 11:09
11:10 avar joined
lizmat usually the period is about 1350 microseconds 11:10
but sometimes it is 7-8x as much, between 10K and 12K microseconds, but not additional CPU usage 11:11
I guess that's either libuv or GC kicking in, at that level ?
jnthn GC can take some miliseconds
lizmat yeah, looks like that 11:12
BTW, is there a way to find out how many GC's have been done ?
is there an nqp:: op for that ?
jnthn --profile
lizmat I mean, while executing :-)
jnthn Not without using the profiler, no
lizmat would it be easy to expose this as an nqp::op ?
jnthn "it depends" 11:13
lizmat hehe, I'm not sure I'm going to like the answer :-)
jnthn In that yes, there's a number we can easily expose
But what about other backends?
lizmat on other backends it will always be 0
and I'd settle for some #?if moar code for now, as to not have to burden the other backends at this time 11:14
jnthn I guess the thing thing is whether one number (how many GC runs) is useful :) 11:37
I guess maybe it is.
We don't currently count (unless profiling) the number of full GCs
The only reason we have the number of GC runs is because we use it as a sequence number 11:38
To check if somnething was seen in this GC run, as well as for debug output
lizmat well, I'd like to be able to crossreference it with other numbers 11:42
to see patterns
12:08 Ven joined
timotimo see the "vmhealth" branch for an example op that counts - among other things - how many GC runs have happened sofar 12:34
lizmat jnthn: sanity check: Worker.run-one is supposed to run 1 job every time it is called, right ? 12:40
12:46 Ven_ joined
lizmat jnthn: from what I can see, this does not appear to be the case :-( 12:52
12:53 zakharyas joined
jnthn Not sure what "job" means in this context, but it's called once per queue item 13:03
If the numbers you're asking about are those timing ones, then see my comment on #perl6-dev as to why they'll be wrong 13:11
lizmat "task" then ?
jnthn Well, consider: start { ...stuff...; await blah; ...stuff... } 13:12
lizmat if I want to process 200 items in a hyper, with a :64batch, that would be 4 tasks (64,64,64,8) ?
jnthn If blah isn't ready and it does a non-blocking await there, then this will show up twice in Worker, once before the await and once after
So at a user level you might say that start block is one task, but it'll either be 1 or 2 entries in the queue over its lifetime depending on that await 13:13
lizmat if the work is all CPU bound, that's not likely to happen, is it ?
jnthn No, but note that the bathcer and the joiner use non-blocking awaits 13:14
iirc, the joiner will spend most of it's life awaiting, but it's a single task, so the way you'd put those time things in, you'd measure its who lifetime, but it's actually only occupying a worker for a fraction of that time 13:15
*its whole 13:16
lizmat suppose I replace the current $!total setting code with a ++$!total just before the $!working = 0 in Worker!run-one
should that count the number of tasks completed ?
jnthn It'd count the number of queue items completed
If you want to count directly scheduled stuff, I guess you'd want to do it in .cue
lizmat which in the case of ^200 .hyper would be 4, right ?
jnthn But that'd miss events from the outside world 13:17
Well, but as I mentioned, the batch/join workers are probably a call to .cue each too
lizmat ok, so it could be *more*, it shouldn't be less, right ?
jnthn Right 13:18
lizmat hmmm...
ok, lemme do some more research and grokking :-)
jnthn fwiw github.com/rakudo/rakudo/blob/mast...ipeline.pm is where all the hyper/race-related starts happen 13:23
13:27 ilmari joined 14:37 AlexDaniel joined 14:41 Ven joined 14:48 zakharyas joined 15:50 domidumont joined 15:57 domidumont joined 16:08 brrt joined 16:33 Ven joined 17:01 domidumont joined 17:08 zakharyas joined 17:12 releasable6 joined 17:16 eater joined 17:23 domidumont joined 18:15 Ven joined
timotimo jnthn: any progress on CStructArray? 18:52
jnthn timotimo: No, between $dayjob, trying to get a Cro release out this week, and a rotten cold, I didn't get to it yet 19:23
19:24 Ven joined
timotimo ugh. i'm returning to my sick roommate tomorrow to care for her, but i'm assuming i'll also be catching something bad real soon 19:24
btw, cro now installs without --/test on latest rakudo after i did a two-line patch in yamlish 19:25
jnthn Oh, nice :)
(About Cro, not about catching a cold soon.)
timotimo of course 19:26
jnthn Mine is...not bad, I just feel tired all the time, and generally under the weather
timotimo it looks like it also succeeded just fine on 2017.09
anyway, i wish you a swift recovery of course :) 19:50
20:54 evalable6 joined 21:49 Ven joined 22:01 colomon joined 22:03 colomon joined
Geth MoarVM: 11ab1dcbe5 | (Samantha McVey)++ | src/strings/ops.c
join: factor code into join_get_str_from_pos() function

Function returns the string by two methods depending on if the array is an object array or a string array.
MoarVM: 4136ae2565 | (Samantha McVey)++ | src/strings/ops.c
speed up join of longer strings by a significant amount

Here we concat multiple times for >300 graphemes per string or if there's <4 pieces and >150 graphemes per string.
This can be up to 10x faster for joining very long strings. The conditions were created after extensive testing of joining strings with a separator.
MoarVM: 8c1584bc5c | (Samantha McVey)++ (committed using GitHub Web editor) | src/strings/ops.c
Merge pull request #743 from samcv/join-concat

Speed up concat of longer strings by a significant amount
Zoffix MoarVM build fails on Windows: ci.appveyor.com/project/rakudo/rak...igxmox1gy6 23:39
The ASM preprocessor or whatever it is inserts these `#line` things, but the paths in them have backslashes that aren't escaped. This is one of the results: gist.github.com/zoffixznet/a7bc53d...74733222d0 23:40
Oh wait. It just warns about that stuff
jnthn Yeah, that's just a warning 23:41
The actual error looks further on
I tried to figure out how to fix dynasm once, 'cus it spewed a gazillion of those warnings
Then got fed up and stuck the warning pragma in
To disable the warning in that file 23:42
So now it does one warning, 'cus I didn't manage to get it to spit out the pragma earlier than that :P
(It probably just needs somebody more patient than me to fiddle with dynasm.)
Zoffix Oh damn 23:43
Neveeerr mind. This fail is from a month ago 'cause PR was subitted a month ago -_-
This was the MIN macro issue 23:44
jnthn oh
phew :)
Sleep time o/ 23:54