Raise CPI Nesting Limit

Thus, the only thing this really raises is the amount of total memory allocated simultaneously (peak can be higher if instructions are nested). But the interaction with that memory stays the same; the VM just needs to "remember" more context. But do we know the actual specifications of this? In other words, can we feasibly state that if someone does 64 instructions in a single transaction through 8 instructions (nested to 8 frames each) to some super large program every time, they won't blast a node's memory? I suppose we can scratchpad it a bit. We have a stack, heap, input region, and program section, and you'd just multiple those by 8, right?

Well, you can already have 4 VMs simultaneously (via CPI nesting) so a step up to 8 is only doubling it. The program section is allocated per executable, not per VM. And the input region will be a whole lot smaller once 219 (direct mapping) is active. Thus, only the stack and heap memory allocation would double.

I threw together a script to estimate the sBPF VM load a node could possibly incur per slot. I ran it across 50 mainnet-beta blocks. I counted instructions (not transactions) that invoke sBPF programs (not builtins). Each instruction could initiate a CPI chain. Instruction Stats Across 50 Blocks - Total sBPF instructions: 64996 - Average per block: 1300 - Maximum in a block: 3122 Upper Bound on VM Memory Per Instruction (Post-Direct-Mapping) Each CPI frame duplicates two memory regions: - Max stack size(https://github.com/anza-xyz/agave/blob/464dcdf35eccd44b846a375a0f7be4a50f71a3b6/program-runtime/src/executionbudget.rsL9-L13): 256 KiB - Max heap size(https://github.com/anza-xyz/agave/blob/4

a step up to 8 is only doubling it When it comes to memory, doubling anything is always something to consider carefully. I ran a little experiment, and put my findings in the root discussion for anyone who wants to check this SIMD out in the future.

Just out of curiosity @jacobcreech how necessary is a nested depth of 8? Could we get away with 6? 8 seems excessive.

Nice work! Average Case (1300 instructions): 4 CPIs: 2.0 MiB 1300 = 2.54 GiB 8 CPIs: 4.0 MiB 1300 = 5.08 GiB Max Case (3122 instructions): 4 CPIs: 2.0 MiB 3122 = 6.10 GiB 8 CPIs: 4.0 MiB 3122 = 12.20 GiB These numbers are only relevant for memory bandwidth (as that much needs to be zeroed out). They are not representative of peak memory allocation because not all transactions coexist in memory at the same time. Yes, we have multiple threads but each one does serial processing. Thus for peak allocation you would have to multiply the number of transaction processor threads by the maximum CPI nesting (2.0 MiB or 4.0 MiB).

Thus for peak allocation you would have to multiply the number of transaction processor threads by the maximum CPI nesting (2.0 MiB or 4.0 MiB). Right, yep. This is a very far-fetched, near-impossible worst-case upper bound.

how necessary is a nested depth of 8? Could we get away with 6? 8 seems excessive. You need at least 5 in order to work with most smart wallet usecases. 8 gives a bit more room as people add additional CPI depth to their programs so as to not break the smart wallet usecases. Could we get away with 6? Potentially as a first step. Average Case (1300 instructions): 4 CPIs: 2.0 MiB 1300 = 2.54 GiB 8 CPIs: 4.0 MiB 1300 = 5.08 GiB Max Case (3122 instructions): 4 CPIs: 2.0 MiB 3122 = 6.10 GiB 8 CPIs: 4.0 MiB 3122 = 12.20 GiB Is this still the case after direct mapping? I thought this change was held until direct mapping landed first.