--- Day changed Tue Mar 20 2018 01:19 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 03:01 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has joined #secp256k1 03:53 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds] 03:56 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 268 seconds] 03:59 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 07:27 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 07:28 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 08:49 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has quit [Ping timeout: 265 seconds] 08:52 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has joined #secp256k1 09:36 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has joined #secp256k1 11:29 -!- droark [~droark@c-24-22-37-84.hsd1.or.comcast.net] has joined #secp256k1 11:30 -!- droark [~droark@c-24-22-37-84.hsd1.or.comcast.net] has quit [Client Quit] 14:21 < andytoshi> i'm having an annoying time trying to add stack frames to the scratch space API 14:21 < andytoshi> if every frame uses the same allocation, then when we run out of memory and have to reallocate, this potentially invalidates pointers that are still live 14:22 < andytoshi> (actually this is always true, but without stack frames our usage patterns are limited to calling _resize exactly once before doing any allocations) 14:22 < andytoshi> OTOH if i allocate a new slab for each frame, the accounting gets ugly 14:25 < sipa> you can turn it into a list of allocated blobs, each larger than the previous 14:25 < sipa> and you only need to deallocate the blobs, not the object in it 14:26 < andytoshi> i don't understand, if i deallocate a blob, anything inside will be invalidated 14:28 < sipa> yes, that's the point? 14:28 < sipa> that's what our scratch space does too 14:29 < sipa> you deallocate the whole scratch space at once, not the objects in it 14:29 < andytoshi> yes 14:29 < andytoshi> i do not intend to change that 14:29 < sipa> that's what i'm saying :) 14:29 < sipa> but it doesn't have to be a single allocated scratch space 14:29 < sipa> it could be a list of scratch blobs 14:29 < andytoshi> ah, i gotcha 14:30 < sipa> and when one is full, you create a new one, but the old one isn't invalidated 14:30 < andytoshi> right 14:30 < andytoshi> that's potentially quite wasteful .. but maybe it won't be with our patterns 14:31 < andytoshi> oh, yeah, derp, every one of my frames knows exactly how much memory it needs before it does any allocations 14:31 < andytoshi> ok thanks 14:31 < sipa> the overhead of an allocation is 16-31 bytes 14:31 < sipa> on 64-bit linux 14:32 < andytoshi> it's not space i care about, but cache locality 14:33 < andytoshi> but this is probably also not an issue, i'll have 2 or 3 blobs at most 14:44 < gmaxwell> there is also a question of how much code needs out of memory error handling. 14:47 < andytoshi> yeah, it's nice right now that we can call `scratch_space_resize` and if it passes, an actual allocation is guaranteed to succeed because the memory is already there.. 14:48 < andytoshi> oh, actually let me check what the ecmult code does 14:49 < andytoshi> everything else tries to call `resize` and fails if it can't resize, so it already has to deal with OOM. the ecmult code is weird in that it first asks "how much memory can I get?" and then tries to allocate the maximum.. 14:50 < andytoshi> ah, ok, it also tries to call `resize`, after deciding how much memory it thinks it can get, then fails if this fails 14:50 < andytoshi> so i think every current usage of the scratch space already has OOM paths 14:53 < andytoshi> so i'm going to replace `secp256k1_scratch_resize` with a function `secp256k1_scratch_allocate_frame` and corresponding `secp256k1_scratch_deallocate_frame` 14:53 < andytoshi> and drop `secp256k1_scratch_reset` 14:54 < andytoshi> then `secp256k1_scratch_alloc` will work as before, it will return a pointer into the most-recently-allocated frame 16:03 < andytoshi> nice, this works very well. i'd expected the extra allocations to kill my performance but i guess even several of them don't matter against a multi-millisecond crypto operation 17:00 -!- weez17 [~isaac@unaffiliated/weez17] has quit [Remote host closed the connection] 17:00 -!- weez17 [~isaac@unaffiliated/weez17] has joined #secp256k1