| 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 | ||
| nice | |||
| 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 | ||
| Yes | |||
| 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 | |
| *batcher | |||
| 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. |
23:25 | |
| 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 | ||