--- Log opened Mon Nov 20 00:00:31 2023
00:43 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
01:25 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:26 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
01:46 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
02:20 -!- lbia [~lbia@user/lbia] has joined #secp256k1
02:32 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
02:46 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
04:08 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
04:09 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
05:13 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
05:14 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
05:14 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
05:37 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
05:38 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
05:39 -!- jonatack [~jonatack@user/jonatack] has joined #secp256k1
07:00 < real_or_random> meeting
07:00 < sipa> hi
07:01 < real_or_random> I know jonas won't join today
07:02 < real_or_random> but we could nevertheless talk about the next release
07:02 < real_or_random> and any other topics people have
07:02 < sipa> when is the intended release date?
07:03 < real_or_random> github says dec 1st https://github.com/bitcoin-core/secp256k1/milestone/5 .
07:03 < sipa> oh, close
07:03 < real_or_random> "We aim to cut a regular release every 3-4 months, approximately twice as frequent as major Bitcoin Core releases. Every second release should be published one month before the feature freeze of the next major Bitcoin Core release, allowing sufficient time to update the library in Core."
07:04 < sipa> i don't think 1198 will make it, as i think we agreed it should be changed substantially (so its hash function is given the full input pubkeys etc)
07:05 < hebasto> hi
07:05 < real_or_random> so we're a bit more flexible this time because this release won't be tight to the bitcoin core release
07:06 < real_or_random> sipa: right, and on top of this: I think we had first added it because it's easy to review, but then we were not sure if it's in scope
07:06 < real_or_random> when we discussed this in person
07:06 < sipa> right
07:07 < real_or_random> and by the last the last release was Sep 4... So Dec 1 would be 3 months
07:08 < hebasto> speaking of upcoming release, are we interested in https://github.com/bitcoin-core/secp256k1/pull/1380?
07:08 < real_or_random> okay I've removed 1198 from the milestone
07:09 < real_or_random> 997 (scope) will be solved (for now) by https://github.com/bitcoin-core/secp256k1/pull/1431 ... it doesn't matter a lot for a release but having a deadline for this will be good, I guess 
07:09 < real_or_random> we procrastinated too long on this
07:09 < sipa> yeah
07:11 < real_or_random> hebasto: I think we'll need to make up our minds on this. if you ask me, I don't mind adding it to the milestone, for exactly this reason. If we want it, it's probably pretty close to being ready to be merged 
07:12 < hebasto> my point is, that we actually do those checks manually a few recent releases
07:13 < real_or_random> yes, you have my Concept ACK (let me actually note that in the issue)
07:14 < real_or_random> we just haven't heard from others so far
07:14 < hebasto> right
07:16 < real_or_random> for https://github.com/bitcoin-core/secp256k1/issues/1095  ( Don't #include standard library headers unconditionally )... if we retarget to around dec 8 or dec 15, I'd like to keep this on the list. i really want to work on this, and a deadline would help me too. we can still see if  a PR is ready enough by then 
07:17 < real_or_random> if noone objects
07:17 < sipa> sounds good to me
07:18 < real_or_random> anything else? 
07:19 < real_or_random> I'd love to see progress on https://github.com/bitcoin-core/secp256k1/issues/726 (Consider removing x86_64 field assembly)
07:20 < real_or_random> it's probably the lowest hanging performance fruit right now ^^ but not sure if we should add it to the list
07:20 < real_or_random> cc theStack , are you still planning to run some benchmarks?
07:23 < real_or_random> hm, my thinking is that we should make progress here, but it's probably worth waiting how https://github.com/bitcoin/bitcoin/pull/27897 evolves. if it looks like this will make it for 27.0 release, then we could retarget our issue to the release that happens before the 27.0 feature freeze  
07:23 < real_or_random> and this gives us a clear decision process: if gcc 12.3.0 is faster, then we disable asm
07:24 < sipa> i think i was hesitant before in #726 to remove the asm, as for clang back then the asm version was still faster
07:24 < sipa> but it appears that that may not be the case anymor either
07:25 < sipa> if so, it's probably a no-brainer - unless we consider the alternative of taking some compiler output and just turning it into asm instead
07:26 < sipa> (because if so, it's probably a smaller code change than actually deleting the asm and support for it)
07:27 < real_or_random> as a first step, I'd just change the default. that's a one-line diff and achieves most of what we'll need
07:28 < sipa> do you mean disabling scalar asm too?
07:28 < sipa> because iirc that is still faster than the native C version even on modern compilers (but also, much less impactful
07:28 < sipa> )
07:28 < real_or_random> oh, right, the setting controls both
07:29 < real_or_random> hmmm. okay then this needs more investigation
07:30 < real_or_random> do you have recent benchmarks? i could imagine that the picture has changed even for the scalar code now 
07:30 < sipa> i doubt it - the scalar code really relies on add-with-carry instructions
07:31 < sipa> which iirc compilers are not yet good at just inferring
07:31 < sipa> but no i don't have recent benchmarks
07:31 < real_or_random> ok I see. though clang got better at this, and gcc 14 will hopefully make some progress here. the internal compiler error we saw on a gcc-14 snapshot was due to ADC stuff 
07:32 < real_or_random> but that's still unreleased
07:32 < sipa> ah
07:33 < real_or_random> (they have improved __builtins but also some pattern matching on native C addition chains 
07:33 < sipa> interesting
07:34 < real_or_random> this is the PR https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=43a3252c42af12
07:35 < real_or_random> anyway, i'll add a short summary of this discussion in the issue...
07:36 < sipa> cool
07:37 < real_or_random> other topics/suggestions for the release?
07:38 < real_or_random> ah what to do with the date then? should we add one or two weeks to the target date?
07:38 < sipa> let's add two weeks
07:39 < real_or_random> sounds good to me
07:39 < sipa> there is no real strict reason to keep it at dec 1st
07:39 < sipa> i'll also be on vacation for the rest of the week
07:40 < real_or_random> yes, agreed. it was anyway the lower end of our target window 
07:40 < real_or_random> ok
07:40 < sipa> right
07:41 < real_or_random> (what GCC is currently used in the official core builds?)
07:41 < real_or_random> hebasto
07:44 < real_or_random> seems to be gcc 10, i just don't know which exact one
07:44 < real_or_random> anyway. more topics? end of meeting?
07:45 < real_or_random> then end of meeting
07:47 < sipa> ok
07:49 < real_or_random> ah one last question: you posted nice benchmarks in 2020... with a nice script like for C in "gcc-4.7 gcc-4.9 gcc-5 gcc-6 gcc-7 gcc-8 gcc-9 gcc-10 clang-3.7 clang-3.8 clang-4.0 clang-6.0 clang-7 clang-8 clang-9 clang-10" ...
07:49 < hebasto> real_or_random: GCC 10.5.0
07:49 < real_or_random> how did you create this environment?
07:49 < real_or_random> thanks!
07:52 < sipa> real_or_random: i just apt installed all those compilers
07:52 < sipa> which were in the ububtu repository at tbe time
07:52 < real_or_random> ah okay, arch linux is not so nice here 
07:52 < sipa> maybe i had added some gcc backports repo/snap too
07:56 < real_or_random> (I can hear the gentoo guy in background: no worries, just build a few toolchains. it'll be quick, just give me a few days.)
07:58 < sipa> ha
08:08 < roconnor> nixos
08:14 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
08:29 < real_or_random> yep, sounds like a great tool for this problem
09:18 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
09:47 < theStack> real_or_random: yes, will run benchmarks for issue #726 in a bit. wanted to do that right after coredev, but apparently i forgot :|
09:49 < real_or_random> nice, thanks
10:20 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
11:54 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
11:57 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
12:30 -!- jon_atack [~jonatack@user/jonatack] has joined #secp256k1
12:30 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
14:00 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
15:31 < roconnor> apparently in my personal repo of libsecp I have patched secp256k1_mul128 to return uint64_t instead of int64_t.
15:34 < roconnor> I'm not sure if that is something we want officially or not
18:09 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.1.1]
21:53 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
22:04 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
22:25 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
--- Log closed Tue Nov 21 00:00:32 2023