[00:35] *** pamplemousse__ joined [00:47] *** Geth left [00:48] *** Geth joined [00:49] *** pamplemousse__ left [04:43] *** linkable6 left [04:43] *** evalable6 left [04:43] *** tellable6 left [04:44] *** evalable6 joined [04:45] *** linkable6 joined [04:45] *** tellable6 joined [05:02] good *, #moarvm [06:55] *** Altai-man joined [07:16] *** domidumont joined [07:44] *** zakharyas joined [07:59] *** zakharyas left [08:01] *** Altai-man left [08:06] *** zakharyas joined [08:22] *** zakharyas left [08:24] *** zakharyas joined [11:13] anyone have a suggestion for this weird problem i'm seeing? or want to look at the diff i posted earlier? i think the problem is not in bigintops.c (well, at least not the math ops implementations) since the math tests are ok for the most part [11:20] *** leont joined [11:27] MasterDuke: I understand that today is a public holiday in the Czech Republic, and jnthn is enjoying some R&R, so don't expect anything from him today [11:28] also not from me, as this is way outside of my thinking cap [11:30] *** zakharyas left [11:32] eh, i bet i've made a silly error. accidentally deleted an extra line somewhere when removing libtommath code, etc. i think almost anyone with a fresh pair of eyes could look at the diff and might spot something [11:39] MasterDuke: if nobody has looked at it before I finish today's RWN, I will have a look :-) [11:40] lizmat: thanks. nobody should feel they have to, but it is appreciated [11:59] *** pamplemousse__ joined [12:06] MasterDuke: what were the performance improvements again wrt to nqp::isprime_I ? [12:06] * lizmat should read to complete commit message [12:06] sorry for the nois [12:06] s [12:06] e [12:06] s [12:09] *** brrt joined [12:09] *** sena_kun joined [12:27] lizmat: you got what you needed from the commit message? [12:27] yeah :-) [12:27] 300000x as fast down to 2.5x as fast :-) [12:27] heh [12:53] *** zakharyas joined [13:00] *** brrt left [13:20] *** domidumont left [13:23] *** domidumont joined [13:28] *** domidumont left [13:40] *** brrt joined [13:42] *** domidumont joined [14:30] *** MasterDuke left [14:40] *** MasterDuke joined [14:41] hm. i looked through my diff and didn't see anything terribly off. i did find a minor mistake, but it wasn't relevant to the problem i'm seeing [14:43] *** zakharyas left [14:50] ¦ MoarVM/hash-fix-fix: 8852896dc1 | (Nicholas Clark)++ | 5 files [14:50] ¦ MoarVM/hash-fix-fix: A more complete fix for the hash max probe distance bug. [14:50] ¦ MoarVM/hash-fix-fix: [14:50] ¦ MoarVM/hash-fix-fix: commit 25c70bfe01eb6404 only actually fixed one of two possible places where [14:50] ¦ MoarVM/hash-fix-fix: this bug could occur: [14:50] ¦ MoarVM/hash-fix-fix: Hash tables must also resize if the max probe distance is hit on an empty slot. [14:50] ¦ MoarVM/hash-fix-fix: [14:50] ¦ MoarVM/hash-fix-fix: Not just for the case of max probe distance being hit during the move [14:50] ¦ MoarVM/hash-fix-fix: <…commit message has 15 more lines…> [14:50] ¦ MoarVM/hash-fix-fix: review: https://github.com/MoarVM/MoarVM/commit/8852896dc1 [14:50] ¦ MoarVM/hash-fix-fix: a27c78829a | (Nicholas Clark)++ | 2 files [14:51] ¦ MoarVM/hash-fix-fix: The lookup table in MVP_round_up_log_base2() can be uint8_t. [14:51] ¦ MoarVM/hash-fix-fix: [14:51] ¦ MoarVM/hash-fix-fix: All values are small enough to fit into one byte, so shrink the table by [14:51] ¦ MoarVM/hash-fix-fix: 96 bytes. [14:51] ¦ MoarVM/hash-fix-fix: [14:51] ¦ MoarVM/hash-fix-fix: Also store the value pre-computed with "plus 1", instead of doing the [14:51] ¦ MoarVM/hash-fix-fix: addition as part of the return expression. This saves an instruction. [14:51] ¦ MoarVM/hash-fix-fix: [14:51] ¦ MoarVM/hash-fix-fix: Fix a typo in an enum, spotted by timotimo. [14:51] ¦ MoarVM/hash-fix-fix: review: https://github.com/MoarVM/MoarVM/commit/a27c78829a [14:51] ¦ MoarVM: nwc10++ created pull request #1356: Hash fix fix [14:51] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1356 [14:56] *** Altai-man joined [14:56] *** zakharyas joined [14:58] *** sena_kun left [15:21] <[Coke]> FICK. [15:29] ex-FICK [15:31] ¦ MoarVM: 8852896dc1 | (Nicholas Clark)++ | 5 files [15:31] ¦ MoarVM: A more complete fix for the hash max probe distance bug. [15:31] ¦ MoarVM: [15:31] ¦ MoarVM: commit 25c70bfe01eb6404 only actually fixed one of two possible places where [15:31] ¦ MoarVM: this bug could occur: [15:31] ¦ MoarVM: Hash tables must also resize if the max probe distance is hit on an empty slot. [15:31] ¦ MoarVM: [15:31] ¦ MoarVM: Not just for the case of max probe distance being hit during the move [15:31] ¦ MoarVM: <…commit message has 15 more lines…> [15:31] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8852896dc1 [15:31] ¦ MoarVM: a27c78829a | (Nicholas Clark)++ | 2 files [15:31] ¦ MoarVM: The lookup table in MVP_round_up_log_base2() can be uint8_t. [15:31] ¦ MoarVM: [15:31] ¦ MoarVM: All values are small enough to fit into one byte, so shrink the table by [15:31] ¦ MoarVM: 96 bytes. [15:31] ¦ MoarVM: [15:31] ¦ MoarVM: Also store the value pre-computed with "plus 1", instead of doing the [15:31] ¦ MoarVM: addition as part of the return expression. This saves an instruction. [15:31] ¦ MoarVM: [15:31] ¦ MoarVM: Fix a typo in an enum, spotted by timotimo. [15:31] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a27c78829a [16:00] *** pamplemousse__ left [16:16] *** samcv joined [16:17] *** brrt left [16:42] *** domidumont left [16:50] and yet another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2020/09/28/2020-39-the-releaser/ [17:06] *** pamplemousse__ joined [17:38] *** zakharyas left [18:02] lizmat++ fwiw, the significant speedup in is-prime is up to 2 billion [18:18] *** brrt joined [18:57] *** sena_kun joined [18:59] *** Altai-man left [19:05] *** zakharyas joined [19:20] ¦ MoarVM/hash-debug: 0015fd05bd | (Nicholas Clark)++ | 3 files [19:20] ¦ MoarVM/hash-debug: Re-instate meaningful hash iterator debugging inside HASH_DEBUG_ITER. [19:20] ¦ MoarVM/hash-debug: [19:20] ¦ MoarVM/hash-debug: The previous debugging code was removed as part of commit bac1ae1cf74f2917: [19:20] ¦ MoarVM/hash-debug: Re-implement MVMStrHashTable as a Robin Hood Hash. [19:20] ¦ MoarVM/hash-debug: [19:20] ¦ MoarVM/hash-debug: and never added back. [19:20] ¦ MoarVM/hash-debug: review: https://github.com/MoarVM/MoarVM/commit/0015fd05bd [19:20] ¦ MoarVM/hash-debug: fb99295086 | (Nicholas Clark)++ | 4 files [19:20] ¦ MoarVM/hash-debug: Add MVM_str_hash_iterator_target_deleted() for HASH_DEBUG_ITER. [19:20] ¦ MoarVM/hash-debug: [19:20] ¦ MoarVM/hash-debug: This name is rather a mouthful, but it describes the logic that this [19:20] ¦ MoarVM/hash-debug: function encapsulates - does this hash iterator point to an entry that has [19:20] ¦ MoarVM/hash-debug: been deleted. This avoids repeating implementation details in four places. [19:20] ¦ MoarVM/hash-debug: review: https://github.com/MoarVM/MoarVM/commit/fb99295086 [19:20] ¦ MoarVM: nwc10++ created pull request #1357: Hash debug [19:20] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1357 [19:39] MasterDuke: yeah, but that is getting close to practically infinitely faster [19:39] lizmat: sorry, i meant it's not the first 100k that are faster, it's the first 2B [19:40] aaaah... ok [19:40] ok, I'll fix that [19:41] updated [19:41] lizmat++ [20:11] *** pamplemousse__ left [20:22] MasterDuke: stupid question, when you're implementing cmp are you then removing all traces of libtommath in your patch? [20:22] *gmp [20:22] well, that'll be the plan [20:23] in your diff there seems to be a reference left, i.e. an #include but perhaps that's according to plan? [20:27] ah, that was an oversight. don't think it should have caused the problem, but trying now [20:28] well. it's all I've seen so far anyways :) [20:33] good catch, but nope, didn't fix it [20:35] darn [20:39] have you tried with the JIT turned off? [20:39] yep, and spesh off [20:39] gist updated to latest changes [20:40] asan? [20:40] ooo, i thought about that and valgrind last night and then forgot to try, thanks for the reminder [20:44] no valgrind complaint [20:44] dogbert17: i almost never use asan, how do i build with it? [20:47] MasterDuke: I tend to use 'perl Configure.pl --debug --asan --no-optimize --prefix=../../install/' in my MoarVM dir [20:47] the prefix might be different for you I guess [20:49] ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD [20:50] did you try to run something? [20:50] it is first in my Makefile, but i guess i need to rebuild all the 3rdparty lib also [20:50] yeah [20:50] I get that sometimes and then I use LD_PRELOAD [20:50] ah. what path do you give it [20:51] I cheat and use strace to see what it is looking for :) [20:53] ha, that did work [20:53] something like 'strace -e openat ./perl6-m ' [20:53] cool [20:53] then you might want to set the following env variable as well: ASAN_OPTIONS="detect_leaks=0" [20:54] otherwise you will get test failures which are actually memory leaks [20:54] ah, i get one leak reported with my example, no output otherwise [20:55] and no nasty errors [20:55] none [20:56] and it still doesn't work properly [20:56] yup [20:56] hmm ... [20:57] the only additional thing I can think of atm is to run something like cppcheck on your MoarVM changes and see if it turns up anything [21:02] *** sena_kun left [21:03] *** zakharyas left [21:08] nwc10: cppcheck warns about this https://github.com/MoarVM/MoarVM/blob/master/src/core/fixkey_hash_table.c#L114-L115 that "Size of pointer 'entry_raw' used instead of size of its data. This is likely to lead to a buffer overflow. You probably intend to write 'sizeof(*entry_raw)'." [21:17] but, nothing useful about my changes... [21:23] *** brrt left [22:26] ha, it'll be the size of a pointer either way though [23:19] *** leont left [23:40] *** ggoebel left [23:45] *** ggoebel joined