github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 05:02
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
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
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
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
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
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
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
[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.
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/09/28/2020-...-releaser/ 16:50
MasterDuke lizmat++ fwiw, the significant speedup in is-prime is up to 2 billion 18:02
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++
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
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
moon-child ha, it'll be the size of a pointer either way though 22:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!