Rusty Russell on Nostr: Now the good news. The basic idea is still intact: the speed is indeed proportional ...
Now the good news. The basic idea is still intact: the speed is indeed proportional to operand size, so the basic idea is correct, it's just the costing of each operation is different. And we could simply say "what's the slowest operation, we'll assume everything is that slow", but comparing (OP_VERIFY, OP_EQUALS), copying (OP_DUP, OP_CAT) and zero-initializing (OP_UPSHIFT) are pretty common operations, so treating them as lower cost is both fairly simple and amply justified by the numbers.
The evidence so far says we can divide into "fast" (copy, compare, initialize) and "slow" (everything else), where slow is twice as expensive as fast. This overcharges a little, but our thesis is still that we should have ample budget for any resonable operations, and I hope to prove that once I have some realistic placeholder values for the model.
Indeed, we can certainly further optimize various opreations using SSE/AVX/NEON. That's awesome, but I've only gone so far as to assume a 64-bit processor which can perform these operations 64-bits at a time: again, such optimizations would mean we're overcharging for some operations, but my "we have so much budget we don't care" thesis means it doesn't matter. If it becomes commonplace to do (say) multiplications on 4096-bit values, I'm sure someone will do the work to shave a few microseconds off block processing times.
The evidence so far says we can divide into "fast" (copy, compare, initialize) and "slow" (everything else), where slow is twice as expensive as fast. This overcharges a little, but our thesis is still that we should have ample budget for any resonable operations, and I hope to prove that once I have some realistic placeholder values for the model.
Indeed, we can certainly further optimize various opreations using SSE/AVX/NEON. That's awesome, but I've only gone so far as to assume a 64-bit processor which can perform these operations 64-bits at a time: again, such optimizations would mean we're overcharging for some operations, but my "we have so much budget we don't care" thesis means it doesn't matter. If it becomes commonplace to do (say) multiplications on 4096-bit values, I'm sure someone will do the work to shave a few microseconds off block processing times.