|
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 | ||
|
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. |
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. |
|||
|
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. |
13:56 | |
|
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 | |
| travis-ci.org/MoarVM/MoarVM/builds/731288125 github.com/MoarVM/MoarVM/compare/f...070970c4a7 | |||
|
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 | |
| travis-ci.org/MoarVM/MoarVM/builds/731288125 github.com/MoarVM/MoarVM/compare/f...070970c4a7 | |||
|
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 | |
| travis-ci.org/MoarVM/MoarVM/builds/731288125 github.com/MoarVM/MoarVM/compare/f...070970c4a7 | |||
|
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)++ review: github.com/MoarVM/MoarVM/compare/c...f3353ace9f |
17:41 | |
|
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)++ review: github.com/MoarVM/MoarVM/compare/7...978ba231a9 |
18:57 | |
|
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
|
|||