Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-10-31

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

All times shown according to UTC.

Time Nick Message
00:25 Geth ¦ MoarVM: 19245a16c3 | (Samantha McVey)++ | 3 files
00:25 Geth ¦ MoarVM: Resolve unassigned codepoints as the defualt property values
00:25 Geth ¦ MoarVM:
00:25 Geth ¦ MoarVM: Fixes bug with non-characters not returning "Cn" General Category.
00:25 Geth ¦ MoarVM: Likely fixes other issues as well.
00:25 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/19245a16c3
00:25 samcv yay
00:29 lizmat :-)
01:14 colomon_ joined #moarvm
02:57 ilbot3 joined #moarvm
02:57 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:58 colomon joined #moarvm
07:58 domidumont joined #moarvm
08:04 domidumont joined #moarvm
08:50 domidumont joined #moarvm
09:18 robertle joined #moarvm
09:48 nwc10 joined #moarvm
09:49 cog_ joined #moarvm
09:52 cog__ joined #moarvm
10:04 coverable6 joined #moarvm
10:04 unicodable6 joined #moarvm
10:04 evalable6 joined #moarvm
10:09 perlawhirl joined #moarvm
11:22 zakharyas joined #moarvm
11:42 cognominal joined #moarvm
13:44 brrt joined #moarvm
13:55 timotimo jnthn: you wanted me to remind you of the cstructarray pr :)
13:55 timotimo food time!
14:01 * jnthn eats the PR
14:01 jnthn Oh, wait...
14:07 brrt joined #moarvm
14:31 lizmat some kind of Czech dish ?
15:04 zakharyas joined #moarvm
15:43 zakharyas joined #moarvm
16:08 timotimo i have a benchmark that spends a lot of time in the spesh arg guard runner. turns out it's doing a whole lot of native_ref_fetch causing lots of repr_box_int; i bet we can change that so that it only checks "what's inside this ref?" rather than "gimme the contents. what is it?"
16:08 timotimo (a lot of time, of course, is quite relative; it's not much in total, but it's like 5% of total time?)
16:28 dalek joined #moarvm
16:28 synopsebot joined #moarvm
16:34 Geth joined #moarvm
16:35 timotimo i'm not sure if i want to introduce a new guard op that directly checks for the resulting value's STable and that it's concrete
16:35 timotimo that'd directly target native refs
16:36 committable6 joined #moarvm
17:20 Ven joined #moarvm
17:37 jnthn timotimo: Hm, but the guard tree really shouldn't be being built in such a way that it tries to deref a native ref in the first place
17:38 timotimo all i know is that callgrind shows it calls native_ref_fetch a bunch of times
17:38 jnthn And derefs are always guarded by the check on the stable
17:38 jnthn So I think it's doing something it shouldn't be.
17:38 jnthn And could perhaps be fixed by making it not stick a deref in the guard tree
17:39 timotimo 879_416 calls are native_ref_fetch, 1_757_724 to rakudo_scalar_fetch
17:40 timotimo right, then it'd have to check against IntLexRef or IntPosRef rather than Int for the conc value check that's next?
17:40 jnthn But IntLexRef is a container type already
17:42 jnthn The guard tree looks at the type of the argument
17:42 jnthn And only then derefs and looks inside it
17:42 jnthn But for an IntLexRef it should just see it's that, and decide it's done or not
17:42 jnthn Not look inside at all
17:44 timotimo unfortunately i don't konw which exact arg guard tree it's doing that for
17:44 timotimo i can gdb it
17:44 jnthn Guard tress are dumped into the spesh log also
17:47 timotimo yup
17:47 timotimo but not really easily identifiable
17:48 timotimo there's no simple way to "break in this function but only if that other function is on the call stack" in gdb?
17:48 jnthn Hmm...can't think of one
17:48 jnthn Though could you do a conditional breakpoint in the arg guard tree on the REPR ID of the thing being deref'd?
17:48 jnthn For if it's something that's not a P6opaque?
17:53 timotimo probably
17:54 timotimo here's a suggestion to have a breakpoint in the "outer" function that enables the breakpoint on the "inner" function when entered and another that disables it when leaving the function
18:00 timotimo wow the conditional breakpoint is incredibly slow it looks like
18:00 timotimo (conditional on test->st->container_spec being not rakudo_scalar)
18:07 timotimo it's not getting hit :\
18:17 zakharyas joined #moarvm
18:22 samcv good *
18:37 domidumont joined #moarvm
19:25 Ven joined #moarvm
19:59 lizmat joined #moarvm
20:24 timotimo well, the breakpoint didn't get hit during all the time i was afk
20:24 timotimo but it did for some reason fill up my ram quite nicely :|
20:26 AlexDaniel joined #moarvm
20:28 [Coke] 19:26 -!- Ven is now known as Guest53736
20:28 [Coke] oops. :)
20:28 Guest53736 uhm?
20:28 [Coke] accidental cut and paste.
20:28 Ven`` [Coke]: much better :p
20:38 timotimo well, i can no longer reproduce the native ref fetch from the arg guards
20:38 timotimo i must have run some different workload, or some change i made to the code made it go away
20:47 timotimo i have no clue how i got this data
20:47 timotimo i don't *think* there was an outdated callgrind file in that folder from long ago?
21:12 SourceBaby joined #moarvm
21:43 Ven joined #moarvm
21:55 lizmat jnthn: I guess my mental image of how the ThreadPoolScheduler works is flawed
21:55 lizmat somehow I thought that with a given input, say my @primes = ^50000 .hyper.grep: *.is-prime
21:56 lizmat you would always have the same number of tasks completed
21:56 lizmat I mean,. distributed over different number of threads, and other orders and what not
21:58 lizmat I've seen the number of completed tasks for the above code vary between 1596 and 1956
21:58 lizmat which I think is a wide range
21:58 timotimo maybe that's because if one of the workers "awaits" for new work that it either immediately continues or suspends itself into the job pool?
22:05 timotimo turns out if you compile moarvm with --optimize=3 instead of --optimize=0 ...
22:09 timotimo lizmat: -McSnapper
22:30 Geth ¦ MoarVM: samcv++ created pull request #743: Speed up concat of longer strings by a significant amount
22:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/743
22:30 Ven joined #moarvm
22:41 jnthn lizmat: How are you counting completed tasks?
22:42 lizmat I've added a $!total attribute to the Worker role which gets updated inside take-completed
22:42 lizmat that's what's being used for that tally
22:42 jnthn Ah, that should be relatively accurate
22:43 jnthn What timotimo said would apply though
22:43 lizmat yes, since the Workers get updated serially by the supervisor
22:43 lizmat that should be lossless
22:43 jnthn Right
22:44 jnthn Yeah, I guess it's exact to the last 10ms
22:44 lizmat yeah, but in our examples, all tasks are done by the end anyway, there are no tasks left queuer
22:44 lizmat *queued
22:45 jnthn OK. Then my first guess would be that sometimes, we get awaits that are not yet completed or other non-blocking contention
22:46 jnthn Which result in continuations being scheduled
22:46 jnthn I agree it's a fairly wide range, though
22:46 lizmat but would those be registered as tasks though ?
22:46 lizmat as completed tasks even
22:47 jnthn Yes
22:47 lizmat ok
22:47 lizmat well, it's been a long day... and it was very late last night
22:47 jnthn See ThreadPoolAwaiter or whatever it's called :)
22:47 lizmat ok
22:47 jnthn Uh, but not today ;)
22:47 lizmat I'll look at it tomorrow  :-)
22:48 jnthn The thing you're looking for is the push onto the queue though :)
22:48 lizmat ok
23:12 * timotimo arrived at home safely

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