Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-10-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 42! Congratulations to Zoffix! You win a roll of duck tape!
00:17 timo joined #moarvm
00:39 leont joined #moarvm
01:12 Ven`` joined #moarvm
01:55 ilbot3 joined #moarvm
01:55 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:49 TimToady joined #moarvm
03:10 squashable6 joined #moarvm
03:35 AlexDaniel squashable6: status
03:35 squashable6 AlexDaniel, ⚠? Next SQUASHathon in 5 days and ≈6 hours (2017-10-07 UTC-12⌁UTC+14). See https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day
04:24 Zoffix Oh awesome!
04:25 Zoffix Can never have too much ducktape
06:08 lizmat joined #moarvm
06:49 domidumont joined #moarvm
06:52 Geth ¦ MoarVM: 89ca8eb08e | (Stefan Seifert)++ | src/jit/graph.c
06:52 Geth ¦ MoarVM: Make "Can't find nc_site value on spesh ins" non-fatal
06:52 Geth ¦ MoarVM:
06:52 Geth ¦ MoarVM: No idea why, but some times spesh doesn't know the native call site
06:52 Geth ¦ MoarVM: value yet, but still tries to JIT compile the block. Make the error
06:52 Geth ¦ MoarVM: non-fatal as it'd be just a performance optimization.
06:52 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/89ca8eb08e
06:52 nine I'd really like to know how this ^^^ works
06:54 domidumont joined #moarvm
08:58 domidumont joined #moarvm
09:21 Ven`` joined #moarvm
10:16 evalable6 joined #moarvm
10:42 japhb joined #moarvm
11:41 MasterDuke jnthn: think it makes sense to try and use the FSA for DecodeStream's buffers?
11:48 jnthn It's not clear that it'd help much; we don't know the size up front
11:49 jnthn And we often take the chars buffer and stick it directly into an MVMString
11:49 jnthn To avoid copying
11:49 jnthn Which was important for performance
11:49 jnthn But in the MVMString we don't store the buffer size, just the string length, and growing every string to store two numbers isn't desirable
11:50 jnthn So it's hard to relesae those using the FSA
11:51 jnthn For the byte buffers, it can make sense, though the longer term plan is that we'll start using MultiDimArray instead of VMArray for blobs coming from I/O, and since those are immutable in terms of size we can avoid the copying entirely of incoming byte buffers, and just keep a reference alive to the array object
11:52 jnthn So that leaves the headers that point to the buffers. Those may make sense, though for chars we already keep one of them around and re-use it in common cases
12:05 nine jnthn: do you have any idea about this? https://github.com/MoarVM/MoarVM/commit/89ca8eb08e
12:05 jnthn nine: 'fraid not
12:06 MasterDuke jnthn: thanks. i'll leave the char buffers alone for now and maybe save the byte buffers for later
12:06 nine So it's not something to be expected that I'm just not aware of?
12:06 jnthn No, it's odd. I mean, spesh isn't entirely deterministric, but it's an odd thing to go missing
12:07 jnthn I'd take a look at the spesh log at the stats info
12:07 jnthn To see what it logged
12:07 jnthn That may give some hints as to what's going on
12:08 MasterDuke nine: does setting MVM_SPESH_BLOCKING=1 change anything?
12:10 MasterDuke jnthn: speaking of FSA and VMArray...how do https://github.com/MoarVM/MoarVM/pull/689 and https://github.com/MoarVM/MoarVM/pull/711 look?
12:10 nine Still there with MVM_SPESH_BLOCKING=1
12:11 timotimo that ought to at least make any flopping go away
12:11 jnthn MasterDuke: Don't have time to review them at the moment
12:11 jnthn Will try next week, though really want to get even-moar-jit review complete first
12:12 MasterDuke sure, no hurry, just making sure it isn't forgotten
12:12 timotimo Memcheck: mc_main.c:5831 (vgMemCheck_is_valid_aligned_word): Assertion 'VG_IS_WORD_ALIGNED(a)' failed.
12:12 timotimo why does it do that, i wonder
12:14 timotimo lol. searching for vgMemCheck_is_valid_aligned_word on google finds me *drumroll* a match from the moarvm irclog
12:18 nine jnthn: does it make more sense knowing that the native sub got inlined into a caller?
12:26 jnthn nine: Oh
12:26 jnthn nine: Yes
12:26 jnthn nine: We don't re-do facts and stuff in that case yet
12:27 jnthn The presumption is that the code being inlined was already specialized
12:27 jnthn For the case of the caller
12:27 jnthn So at the moment we do no more than just splice it in
12:28 nine Oh, so the native sub is in fact not specialized but will be JIT compiled as part of the caller?
12:29 jnthn Well, it already was specialized
12:29 jnthn We inline specializations
12:29 timotimo it just forgot the facts in the mean time
12:29 jnthn lunch, bbiab
12:29 nine Oh, that way around
12:29 nine jnthn: ok, thanks for clearing that up!
12:30 nine So as a solution we'd have to retain the facts for when we inline the code later on?
12:32 timotimo we can mark the ncinvoke op noinline :P
12:35 MasterDuke jnthn, timotimo: any suggestions on an easy optimization for MVM_sc_find_object_idx? https://github.com/MoarVM/MoarVM/blob/master/src/6model/sc.c#L90
12:36 MasterDuke perf shows that the second most expensive function when doing `./perl6-m tools/build/install-core-dist.pl /home/dan/Source/perl6/install/share/perl6`
12:36 MasterDuke the largest value for count (in the loop on line 99) is 161211, which occurs 54727 times (the most of any of the values for count)
12:37 timotimo oh? interesting!
12:37 timotimo how often does it go through to th efor loop?
12:38 MasterDuke as opposed to hitting the cache?
12:39 timotimo yeah
12:40 MasterDuke not sure, let me log it
12:43 MasterDuke 15344 cached, 62418 not
12:43 timotimo wow
12:44 timotimo i'm not sure what causes things to get cached
12:45 MasterDuke no idea here
12:45 timotimo i wonder if it's important that the indices have very specific values
12:45 timotimo i.e. can we sort by pointer value and binary search?
12:48 MasterDuke yeah, that's the only thing i could think of without knowing anything about the data
12:49 timotimo i mean, we can still have a sorted list of the pointers and an equivalent list of indices next to it
12:50 leont joined #moarvm
13:13 MasterDuke timotimo: do you know if sc->body->root_objects ever reaches a steady state?
13:15 timotimo i do not; it probably depends on whether we're currently creating this stuff or have loaded it from disc at one point?
13:40 evalable6 joined #moarvm
13:55 zakharyas joined #moarvm
14:07 MasterDuke_ joined #moarvm
17:00 Geth ¦ MoarVM: MasterDuke17++ created pull request #712: Convert realloc plus memset 0 to recalloc
17:00 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/712
17:18 domidumont joined #moarvm
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support: 4f68d71e92 | (Timo Paulssen)++ | src/core/fixedsizealloc.c
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support: FSA size debug: cooperate with valgrind
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support:
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support: when the free size is wrong, it gives the stack trace for
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support: where the corresponding data was allocated, how many bytes are
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support: marked "defined" by valgrind, and of course the current stacktrace.
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support: On top of that, it outputs the passed and expected size.
17:25 Geth ¦ MoarVM/fsa_valgrind_error_support: review: https://github.com/MoarVM/MoarVM/commit/4f68d71e92
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support: 483b3b8519 | (Timo Paulssen)++ | src/core/fixedsizealloc.c
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support: FSA size debug: cooperate with valgrind
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support:
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support: when the free size is wrong, it gives the stack trace for
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support: where the corresponding data was allocated, how many bytes are
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support: marked "defined" by valgrind, and of course the current stacktrace.
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support: On top of that, it outputs the passed and expected size.
17:33 Geth ¦ MoarVM/fsa_valgrind_error_support: review: https://github.com/MoarVM/MoarVM/commit/483b3b8519
17:33 timotimo had a missing curly brace there
17:33 Geth ¦ MoarVM: timo++ created pull request #713: FSA size debug: cooperate with valgrind
17:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/713
17:42 samcv releasable6, status
17:43 zakharyas joined #moarvm
17:44 releasable6 samcv, Next release in 20 days and ≈1 hour. R6 is down. Changelog for this release was not started yet
17:44 releasable6 samcv, Details: https://gist.github.com/bda894f10951580ec4c2c9bc64bc1ad5
17:54 Zoffix releasable6: status
17:55 Geth ¦ MoarVM: usev6++ created pull request #714: Fix getaddrinfo failing with EAI_HINTS on FreeBSD
17:55 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/714
17:56 * Zoffix see nothing down with R6 :\
17:56 releasable6 joined #moarvm
17:57 samcv good *
17:57 Zoffix \o
18:00 releasable6 joined #moarvm
18:18 samcv Zoffix, so unicode changed some of the annotations for emoji from 4-5, like "man in business suit levitating" to man in suit levitating. so i'm going to have to make sure we use all versions since we started, version 4
18:19 * Zoffix knows nothing about Unicode :)
18:19 samcv so you can do "man in business suit levitating: light skin tone" or "man in suit levitating: light skin tone". not sure why they changed it. since the name of the base character is "man in business suit levitating"
18:19 samcv Zoffix, well most things are nonchanging, but unicode doesn't purport the emoji sequence names to never change. and so one they changed it slightly. and i want to make sure that we have backward compatibiitiy
18:20 samcv since the names could change slightly
18:31 evalable6 joined #moarvm
18:32 domidumont joined #moarvm
19:15 zakharyas joined #moarvm
19:30 geekosaur joined #moarvm
20:13 leont joined #moarvm
20:55 geekosaur joined #moarvm
20:56 leont joined #moarvm
21:32 buggable joined #moarvm
21:43 leont joined #moarvm
22:03 buggable joined #moarvm
22:16 buggable joined #moarvm
22:25 buggable joined #moarvm
22:26 buggable joined #moarvm
22:45 arnsholt joined #moarvm
23:23 evalable6 joined #moarvm
23:28 nebuchadnezzar joined #moarvm

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