--- Log opened Fri May 28 00:00:21 2021
02:35 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has joined #secp256k1
02:44 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has quit [Quit: I am away from my computer]
02:47 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has joined #secp256k1
03:25 -!- fjahr [sid374480@id-374480.highgate.irccloud.com] has joined #secp256k1
04:05 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has left #secp256k1 []
04:27 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined #secp256k1
04:28 < real_or_random> I know this is the most boring PR ever but it would be great to get some review https://github.com/bitcoin-core/secp256k1/pull/944
04:28 < real_or_random> Happy to review other PRs in return :)
04:47 < roconnor> does anyone (else) know automake?
04:51 < sipa> one does not "know" automake
04:52 < sipa> to modify it you just fuzz it until it does what you wanr
06:06 < real_or_random> that's a good explanation. even though I went as deep as reading the libtool source code... ^^ if you're not comfortable with reviewing automake changes, it will also be helpful to feedback on the effects, i.e., the additionally enabled warnings and -Werror on CI
07:02 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has quit [Quit: Textual IRC Client: www.textualapp.com]
07:15 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has joined #secp256k1
07:20 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has quit [Client Quit]
07:34 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has joined #secp256k1
07:49 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:00 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has joined #secp256k1
08:10 < roconnor> so what does gcc -O2 -O0 do?
08:56 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:08 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has joined #secp256k1
09:27 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:5db2:a238:1b75:5efc] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:33 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:8d3c:d04e:3e8a:5e2d] has joined #secp256k1
10:11 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:8d3c:d04e:3e8a:5e2d] has quit [Quit: Textual IRC Client: www.textualapp.com]
10:13 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:8d3c:d04e:3e8a:5e2d] has joined #secp256k1
11:30 -!- michaelfolkson [~michael@2a00:23c7:60c5:ad01:8d3c:d04e:3e8a:5e2d] has quit [Quit: Textual IRC Client: www.textualapp.com]
11:37 < real_or_random> nickler:  https://github.com/bitcoin-core/secp256k1/pull/844#issuecomment-850569650 now it would be interesting to know why valgrind does not detect this
11:38 < sipa> roconnor: -O0 takes precedence
11:39 < real_or_random> or was this simply a single allocation that the OS will clean up on exit?
12:22 < roconnor> real_or_random: Funciton is called SECP_TRY_APPEND_CFLAGS but
12:23 < roconnor> CFLAGS="$1 $CFLAGS"
12:29 < roconnor> oh AM_CFLAGS claims to be prepended
12:39 -!- jonatack [~jon@user/jonatack] has quit [Ping timeout: 265 seconds]
12:46 -!- sipa [~pw@user/sipa] has quit [Quit: leaving]
13:16 < roconnor> Oh and it does do    $2="$$2 $1"
13:16 < roconnor> ... I'll accept APPEND.
13:38 < nickler> nice, roconnor, changing the range of the randomizers is yet another speedup https://gist.github.com/jonasnick/ad5f45c54c0a51dfc2c7decc104a2f10
13:38 < nickler> except for verify_2 O.o
13:42 < roconnor> hmm.  Is 2 still using batch verify?
13:42 < roconnor> or is it running single verify twice?
13:45 < roconnor> Are you planning to try klo + khi * lambda for 64 bit numbers of klo and khi, or do you want me to look into whether I think it will help or not?
13:46 < nickler> if it were runing single verify twice, then verify_2 should be == verify_1 (which it isn't)
13:47 < nickler> didn't plan to do that immediately, but it would be important for the ecmult interface redesign I suppose
13:48 < nickler> also the pippenger windows/threshold may not be optimal for this randomizer optimization
13:48 < roconnor> Right. I'm not so sure about this split 64 bit idea.
13:49 < roconnor> But maybe it is worth trying rather than guessing if it would be better or not.
13:51 < nickler> at least the experimental approach revealed that your optimization works with pippenger too, without having to guess anything :)
13:52 < roconnor> I was moderately confident about that.
13:52 < nickler> but yeah we may end up with an ecmult_multi that's special for schnorr batch verification
14:05 -!- sipa [~pw@user/sipa] has joined #secp256k1
14:26 -!- belcher_ is now known as belcher
14:43 < real_or_random> yep it appends to the second argument
14:43 < real_or_random> thanks for having a look
14:47 < real_or_random> nickler: I don't think any code specifically exploits that klo or khi is 0. We should just add a branch.
14:47 < real_or_random> I can imagine that yields larger speed ups
14:51 < real_or_random> oh maybe it does exploit it https://github.com/bitcoin-core/secp256k1/blob/1e5d50fa93d71d751b95eec6a80f6732879a0071/src/ecmult_impl.h#L541 at least we check i against the number of bits in the k's  
14:53 < sipa> the table only contains odd multiples of P, so zeroes will obviously make it skip
14:53 < real_or_random> sure 
14:54 < sipa> but i don't think there is any speedup beyond that really
14:54 < real_or_random> yeah I guess you're right
14:54 < sipa> just a term that scales with the number of nonzero limbs in wnaf representation, which happens to be zero if the scalar is zero
14:55 < real_or_random> we'd save 129*#points checks but the checks are just a single instruction.
14:55 < sipa> right
14:55 < real_or_random> but it's cheap to try it, maybe it makes the compiler do some other magic 
14:56 < real_or_random> (I haven't looked at the asm)
14:56 < sipa> i guess we could sort the point,scalar tuples by order of decreasing "length", and then have the loop length shrink as the position increases
14:56 < sipa> but i doubt this will do much
14:57 < sipa> oh, where length is actually defined as the lowest nonzero limb, not the highest
14:59 < sipa> just zero we can probably just skip entirely by removing it from the list?
14:59 < real_or_random> I don't understand
15:00 < real_or_random> but here's another thing: we could save one table and this entire loop? https://github.com/bitcoin-core/secp256k1/blob/1e5d50fa93d71d751b95eec6a80f6732879a0071/src/ecmult_impl.h#L510
15:01 < sipa> don't worry about it
15:03 < sipa> right, that could be avoided
15:16 < roconnor> real_or_random: your links are to strauss but for large batches pippenger is used.
15:16 < real_or_random> ok... true
15:17 < real_or_random> we'll just need smaller blocks
15:18 < roconnor> https://github.com/bitcoin-core/secp256k1/blob/1e5d50fa93d71d751b95eec6a80f6732879a0071/src/ecmult_impl.h#L723 is where pippenger checks for 0 scalars.
15:18 < roconnor> fairly sure this is after the endomorphism split.
15:22 < roconnor> And https://github.com/bitcoin-core/secp256k1/blob/1e5d50fa93d71d751b95eec6a80f6732879a0071/src/ecmult_impl.h#L757-L765 is a bunch of code that is skipped when a wnaf value is 0.
15:22 < roconnor> which will happen a moderate amount if the endomorphism yeilds coefficents whose values are half 0s.
15:23 < roconnor> (on the other hand we lose the dropped point, it is maybe a wash (or worse)).
15:35 < real_or_random> we could save this here https://github.com/bitcoin-core/secp256k1/blob/1e5d50fa93d71d751b95eec6a80f6732879a0071/src/ecmult_impl.h#L847
15:42 < roconnor> true, but that is a field cube operation.
15:42 < roconnor> so 1 squre and one mult.
15:42 < roconnor> It might show up...
15:56 -!- sipa [~pw@user/sipa] has quit [Quit: Lost terminal]
16:05 -!- sipa [~pw@user/sipa] has joined #secp256k1
17:20 < real_or_random> probably not
17:29 < real_or_random> we could at least save space in the pippenger state
17:30 < real_or_random> that's always a good idea for batch verification. 
17:32 < real_or_random> we could get rid of half of the scalars (and if we're really greedy, we could always get rid of half of the bits of every scalar...)
18:06 < roconnor> I think I removed a negation once and got it to barely show up.
18:07 < roconnor> BTW if you want to get rid of strauss state, I have a PR for that.
18:07 < roconnor> Also if this were only written in Haskell, those unused mul_lambda would never get evaluted so ... um ... I guess Haskell is faster?
18:09 < real_or_random> yep I know, it's on my list ...
18:11 < real_or_random> reminds me of https://xkcd.com/1312/
18:13 < sipa> 't is true
18:25 < roconnor> I certainly never run it: http://r6.ca/blog/20120708T122219Z.html
18:25 < real_or_random> :)
18:28 < sipa> if all your logic is in the type system/compile time stuff, who cares?
18:29 < sipa> real_or_random: what timezone are operating in?
18:45 < nickler> oh I think I know now why verify_2 isn't better with the range optimization. It's a bug. The verify benchmark verifies the same sigs in every iter, so khi was always already 0, not only 50% of the time.
18:45 < nickler> xmonad every day all day
18:48 < sipa> /o\
19:11 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1
19:14 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 264 seconds]
--- Log closed Sat May 29 00:00:22 2021