github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:35 pamplemousse__ joined 00:47 Geth left 00:48 Geth joined 00:49 pamplemousse__ left 04:43 linkable6 left, evalable6 left, tellable6 left 04:44 evalable6 joined 04:45 linkable6 joined, tellable6 joined
nwc10 good *, #moarvm 05:02
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
MasterDuke 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:13
11:20 leont joined
lizmat 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:27
also not from me, as this is way outside of my thinking cap 11:28
11:30 zakharyas left
MasterDuke 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:32
lizmat MasterDuke: if nobody has looked at it before I finish today's RWN, I will have a look :-) 11:39
MasterDuke lizmat: thanks. nobody should feel they have to, but it is appreciated 11:40
11:59 pamplemousse__ joined
lizmat MasterDuke: what were the performance improvements again wrt to nqp::isprime_I ? 12:06
lizmat should read to complete commit message
sorry for the nois
s
e
s
12:09 brrt joined, sena_kun joined
MasterDuke lizmat: you got what you needed from the commit message? 12:27
lizmat yeah :-)
300000x as fast down to 2.5x as fast :-)
MasterDuke 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
MasterDuke 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:41
14:43 zakharyas left
Geth MoarVM/hash-fix-fix: 8852896dc1 | (Nicholas Clark)++ | 5 files
A more complete fix for the hash max probe distance bug.

commit 25c70bfe01eb6404 only actually fixed one of two possible places where this bug could occur:
   Hash tables must also resize if the max probe distance is hit on an empty slot.
   Not just for the case of max probe distance being hit during the move
... (15 more lines)		 14:50
MoarVM/hash-fix-fix: a27c78829a | (Nicholas Clark)++ | 2 files
The lookup table in MVP_round_up_log_base2() can be uint8_t.

All values are small enough to fit into one byte, so shrink the table by 96 bytes.
Also store the value pre-computed with "plus 1", instead of doing the addition as part of the return expression. This saves an instruction.
Fix a typo in an enum, spotted by timotimo.
MoarVM: nwc10++ created pull request #1356:
Hash fix fix
14:56 Altai-man joined, zakharyas joined 14:58 sena_kun left
[Coke] FICK. 15:21
nwc10 ex-FICK 15:29
Geth MoarVM: 8852896dc1 | (Nicholas Clark)++ | 5 files
A more complete fix for the hash max probe distance bug.

commit 25c70bfe01eb6404 only actually fixed one of two possible places where this bug could occur:
   Hash tables must also resize if the max probe distance is hit on an empty slot.
   Not just for the case of max probe distance being hit during the move
... (15 more lines)		 15:31
MoarVM: a27c78829a | (Nicholas Clark)++ | 2 files
The lookup table in MVP_round_up_log_base2() can be uint8_t.

All values are small enough to fit into one byte, so shrink the table by 96 bytes.
Also store the value pre-computed with "plus 1", instead of doing the addition as part of the return expression. This saves an instruction.
Fix a typo in an enum, spotted by timotimo.
16:00 pamplemousse__ left 16:16 samcv joined 16:17 brrt left 16:42 domidumont left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/09/28/2020-...-releaser/ 16:50
17:06 pamplemousse__ joined 17:38 zakharyas left
MasterDuke lizmat++ fwiw, the significant speedup in is-prime is up to 2 billion 18:02
18:18 brrt joined 18:57 sena_kun joined 18:59 Altai-man left 19:05 zakharyas joined
Geth MoarVM/hash-debug: 0015fd05bd | (Nicholas Clark)++ | 3 files
Re-instate meaningful hash iterator debugging inside HASH_DEBUG_ITER.

The previous debugging code was removed as part of commit bac1ae1cf74f2917:
   Re-implement MVMStrHashTable as a Robin Hood Hash.
and never added back.		 19:20
MoarVM/hash-debug: fb99295086 | (Nicholas Clark)++ | 4 files
Add MVM_str_hash_iterator_target_deleted() for HASH_DEBUG_ITER.

This name is rather a mouthful, but it describes the logic that this function encapsulates - does this hash iterator point to an entry that has been deleted. This avoids repeating implementation details in four places.
MoarVM: nwc10++ created pull request #1357:
Hash debug
lizmat MasterDuke: yeah, but that is getting close to practically infinitely faster 19:39
MasterDuke lizmat: sorry, i meant it's not the first 100k that are faster, it's the first 2B
lizmat aaaah... ok 19:40
ok, I'll fix that
updated 19:41
MasterDuke lizmat++
20:11 pamplemousse__ left
dogbert17 MasterDuke: stupid question, when you're implementing cmp are you then removing all traces of libtommath in your patch? 20:22
*gmp
MasterDuke well, that'll be the plan
dogbert17 in your diff there seems to be a reference left, i.e. an #include but perhaps that's according to plan? 20:23
MasterDuke ah, that was an oversight. don't think it should have caused the problem, but trying now 20:27
dogbert17 well. it's all I've seen so far anyways :) 20:28
MasterDuke good catch, but nope, didn't fix it 20:33
dogbert17 darn 20:35
have you tried with the JIT turned off? 20:39
MasterDuke yep, and spesh off
gist updated to latest changes
dogbert17 asan? 20:40
MasterDuke ooo, i thought about that and valgrind last night and then forgot to try, thanks for the reminder
no valgrind complaint 20:44
dogbert17: i almost never use asan, how do i build with it?
dogbert17 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
MasterDuke 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:49
dogbert17 did you try to run something? 20:50
MasterDuke it is first in my Makefile, but i guess i need to rebuild all the 3rdparty lib also
yeah
dogbert17 I get that sometimes and then I use LD_PRELOAD
MasterDuke ah. what path do you give it
dogbert17 I cheat and use strace to see what it is looking for :) 20:51
MasterDuke ha, that did work 20:53
dogbert17 something like 'strace -e openat ./perl6-m <some code>'
cool
then you might want to set the following env variable as well: ASAN_OPTIONS="detect_leaks=0"
otherwise you will get test failures which are actually memory leaks 20:54
MasterDuke ah, i get one leak reported with my example, no output otherwise
dogbert17 and no nasty errors 20:55
MasterDuke none
dogbert17 and it still doesn't work properly 20:56
MasterDuke yup
dogbert17 hmm ...
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 20:57
21:02 sena_kun left 21:03 zakharyas left
MasterDuke nwc10: cppcheck warns about this github.com/MoarVM/MoarVM/blob/mast...#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:08
but, nothing useful about my changes... 21:17
21:23 brrt left
moon-child ha, it'll be the size of a pointer either way though 22:26
23:19 leont left 23:40 ggoebel left 23:45 ggoebel joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!