Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-01

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 buggable 🎺🎺🎺 It's time for the monthly Accidental /win Lottery 😍😍😍 We have 2 ballots submitted by 2 users! DRUM ROLL PLEASE!...
00:00 buggable And the winning number is 4! Congratulations to AlexDaniel-! You win a can of WD40!
00:00 samcv buggable, i want to win
00:09 timotimo you need to accidentally write a /win 123 command in the chat
00:09 timotimo but it better be a legitimate accident!
00:32 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
00:32 samcv oops
00:32 samcv nice
00:33 timotimo you have more than a hundred irc windows open? :o
02:40 samcv no
02:40 samcv <timotimo> you need to accidentally write a /win 123 command in the chat
02:56 ilbot3 joined #moarvm
02:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:13 TimToady joined #moarvm
07:08 AlexDaniel joined #moarvm
07:58 Util joined #moarvm
08:21 mtj_ joined #moarvm
08:30 releasable6 joined #moarvm
08:52 zakharyas joined #moarvm
09:27 Ven joined #moarvm
09:30 robertle joined #moarvm
10:04 brrt joined #moarvm
11:00 lizmat good *, #moarvm!
11:00 lizmat timotimo: glad to see you got home safely
11:00 brrt good * lizmat
11:01 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 lizmat assuming nothing else is going on
11:07 jnthn Yes, because batching/joining are also scheduled tasks
11:07 lizmat ok, just checking  :-)
11:07 jnthn The degree is interpreted as the degree of parallelism of the stages that we can distribute, but excludes infrastructural things.
11:09 lizmat hmmm...  if I run the snapper with 0.001  (as in 10x as much as the supervisor)
11:10 avar joined #moarvm
11:10 avar joined #moarvm
11:10 lizmat usually the period is about 1350 microseconds
11:11 lizmat but sometimes it is 7-8x as much, between 10K and 12K microseconds, but not additional CPU usage
11:11 lizmat I guess that's either libuv or GC kicking in, at that level ?
11:11 jnthn GC can take some miliseconds
11:12 lizmat yeah, looks like that
11:12 lizmat BTW, is there a way to find out how many GC's have been done ?
11:12 lizmat is there an nqp:: op for that ?
11:12 jnthn --profile
11:12 lizmat I mean, while executing  :-)
11:12 jnthn Not without using the profiler, no
11:12 lizmat would it be easy to expose this as an nqp::op ?
11:13 jnthn "it depends"
11:13 lizmat hehe, I'm not sure I'm going to like the answer  :-)
11:13 jnthn In that yes, there's a number we can easily expose
11:13 jnthn But what about other backends?
11:13 lizmat on other backends it will always be 0
11:14 lizmat and I'd settle for some #?if moar code for now, as to not have to burden the other backends at this time
11:37 jnthn I guess the thing thing is whether one number (how many GC runs) is useful :)
11:37 jnthn I guess maybe it is.
11:37 jnthn We don't currently count (unless profiling) the number of full GCs
11:38 jnthn The only reason we have the number of GC runs is because we use it as a sequence number
11:38 jnthn To check if somnething was seen in this GC run, as well as for debug output
11:42 lizmat well, I'd like to be able to crossreference it with other numbers
11:42 lizmat to see patterns
12:08 Ven joined #moarvm
12:34 timotimo see the "vmhealth" branch for an example op that counts - among other things - how many GC runs have happened sofar
12:40 lizmat jnthn: sanity check: Worker.run-one is supposed to run 1 job every time it is called, right ?
12:46 Ven_ joined #moarvm
12:52 lizmat jnthn: from what I can see, this does not appear to be the case  :-(
12:53 zakharyas joined #moarvm
13:03 jnthn Not sure what "job" means in this context, but it's called once per queue item
13:11 jnthn 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 ?
13:12 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) ?
13:12 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
13:12 jnthn Yes
13:13 jnthn 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 ?
13:14 jnthn No, but note that the bathcer and the joiner use non-blocking awaits
13:14 jnthn *batcher
13:15 jnthn 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:16 jnthn *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
13:16 lizmat should that count the number of tasks completed ?
13:16 jnthn It'd count the number of queue items completed
13:16 jnthn If you want to count directly scheduled stuff, I guess you'd want to do it in .cue
13:16 lizmat which in the case of ^200 .hyper would be 4, right ?
13:17 jnthn But that'd miss events from the outside world
13:17 jnthn Well, but as I mentioned, the batch/join workers are probably a call to .cue each too
13:17 lizmat ok, so it could be *more*, it shouldn't be less, right ?
13:18 jnthn Right
13:18 lizmat hmmm...
13:18 lizmat ok, lemme do some more research and grokking  :-)
13:23 jnthn fwiw https://github.com/rakudo/rakudo/blob/master/src/core/Rakudo/Internals/HyperPipeline.pm is where all the hyper/race-related starts happen
13:27 ilmari joined #moarvm
14:37 AlexDaniel joined #moarvm
14:41 Ven joined #moarvm
14:48 zakharyas joined #moarvm
15:50 domidumont joined #moarvm
15:57 domidumont joined #moarvm
16:08 brrt joined #moarvm
16:33 Ven joined #moarvm
17:01 domidumont joined #moarvm
17:08 zakharyas joined #moarvm
17:12 releasable6 joined #moarvm
17:16 eater joined #moarvm
17:23 domidumont joined #moarvm
18:15 Ven joined #moarvm
18:52 timotimo jnthn: any progress on CStructArray?
19:23 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:24 Ven joined #moarvm
19:24 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:25 timotimo btw, cro now installs without --/test on latest rakudo after i did a two-line patch in yamlish
19:25 jnthn Oh, nice :)
19:25 jnthn (About Cro, not about catching a cold soon.)
19:26 timotimo of course
19:26 jnthn Mine is...not bad, I just feel tired all the time, and generally under the weather
19:26 timotimo it looks like it also succeeded just fine on 2017.09
19:50 timotimo anyway, i wish you a swift recovery of course :)
20:54 evalable6 joined #moarvm
21:49 Ven joined #moarvm
22:01 colomon joined #moarvm
22:03 colomon joined #moarvm
23:25 Geth ¦ MoarVM: 11ab1dcbe5 | (Samantha McVey)++ | src/strings/ops.c
23:25 Geth ¦ MoarVM: join: factor code into join_get_str_from_pos() function
23:25 Geth ¦ MoarVM:
23:25 Geth ¦ MoarVM: Function returns the string by two methods depending on if the array is
23:25 Geth ¦ MoarVM: an object array or a string array.
23:25 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/11ab1dcbe5
23:25 Geth ¦ MoarVM: 4136ae2565 | (Samantha McVey)++ | src/strings/ops.c
23:25 Geth ¦ MoarVM: speed up join of longer strings by a significant amount
23:25 Geth ¦ MoarVM:
23:25 Geth ¦ MoarVM: Here we concat multiple times for >300 graphemes per string or if
23:25 Geth ¦ MoarVM: there's <4 pieces and >150 graphemes per string.
23:25 Geth ¦ MoarVM:
23:25 Geth ¦ MoarVM: This can be up to 10x faster for joining very long strings. The
23:25 Geth ¦ MoarVM: conditions were created after extensive testing of joining strings with
23:25 Geth ¦ MoarVM: a separator.
23:25 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4136ae2565
23:25 Geth ¦ MoarVM: 8c1584bc5c | (Samantha McVey)++ (committed using GitHub Web editor) | src/strings/ops.c
23:25 Geth ¦ MoarVM: Merge pull request #743 from samcv/join-concat
23:25 Geth ¦ MoarVM:
23:25 Geth ¦ MoarVM: Speed up concat of longer strings by a significant amount
23:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8c1584bc5c
23:39 Zoffix MoarVM build fails on Windows: https://ci.appveyor.com/project/rakudo/rakudo/build/1.0.295/job/gyllyligxmox1gy6
23:40 Zoffix 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: https://gist.github.com/zoffixznet/a7bc53d214d011ef0a892074733222d0
23:40 Zoffix Oh wait. It just warns about that stuff
23:41 jnthn Yeah, that's just a warning
23:41 jnthn The actual error looks further on
23:41 jnthn I tried to figure out how to fix dynasm once, 'cus it spewed a gazillion of those warnings
23:41 jnthn Then got fed up and stuck the warning pragma in
23:42 jnthn To disable the warning in that file
23:42 jnthn So now it does one warning, 'cus I didn't manage to get it to spit out the pragma earlier than that :P
23:42 jnthn (It probably just needs somebody more patient than me to fiddle with dynasm.)
23:43 Zoffix Oh damn
23:43 Zoffix Neveeerr mind. This fail is from a month ago 'cause PR was subitted a month ago -_-
23:44 Zoffix This was the MIN macro issue
23:44 jnthn oh
23:44 jnthn phew :)
23:54 jnthn Sleep time o/

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary