--- Log opened Sat Jun 19 00:00:42 2021
01:02 -!- belcher_ is now known as belcher
11:32 -!- kittywhiskers [~kittywhis@user/kittywhiskers] has joined #secp256k1
11:50 < kittywhiskers> i've been trying to compile bitcoin core (and therefore secp256k1) using cmake and while making the CMakeList, i needed to manually define ECMULT_GEN_PREC_BITS and ECMULT_WINDOW_SIZE within the CMakeList but when going through configure.ac, it seems to default to the same values regardless of buildenv
11:51 < sipa> if you want to change those you need to pass the relevant options to ./configure
11:51 < kittywhiskers> but i don't see why i would to change them
11:51 < sipa> that's a better question :)
11:52 < kittywhiskers> configure.ac doesn't seem to change them unless manually specified so why not just hardcode them
11:52 < sipa> in short, they're a CPU/memory tradeoff
11:52 < sipa> the way to specify them is too low-level
11:53 < sipa> but larger values result in more memory or a larger binary, at the cost of lower CPU ussge
11:54 < kittywhiskers> i have a tendency to write a lot of text before getting to the actual question, my bad 😅
11:54 < sipa> on an embedded system like a hardware wallet you may not have enough memory
11:55 < sipa> for the default
11:55 < sipa> i think we've thought about instead having the configure interface just expose a low/mid/large setting for memory ussge
11:56 < sipa> instead of actual individual parameter tuning
11:57 < sipa> part of these options will go away too (and be replaced with other tunables) in the multicomb work
11:57 < kittywhiskers> the concept of generating files like libsecp256k1-config.h seem to be very specific to this form of build system, how would you suggest tuning would be incorporated best? 
11:58 < kittywhiskers> right now i'm just cramming a bunch of flags and making a dummy libsecp256k1-config.h to get it to build but that seems less than optimal 
11:59 < sipa> that file is likely going away
11:59 < sipa> it's also optional already
11:59 < sipa> you can not have it, and just pass all its definitions on -D lines to compiler
12:00 < kittywhiskers> that's what i did
12:03 < kittywhiskers> for some reason back then (i last remembered working on this six months ago) it wouldn't build despite everything being defined, it still wanted a dummy file so i just had one made to make it happy
12:06 < sipa> if you don't define HAVE_CONFIG_H, it shouldn't
12:08 < gmaxwell> Does bitcoin core have acceptable performance if the contexts aren't static? (does it avoid reconstructing contexts?)
12:10 < sipa> no, rebuilding the context is slow, even if you already have one
12:11 < sipa> avoiding that would require globals, which means either being thread unsafe, or require synchronization mechanisms (which means logistic overhead)
12:11 < sipa> making all contexts statically precomputed (or at least by default) would simplify things a lot
12:17 < gmaxwell> Well you know my opinion there. :)
12:24 < roconnor> FWIW I use synchronization mechanisms such as call_once, but I'm not trying to be C99 (though I do have a single threaded implemenation of call_once).
17:07 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
17:11 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 268 seconds]
17:33 -!- belcher_ is now known as belcher
18:05 < gmaxwell> Youtube suggested this to me: https://www.youtube.com/watch?v=Nad2V7eUjbs  it's nickler explaining the schnorr security proof.
--- Log closed Sun Jun 20 00:00:43 2021