--- Log opened Sat Jul 03 00:00:55 2021 00:05 -!- reallll is now known as belcher 17:21 -!- belcher_ [~belcher@user/belcher] has joined #secp256k1 17:25 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 265 seconds] 18:24 < gmaxwell> real_or_random: so right now github is showing the secp256k1 master fails CI. 18:25 < gmaxwell> real_or_random: https://github.com/bitcoin-core/secp256k1/runs/2978402329 the reason appears to be that the latest merge added a warning which fails the -Werror builds. 18:26 < gmaxwell> How did this happen? 18:27 < gmaxwell> oh there is a PR fixing it. 18:28 < sipa> gmaxwell: PR CI runs on the merge of PR+master at the time of the push, not the latest merge with master 18:29 < gmaxwell> So the issue is that PR wasn't based on the recent tree and so it didn't have the -Werror stuff in it? 18:30 < sipa> right 18:30 < gmaxwell> Makes sense. Another kind of irritating shortcoming of testing only via the CI, -- results in brief windows where the tip of master may never have been tested. 18:39 < gmaxwell> https://github.com/bitcoin-core/secp256k1/pull/963#issuecomment-873497861 I made a suggestion to just build the entire project with a C++ compiler in CI. 18:39 < gmaxwell> It should work fine, other than there might be a few cases where C++ requires an explicit cast. 20:59 < sipa> random thought: bos-coster needs fewer group operations than pippenger (in simulations, around 15% fewer for 1000 points), but they're more expensive due to the higher cost of jacobian operations... what if we'd use a bos-coster that chooses affine where possible, and whenever a sufficiently large % of the heap has been converted into jacobian, perform a bring-all-to-the-same-Z operation (effective affine 20:59 < sipa> rule)? 21:02 < gmaxwell> hm. Is it really the difference between jacobian or not? IIRC the original pippenger implementation we had needlessly used gej operations. Maintaining the heap also has a cost. 21:03 < gmaxwell> I think you'd kinda want to do something like stash the jacobians until the heap gets too small, then bring everything to the same z... (or even batch invert) 21:04 < gmaxwell> nice thing about pippenger though is that if we ever got SIMD group operations it has a lot of parallelism -- it's essentially a constant time algorithim. 21:05 < sipa> yeah, it's hard for me to reason about what the cost of the heap maintenance is 21:06 < sipa> gmaxwell: well there isn't really a need to stash the jacobians; the typical pattern (at the beginning) is that you have one J up front, and a whole bunch of As below it 21:06 < sipa> so you'd do J+A operations to rewrite them 21:06 < sipa> it's only once you hit two Js on top that it becomes more expensive 21:14 < gmaxwell> I guess you could avoid operating on the still affine points by just tracking the new z and converting them 'just in time'. 21:15 < gmaxwell> so you won't waste time reprojecting affine points multiple times without even using them. --- Log closed Sun Jul 04 00:00:56 2021