--- Log opened Fri Jul 02 00:00:54 2021
00:25 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #secp256k1
00:48 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Quit: Client limit exceeded: 20000]
00:58 < real_or_random> sipa nickler_: what's the status of this PR? not sure if I understand the discussion https://github.com/bitcoin-core/secp256k1/pull/920
01:00 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #secp256k1
01:22 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Quit: Client limit exceeded: 20000]
01:33 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #secp256k1
01:40 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Remote host closed the connection]
02:06 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #secp256k1
02:19 -!- jesseposner [~jesse@2601:647:0:89:1597:3bb6:d9c9:249b] has quit [Ping timeout: 256 seconds]
02:20 -!- jesseposner [~jesse@2601:647:0:89:616b:5a1b:543d:92b] has joined #secp256k1
02:28 < nickler_> my understanding is that sipa intends to update the tests (or I'm missing a joke in response to my joke attempt)
05:12 -!- roconnor [~roconnor@host-45-78-208-216.dyn.295.ca] has joined #secp256k1
07:59 < roconnor> https://github.com/bitcoin-core/secp256k1/pull/956 is out of the draft stage.
12:59 < sipa> benchmarking on Zen+... it seems --with-ecmult-window=18 is fastest...
13:00 < roconnor> is that true both before and after this PR?
13:01 < sipa> i'm testing master
13:02 < sipa> actually, this may be noise
13:07 < sipa> 12 MiB binaries do seem a bit excessive, though
13:08 < sipa> 8 MiB, sorry
13:08 < sipa> this isn't emacs
13:15 < sipa> also, microbenchmark bias; real-life usage isn't just doing signature validations, and mixing other code generally worsens cache effects
13:16 < sipa> so in practice performance may be relatively worse for large table sizes
13:46 < sipa> on cortex-A73 (Odroid N2+), the optimal table size seems to be 22...
13:46 < sipa> 196 us at 15, 189 us at 22
13:46 < sipa> for an ecdsa verify
13:50 < sipa> that's a 128 MiB table :s
14:37 < roconnor> what's your margin of error?
14:38 < sipa> on this system there is no noise that i can notice
14:38 < sipa> the numbers for minimum/average/maximum are always the same
14:40 < gmaxwell> You ought to scan the dynamic table size at the same time. :P
14:40 < gmaxwell> since the optimal static table size might depend on the dynamic table. :P
14:40 < sipa> dynamic table?
14:41 < gmaxwell> WINDOW_A
14:41 < sipa> ecdsa verification accesses both
14:41 < sipa> oh
14:41 < gmaxwell> That would be my point, yes.
14:41 < sipa> i think i'm misinterpreting what you mean by scanning
14:41 < gmaxwell> also, 128MB table is not that attractive for just a 3% speedup particularly since in a non-microbenchmark...
14:42 -!- FelixWeis [sid154231@id-154231.stonehaven.irccloud.com] has quit [Read error: Connection reset by peer]
14:42 -!- elichai2 [sid212594@id-212594.stonehaven.irccloud.com] has quit [Read error: Connection reset by peer]
14:42 < sipa> of course, and it's unlikely to be beneficial in a production setting
14:42 < gmaxwell> sipa: I mean you shouldn't just be searching for the optimal WINDOW_G but the optimal WINDOW_A,WINDOW_G which may be different.
14:43 < sipa> gmaxwell: you mean just do to memory accesses to both competing for cache space?
14:43 < gmaxwell> well also because the time spent on precomp thats justified also depends on how long the operation overall takes.
14:44 < sipa> i don't think so (ignoring cache competition effects)
14:45 < sipa> the amount of time spent precomputing the A table is just a function of the time to access and entry in it and how many of those accesses there are
14:45 < sipa> and the number of accesses is independent from the choice for G window size
14:47 -!- elichai2 [sid212594@stonehaven.irccloud.com] has joined #secp256k1
14:48 < gmaxwell> sipa: Good point. I agree.
14:54 -!- FelixWeis [sid154231@id-154231.stonehaven.irccloud.com] has joined #secp256k1
17:21 -!- reallll [~belcher@user/belcher] has joined #secp256k1
17:25 -!- belcher_ [~belcher@user/belcher] has quit [Ping timeout: 272 seconds]
23:38 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 240 seconds]
23:45 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
--- Log closed Sat Jul 03 00:00:55 2021