--- Log opened Wed Jun 23 00:00:46 2021
00:26 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #secp256k1
00:59 -!- belcher_ is now known as belcher
09:30 < roconnor> I've generated static arrays for ecmult pre_g and pre_g_128 tables. The source file is 3MB.  gcc seems to have absolutely no problem with it.
09:33 < roconnor> 1.2M when the file is bzipped.
10:14 -!- nsh [~lol@5.135.157.17] has quit [Changing host]
10:14 -!- nsh [~lol@user/nsh] has joined #secp256k1
13:29 < elichai2> roconnor: 3MB with no spaces/newlines? 
13:37 < roconnor> $ wc C/secp256k1/ecmult_pre_g.h 
13:37 < roconnor>   16397   16423 3143902 C/secp256k1/ecmult_pre_g.h
13:54 < roconnor> Github seems to have a file size limit of 100MB.
13:55 < roconnor> There is some indication that the limit used to be 25MB.
15:09 < roconnor> real_or_random: sipa: if we did generate different tables of different size based on configuration parameters, the next question would be what code would we use to generate the table?  Python? (Haskell?) Maybe C?     
15:10 < roconnor> There are issues regarding cross-compiling that I don't have any experience with.
15:11 < gmaxwell> There is already code to generate the signing tables, it would basically be a few lines moved around to make it also generate other tables.
15:12 < roconnor> oh right, gen_context.c
15:12 < roconnor> I guess that has the same whatever cross-compiling issues that there might be.
15:13 < gmaxwell> If the tables are checked in, cross-compiling concerns go away-- the gen tool becomes some not compiled by default development too.
15:13 < gmaxwell> tool*
15:14 < roconnor> depends on the configuration of the table size changes.
15:14 < sipa> it may still be desirable to have it as part of the build system, in case a non-default configuration is selected
15:14 < sipa> though i guess the one we'd check at least would be pretty much the largest reasonable size we want
15:14 < sipa> so if that's ok to check in, it's not really a concern a check in a smaller one too
15:14 < roconnor>     fprintf(fp, "#if ECMULT_GEN_PREC_N != %d || ECMULT_GEN_PREC_G != %d\n", ECMULT_GEN_PREC_N, ECMULT_GEN_PREC_G);
15:14 < roconnor>     fprintf(fp, "   #error configuration mismatch, invalid ECMULT_GEN_PREC_N, ECMULT_GEN_PREC_G. Try deleting ecmult_static_context.h before the build.\n");
15:15 < gmaxwell> True, though it's a pretty high cost to keep that... While it would be cheap to just check in a couple options, and a couple options is all that are going to get testing in any case.
15:15 < gmaxwell> sipa: Also, as my prior PR showed, you can just make the larger one also generate the smaller ones through truncation.
15:15 < roconnor> with some ifdefs we could trim down the size of the table based on the config parameters.
15:15 < gmaxwell> yes, I already did that..
15:15 < roconnor> did that where?
15:16 < gmaxwell> https://github.com/bitcoin-core/secp256k1/pull/614
15:21 < sipa> gmaxwell: do you think there is a use in keeping the ability to have them generated at runtime?
15:21 < sipa> it'd be useful on systems where binary size matters, but RAM doesn't... i doubt those exist
15:22 < sipa> well, at least among potential users of the library
15:22 < gmaxwell> I think if the size matters that much you can just use a really small table.
15:22 < sipa> right
15:22 < sipa> we do want to keep the ability to configure a small table at compile time
15:22 < gmaxwell> So you'd need performance matters a lot, ram is free, code size is not free.. and you're going to do a lot of operations with a single context.
15:22 < roconnor> I think we can keep the ability to configure small tables at compile time with very little effort.
15:23 < sipa> agree
15:23 < roconnor> And it will be no less testable than it alread isn't. :)
15:23 < gmaxwell> Simplifying the code is good, and simplifying the configurations to test is better.  I don't really like having supported configs that won't get adequate testing because they're kinda useless.
15:24 < gmaxwell> we've been essentially unable to get any feedback about what size tradeoffs users are interested in, which makes it harder to reduce the supported configs to a reasonable set (which all get adequate testing).  Doubly sucks because the embedded users are probably never even running the tests.
15:27 < roconnor> In case someone else want to work on this, I'm not certain I'll have the time to put together the PR.  The work involves cargo-culting the gen_context.c to generate secp256k1_g_pre and secp256k1_g_pre128 tables; including a few ifdefs to make variable array sizes along the lines of gmaxwell's #614; I also moved some of the WINDOW_G ifdef stuff from ecmult_impl.h to ecmult.h so I could import them into this generated pre_g_impl.h file; 
15:27 < roconnor> then you can delete all secp256k1_ecmult_context and any uses of it.
15:28 < roconnor> I don't know.  Maybe I should do this after all.
15:31 < roconnor> Okay, I'll give it a try tomorrow and see how it goes.
15:32 < sipa> roconnor: perhaps some of the code in https://github.com/bitcoin-core/secp256k1/pull/919/files is useful
15:32 < roconnor> correction, I'll try on friday.
17:08 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
17:11 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
--- Log closed Thu Jun 24 00:00:47 2021