github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
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
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
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.
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
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.		 11:47
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.
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.		 13:56
travis-ci MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. 14:15
travis-ci.org/MoarVM/MoarVM/builds/731288125 github.com/MoarVM/MoarVM/compare/f...070970c4a7
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
travis-ci MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. 14:41
travis-ci.org/MoarVM/MoarVM/builds/731288125 github.com/MoarVM/MoarVM/compare/f...070970c4a7
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
travis-ci MoarVM build errored. Nicholas Clark 'oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. 14:48
travis-ci.org/MoarVM/MoarVM/builds/731288125 github.com/MoarVM/MoarVM/compare/f...070970c4a7
Geth MoarVM/hash-single-allocation: 20 commits pushed by (Nicholas Clark)++
review: github.com/MoarVM/MoarVM/compare/c...f3353ace9f		 17:41
nwc10 oops, try this one 18:56
Geth MoarVM/hash-single-allocation: 17 commits pushed by (Nicholas Clark)++
review: github.com/MoarVM/MoarVM/compare/7...978ba231a9		 18:57
nwc10 WTF - I think tha this thing is working first time. 19:26
(OK, one typo before it would compile)
it compiles - ship it!
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
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
dogbert17 mpz_cmp* is used in several places, perhaps more changes are necessary 22:03
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!