github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:33
(oops, I should have done that some time ago)
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"
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
timotimo so the individual limbs are bigger? 10:58
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
MasterDuke hm. for gmp, two limbs, each is FFFFFFFFFFFFFFFF 13:47
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
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!