github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
04:53
nebuchadnezzar joined
05:31
robertle left
06:19
brrt joined,
domidumont joined
|
|||
brrt | \o | 06:22 | |
nwc10 | o/ | 06:26 | |
07:06
patrickb joined
|
|||
samcv | my mentee has now got mo | 07:14 | |
moarvm/nqp/rakudo building together, and now needs to go about testing it now that it's put into moarvm. i asked him to write up a blog post to explain what he has done so far | |||
patrickb | samcv: Sounds great! | 07:22 | |
07:22
domidumont1 joined
|
|||
timotimo | now recording a profiled run with rr's "chaos" mode in the hopes that it'll recreate the problem with gc sequence numbers ... :| | 07:23 | |
07:25
domidumont left
|
|||
timotimo | it might take half an eternity | 07:30 | |
08:02
zakharyas joined
|
|||
timotimo | nope. my hard drive ran full and everything came crashing down :) | 08:04 | |
08:46
domidumont1 left
08:51
domidumont joined
09:30
domidumont left
09:51
MasterDuke left
10:06
zakharyas left
10:20
sena_kun joined
11:19
brrt left
11:27
brrt joined
11:33
brrt left
12:14
domidumont joined
12:28
domidumont1 joined
12:31
domidumont left
12:34
domidumont joined
12:35
domidumont1 left
12:38
zakharyas joined
13:10
brrt joined
13:14
brrt` joined
13:15
brrt left
13:20
domidumont1 joined
13:23
domidumont left
|
|||
brrt` | I may have conditional jumps wrong in the floating point variant | 14:05 | |
14:05
brrt` is now known as brrt
|
|||
brrt | problem is, there's not even a way to check | 14:06 | |
timotimo | there isn't? | ||
ugexe | push it to master and let the general public sort it out | ||
brrt | no. No templates even use the conditional-branch variant comparison | ||
timotimo | so it hasn't been necessary yet? | ||
brrt | nope | 14:07 | |
but I also don't want it to become necessary when I'm debugging an issue :-D | |||
timotimo | and you can't just quickly steal an unassigned or deprecated op for trying it? | ||
brrt | of course I could | 14:08 | |
but where would be the challenge in that | |||
timotimo | ah | ||
brrt | :-D | ||
timotimo | of course | ||
brrt | I guess I'm saying, I still want my spesh/JIT testing tool | ||
timotimo | atan2 is always a good candidate because almost nothing needs that | ||
yeah | |||
brrt | lol. yeah, atan2 could be a thing | ||
timotimo... what was it that you called, to have type-specific JIT fragments | 14:11 | ||
timotimo | devirtualization? | ||
that's how we call it in the lego jit | |||
since we get rid of checking a given REPR for its ops at run time and do it at jit time instead | 14:12 | ||
brrt | devirtualizaiton | ||
thank you | |||
timotimo | YW | ||
also thank you very much if you build it soon :) :) | |||
brrt | okay, it's on the list | ||
timotimo | i was wondering if there ought to be a variant of "load" that says "oh btw if the type in this register is known, this can be jit-time evaluated" | 14:14 | |
or how else to expose that functionality | 14:15 | ||
14:33
domidumont joined
14:34
brrt left
14:36
domidumont1 left
14:43
lucasb joined
14:44
pamplemousse joined
14:52
TimToady joined
15:01
dogbert11 left
15:23
patrickb left
15:24
MasterDuke joined
15:41
Kaypie left
15:42
Kaypie joined
16:05
domidumont left
16:38
Kaypie is now known as Kaiepi
|
|||
nine | timotimo: compunits may share serialization contexts. Think BEGIN time EVAL | 16:45 | |
timotimo | ah, that's good to know | 16:46 | |
i would have thought that'd have it in one and just one CU depend on the other one that has the SC | |||
17:26
klapperl joined
|
|||
timotimo | smrt_intify could get a jit, i see something bail from that | 17:58 | |
17:58
MasterDuke left
18:26
pamplemousse left
18:30
zakharyas left
18:34
MasterDuke joined
|
|||
MasterDuke | timotimo: github.com/MoarVM/MoarVM/pull/1133 | 18:34 | |
18:43
lucasb left
|
|||
Geth | MoarVM: 6cecad741a | (Samantha McVey)++ | docs/ChangeLog Update ChangeLog in preparation for release |
18:52 | |
japhb | \o/ Release prep! | 18:55 | |
timotimo | ah, that looks good | 19:02 | |
MasterDuke | timotimo: the changelog or my PR? | 19:07 | |
timotimo | the PR | 19:10 | |
haven't looked at the CL yet | |||
MasterDuke | k, (selfishly glad to hear it) | 19:11 | |
timotimo | samcv: i'd probably put both lines about decodeconf and decoderepconf ops in one line | 19:14 | |
otherwise it looks good | |||
19:24
brrt joined
19:34
MasterDuke left
19:35
MasterDuke joined
19:54
pamplemousse2 joined
|
|||
brrt | \o | 19:56 | |
samcv | hey brrt | 19:59 | |
timotimo, is the new profiler stuff functional yet and usable? | 20:00 | ||
20:01
zakharyas joined
20:04
pamplemousse2 left
|
|||
brrt | hey samcv | 20:11 | |
timotimo | which new stuff exactly? the heap snapshot stuff isn't ready. the deallocations is fine except for the odd bug where sometimes two GC entries have the same sequence number | 20:14 | |
samcv | timotimo, confnprog | ||
Geth | MoarVM: 8196ea172b | (Samantha McVey)++ | tools/update-changelog.p6 Fix minor formatting bug in update-changelog.p6 [Why] Git tags were being formatted with both commas and spaces. They should only be separated by commas. |
20:42 | |
MoarVM: c00afcb655 | (Samantha McVey)++ | docs/ChangeLog Mention confprog in ChangeLog |
|||
20:42
zakharyas left
|
|||
Kaiepi | is there a reason why nativecall treats all strings like utf8 strings in certain cases and doesn't bother trying to jit strings that aren't utf8 | 20:53 | |
timotimo | samcv: confprog is at least already in and active :) | 20:55 | |
Kaiepi: excuse me, "jit strings"? | |||
Geth | MoarVM/refs/tags/2019.07: 446b27b602 | (Samantha McVey)++ | VERSION Bump VERSION for release |
20:57 | |
MoarVM: 446b27b602 | (Samantha McVey)++ | VERSION Bump VERSION for release |
|||
Kaiepi | MVM_nativecall_jit_graph_for_caller_code only jits utf8 strings, nativecall_cast treats all strings as if they're utf8 | ||
timotimo, | |||
it's really simple to make both these work properly with all types of strings, just i was wondering if there was a specific reason why they don't | 20:59 | ||
MasterDuke | samcv++ | 21:03 | |
Geth | MoarVM: MasterDuke17++ created pull request #1136: Jit captureposarg_n |
21:07 | |
MasterDuke | timotimo: does ^^^ look good? if so, i'll go ahead and merge it and github.com/MoarVM/MoarVM/pull/1133 now that we've had a release | 21:08 | |
21:37
squashable6 left
21:38
squashable6 joined
|
|||
japhb | Is the release complete at this point? It's always hard to tell if there's anything left to do ... | 21:39 | |
Ah! I see in the other channel samcv++ announced it was done | 21:40 | ||
22:17
brrt left
22:42
Altai-man_ joined,
Altai-man_ left
22:45
sena_kun left
|
|||
jnthn | samcv++ # release | 22:55 | |
timotimo | roohay | ||
jnthn | Back to breaking stuff. \o/ ;0 | 22:58 | |
timotimo: Do you know if the profiler's SQL output contains info on all threads? | |||
timotimo | threads that have been deleted will not stay present | 22:59 | |
there.s not yet a mechanism to keep their data around | |||
jnthn | OK, but I'm thinking the thread pool | 23:00 | |
timotimo | and since the thread only gets an entry in the gc log if it participates, it could happen that a thread could be missed in a profile | ||
by being blocked the entire time | |||
jnthn | That's also probably fine enough | ||
timotimo | other than that, yeah, they should show up, and you can tell which thread got spawned by what thread | ||
and looking at the topmost few frames you should be able to find out what's a worker and what's the supervisor and all that | 23:01 | ||
what i don't have yet, and am not sure whether to include, is to keep around what call graph node spawned the thread in question | |||
23:53
MasterDuke left
|