| IRC logs at
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 05:56
MasterDuke: thanks. In this case cppcheck is not correct 05:58
and it's arguably a bit silly, as I didn't write sizeof(entry_raw)
I wrote sizeof() with a type
and a type which is not the type of cntry_raw 05:59
07:25 brrt joined
nwc10 good *, brrt 07:36
brrt good * nwc10 :-) 07:38
another slog waiting for us 07:39
nwc10 slog? Something specific, or simply "Tuesday" ?
brrt I guess 'tuesday' 07:40
07:42 leont joined 07:44 zakharyas joined
MasterDuke nwc10: cool. i'll admit i didn't bother checking the checker and just passed on its warning 07:57
nwc10 I'm assuming that that was the only thing in the hash code that it grumbled about. If so, that's good
MasterDuke iirc, yes 07:58
nwc10 and there *might* still be buffer overflows. But all the regression tests pass under ASAN (and I wrote some more tests) so there aren't any *obvious* ones.
08:01 domidumont joined
MasterDuke wow. gmp really is quite a bit faster. `my ($a; $b; $c; $s); for 66..5_000 -> $e { $a = 23**$e; $b = 7**$e; $c = $a % $b; $c *= $c; $c += $a; $c -= $b; $s = ~$c }; say $s.substr(0, 10); say now - INIT now` takes about 35s with libtommath. on my gmp branch it takes 0.24s (and gives the same result) 08:25
moritz wow 08:30
is it the stringifcation that is slow in libtommath, or everything?
MasterDuke well, the stringification is *really* slow. but so far everything i've tested is slower to some degree 08:32
the difference is way less dramatic if i take out the stringification every loop 08:33
if i increase the range to 10_000, but don't stringify every iteration, libtommath is ~2.1s and gmp is ~0.36s 08:35
the stringification is definitely an algorithmic difference. my pure-Raku implementation of stringification using Barrett reduction was faster than libtomath at ~2**600 iirc 08:37
and i haven't yet gotten around to finalizing my implementation for libtommath... 08:38
08:46 domidumont left 09:30 harrow` left 09:32 harrow joined 09:36 domidumont joined 09:43 brrt left 10:09 brrt joined 11:16 brrt left 11:19 MasterDuke left 11:32 zakharyas left 11:39 MasterDuke joined
Geth MoarVM: 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.
MoarVM: 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.
12:21 MasterDuke left 12:38 pamplemousse__ joined 12:48 sena_kun joined 12:54 zakharyas joined 13:07 squashable6 left 13:08 squashable6 joined 13:10 MasterDuke joined
Geth MoarVM: 60070970c4 | (Nicholas Clark)++ | src/core/fixedsizealloc.c
oops if MVM_fixed_size_alloc() is called for a size of 0 bytes.

Previously this wasn't trapped. With FSA_SIZE_DEBUG enabled (not the default) everything works (it can allocate "0" bytes, as it adds its debugging record keeping to the size requested). With default settings, we corrupt the malloc heap, which doesn't get reported at the time, and may or may not get reported in any useful way later.
14:15 travis-ci joined
travis-ci MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. 14:15
14:15 travis-ci left
nwc10 dear travis dry-by bot - *what* failed? 14:19
timotimo dry-by, eh? 14:20
nwc10 er, drive-by
[Coke] looks like only some of the builds failed. one error is Error: retrieving gpg key timed out. 14:21
timotimo ah, ugh
one of our bots used to check what killed a travis build
nwc10 ah, I missed that it splats 2 URLs
timotimo i think it was one run by zoffix that hasn't been put back online by anybody else since he left
[Coke] I think someone with privs could re-start that job and hope it didn't time out this time
I can see the error, but don't see a "re-run" anywhere on the sub jobs. 14:22
timotimo let me have a look
how good that it has a button directly on that list, makes it faster to restart many jobs in a row
jobs still failing with the same error 14:27
one of the restarted jobs seems to succeed now
14:41 travis-ci joined
travis-ci MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. 14:41
14:41 travis-ci left
sena_kun Those logs are not cool. 14:42
If those are internal travis issues, if its coverage is done by azure, maybe we can deprecate-disable travis? Azure builds go just fine. 14:46
14:48 travis-ci joined
travis-ci MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. 14:48
14:48 travis-ci left 14:56 Altai-man joined 14:58 sena_kun left 15:43 zakharyas left 15:48 zakharyas joined 16:24 elcaro left 16:31 elcaro joined 16:36 elcaro left 16:37 elcaro joined, domidumont left 16:44 elcaro left, elcaro joined 17:28 pamplemousse__ left, zakharyas left 17:30 elcaro left 17:37 elcaro joined 17:38 chansen_ left, kawaii left 17:39 tbrowder left
Geth MoarVM/hash-single-allocation: 20 commits pushed by (Nicholas Clark)++
17:54 kawaii joined 17:58 tbrowder joined 18:00 chansen_ joined 18:05 pamplemousse__ joined 18:31 pamplemousse__ left 18:56 sena_kun joined
nwc10 oops, try this one 18:56
Geth MoarVM/hash-single-allocation: 17 commits pushed by (Nicholas Clark)++
18:58 Altai-man left 19:06 elcaro left, kawaii left 19:07 kawaii joined 19:23 elcaro joined
nwc10 WTF - I think tha this thing is working first time. 19:26
(OK, one typo before it would compile)
it compiles - ship it!
19:39 zakharyas joined
MasterDuke any difference in benchmarks? 19:39
nwc10 not yet. This thing just has regression tests. 19:41
dogbert17 late night hacking I see 20:15
MasterDuke: do you have time for another stupid question wrt your gmp patch 20:16
MasterDuke sure
dogbert17 ok, this line in your diff: 329 + result = mpz_cmp_si(*b->u.bigint, 0) != 0; 20:17
shouldn't that be: 329 + result = mpz_cmp_si(*b->u.bigint, 0L) != 0;
dunno if it matters but in their demo examples they use 0L 20:18
MasterDuke i don't think it can make a difference for 0 20:23
but i just changed them all and no difference 20:26
20:31 zakharyas left 20:34 Kaiepi left 21:08 sena_kun left
dogbert17 sigh, well it was worth a shot 21:15
MasterDuke hm. you don't even need the exponentiation. if you just use a bigint constant, e.g., 73786976294838206464, you get the same behavior 21:26
m: say +(42 xx 73786976294838206464)
camelia Cannot .elems a lazy list
in block <unit> at <tmp> line 1
MasterDuke i get `0` 21:27
ah ha! 21:41
in MVM_bigint_cmp 21:43
- return r;
+ return r == 0 ? 0 : r < 0 ? -1 : 1; 21:44
rakudo tests pass...on to a spectest 21:45
dogbert17 MasterDuke++ 21:47
21:49 MasterDuke left 21:52 kawaii left, tbrowder left 21:54 chansen_ left 21:55 tbrowder joined 21:56 chansen_ joined 22:00 MasterDuke joined
dogbert17 mpz_cmp* is used in several places, perhaps more changes are necessary 22:03
22:07 kawaii joined
MasterDuke good catch, one other place did need a fix! 22:08
dogbert17 cool 22:10
MasterDuke unfortunately don't think it's going to correct any of the spectest fails
dogbert17 why is that? 22:11
MasterDuke most other uses of mpz_cmp_* were checking for equality, which did work the same as libtommath's 22:12
it's just greater/less than that was different 22:13
and the only use of one of those was in an unlikely branch of bigint_pow
dogbert17 so what kind of failures are you getting? 22:15
MasterDuke a couple are because gmp doesn't return an error code like libtommath does, it just aborts 22:16
m: say 42.expmod(-1,7) # gmp gives `Floating point exception (core dumped)`
camelia Error in mp_exptmod: Value out of range
in block <unit> at <tmp> line 1
MasterDuke m: say so (2⁴⁵⁵³⁵³⁵³⁴⁵³⁶⁴⁵³⁵³⁴⁵) # gmp gives gmp: overflow in mpz type Aborted (core dumped)` and i'm not sure why 22:17
camelia False
MasterDuke m: say 2⁴⁵⁵³⁵³⁵³⁴⁵³⁶⁴⁵³⁵³⁴⁵ 22:18
camelia Numeric overflow
in block <unit> at <tmp> line 1
MasterDuke so we have to figure out to handle those kinds of cases 22:19
some are wrong values when right-shifting, which we had a lot of special handling for and i just got rid of, but maybe some of it needs to come back 22:20
and some are different num representations
m: say 2026887777243374/10**63 22:21
camelia 2.026887777243374e-48
MasterDuke and gmp gives 2.0268877772433737e-48
anyway, i'm off to bed. good progress today 22:22
dogbert17 sleep well 22:23
22:53 MasterDuke left