github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:13 pamplemousse_ left 00:22 leont left 01:55 vrurg_ joined 01:58 vrurg left 06:05 hoelzro left, bisectable6 left, tellable6 left, sourceable6 left, statisfiable6 left, committable6 left, quotable6 left, evalable6 left, nativecallable6 left, linkable6 left, notable6 left, benchable6 left, Altreus left 06:10 hoelzro joined, bisectable6 joined, tellable6 joined, sourceable6 joined, statisfiable6 joined, committable6 joined, quotable6 joined, evalable6 joined, nativecallable6 joined, linkable6 joined, notable6 joined, benchable6 joined, Altreus joined 06:49 sena_kun joined 06:52 Kaiepi left 06:53 Kaiepi joined
nwc10 good *, #moarvm 07:33
(oops, I should have done that some time ago)
07:37 zakharyas joined
nine nwc10: I'm still drinking my morning coffee, so you're well in time ;) 07:37
nwc10 I'm digesting mine. I'm ahead
I blame Schwechat Gymnasium 07:38
actually, I think that should be "Gymnasium Schwechat"
07:39 zakharyas1 joined 07:41 zakharyas left 07:43 domidumont joined 07:46 zakharyas joined 07:48 zakharyas1 left 08:01 zakharyas left 08:19 leont joined 08:21 zakharyas joined 08:48 domidumont left 09:36 domidumont joined 09:41 Altai-man joined 09:43 sena_kun left
MasterDuke hm. so a gmp bigint uses fewer bits to store the same number than a tommath bigint 10:06
i.e., mpz_size(a) != a->used 10:07
which is why i'm having trouble with MVM_bigint_div_num (because of MVM_mp_get_double_shift) 10:08
err, gmp uses fewer 'limbs' than tommath uses 'digits' 10:10
10:54 zakharyas left
timotimo so the individual limbs are bigger? 10:58
12:27 zakharyas joined
MasterDuke i guess so. but i haven't figured out how to adjust the algorithm 12:35
timotimo create a bigint 0xffffffffffffffffffffffffffffffff and see how each limb looks, count the bits of the individual values, and that would be your shift value? 12:54
in libtommath there's a jungle of preprocessor defines that change how big individual pieces are, so they have a function for that 12:55
that's my assumption anyway
13:42 sena_kun joined 13:44 Altai-man left
MasterDuke hm. for gmp, two limbs, each is FFFFFFFFFFFFFFFF 13:47
13:51 vrurg_ is now known as vrurg
MasterDuke for tommath, three digits, one is FF, other two are FFFFFFFFFFFFFFF 13:58
timotimo m: say 0xFFFFFFFFFFFFFFFF.base(2).chars 14:02
camelia 64
timotimo m: say 0xFFFFFFFFFFFFFFF.base(2).chars
camelia 60
timotimo hum? 64 + 64 isn't the same as 2 + 2 * 60 14:03
MasterDuke m: say 0xFF.base(2).chars 14:17
camelia 8
MasterDuke 2*4 + 2*60 14:18
ok, making MVM_mp_get_double_multiplier = 2**64 - 1 works... 14:29
timotimo m) m) 14:30
i'm dumb 14:31
MasterDuke not one to talk, given how long it's taking me to get this working...
heh. now only a single failed test in a spectest 14:38
lizmat hopes that's not some kind of numerical accuracy test
MasterDuke well, there's this: not ok 1 - '2**10000000000' died 14:39
timotimo hahaha 14:40
MasterDuke it doesn't die cause gmp can do that number
timotimo so it just succeeds rather than dying
MasterDuke but then there's an abort. `gmp: overflow in mpz typeAborted (core dumped)`
a later test where it is too big
so need to figure out how to handle those
timotimo right
lizmat MasterDuke++ # progress!! 14:41
timotimo i wish i had figured this tip out a week ago 14:42
MasterDuke eh. i also could have tried actually figuring things out earlier instead of just blindly changing numbers and hoping for the best 14:43
i'll also blame this flu which i'm just on the tail end of now 14:44
and canada
timotimo oof 14:45
MasterDuke "There’s currently no defined way for the allocation functions to recover from an error such as out of memory, they must terminate program execution. A longjmp or throwing a C++ exception will have undefined results. This may change in the future. " 14:47
according to a SO answer: "The best way to handle these errors gracefully in your application is probably to fork off a helper process to perform the GMP calculations. If the helper process is killed by SIGABRT, your parent process can detect that and report an error to the user." 14:50
gmplib.org/repo/gmp/file/default/m...lloc.c#l57 14:52
timotimo ... ... ... :\ 15:00
15:01 codesections left
MasterDuke we could patch it to do something else, but then we can't have a --has-gmp flag 15:01
any other suggestions?
lizmat make sure nqp::power_I doesn't accept values over x ? 15:06
MasterDuke well, i assume other things could throw also. multiplying/adding two numbers just under the limit 15:07
timotimo we can't give gmp "our own" allocation functions, i assume? 15:09
hm, even then, i don't think there's a way to allocate a black-hole memory mapping
my first idea was to maybe just return a blob of the right size that doesn't use up any actual memory 15:10
MasterDuke well, we could. but that first quote seems to suggest we couldn't do an MVM_exception_throw_adhoc?
timotimo so that gmp can just write to it and silently fail when it just gets zeroes back
right, we wouldn't be able to do that
15:59 lizmat left 16:10 lizmat joined
nwc10 It's far more fun building without ASAN and all the debugging, when you've got use to how slow things are with them. 16:51
MasterDuke the custom alloc function has to have the signature `void * allocate_function (size_t alloc_size)`, so not even sure we could get a tc in there 16:55
nwc10 thread local storage! 16:56
except, since then there are __thread variables
MasterDuke nine, brrt: do you have suggestions for how to handle gmp abort()ing in its (re)alloc functions? 16:57
nwc10: is that a serious suggestion? 16:58
nwc10 yes. sadly it is
and we should already be usign them
there's a bad-and-wrong use of `static` somewhere in the serialisation code, that should be TLS or __thread 16:59
needs to sneak a tc into qsort
MasterDuke hm. but the gmp docs say "A longjmp or throwing a C++ exception will have undefined results." which seems like throwing would be bad even if we could figure out how 17:00
nwc10 agree
timotimo ah dang. it's usually designed such that you get to pass "user data" along with the function pointer 17:08
though that'd also mean you're only getting a single value for all threads, likely
MasterDuke anybody want to find what julia does? 17:15
github.com/JuliaLang/julia/blob/b9...l#L86-L125 17:16
17:24 domidumont left 17:41 zakharyas left, Altai-man joined 17:44 sena_kun left 19:25 Kaiepi left, Kaeipi joined 19:43 Kaeipi left 19:49 Kaiepi joined
MasterDuke well, a bunch of googling and skimming mailing lists suggests that while throwing an exception from gmp is (probably) not supported, it's actually very unlikely to cause a problem 20:12
so maybe i try it and see what happens?
but i know nothing of thread local storage and/or __thread variables. and quick pointers on how i would use them to create an alloc function that could MVM_exception_throw_adhoc? 20:13
nwc10 er, no idea on quick 20:14
to copy-paste from the work code, I have: 20:15
static __thread int worker_loop_val = 0;
and I don't know if that `= 0` is a tautology - I don't know offhand if they always start as 0
but this variable, as shown, is scoped at file level, and starts out with value 0 *in each thread* 20:16
oh, actually, you'd want this one:
static __thread void *worker_copied_hashes = NULL;
so starts out as NULL in each thread
and assuming a 1:1 mapping from threads to `tc`, I guess that you just assign `tc` to it if you find it to be NULL *before* you call into GMP 20:17
and in the callback function, you reference it an assume that it wasn't NULL
MasterDuke cool, thanks
nwc10 and I need to go to bed soon because the evil alarm clock will be going "good *" to me soon enough 20:18
21:11 Altai-man left 21:27 Kaiepi left, Kaiepi joined 21:28 Kaiepi left 21:29 Kaiepi joined 21:36 Kaiepi left 21:37 Kaeipi joined 22:13 Kaeipi left, Kaeipi 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!