--- 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