Add JIT benchmarks

[xermicus]

Setting the REVIVE_USE_COMPILER env var will enable the JIT in PVM in the pallet. However just setting this variable and running the benchmarks does not tell anything because it measures the whole execution from the get go.

Add to that, because JITed contracts run orders of magnitudes faster, the benchmarking parameters used for benchmark the {EVM,PVM} interpreters are too low to be telling.

What should be done here:

• Add a bench-pvm-jit feature flag to the benchmarks crate which will lead to benchmark the JIT instead the interpreter.
• Implement functions wall-time measuring the compilation and execution (execution means the sandbox is already up - zero startup or compilation overhead, just the execution time).
• Find new parameters suitable for measuring the JIT. They are selected if the bench-pvm-jit feature is set. Ideally they are big enough to be telling but still small enough so the EVM interpreter can execute them too (will be very slow but we need the numbers to compare)

[athei]

You can't really separate compilation vs. execution can you? Or do you want to add code to pallet_revive to do so?

The problem currently is that the Engine is destroyed and re-created for every contract call. This means the sandbox processes are not cached. So most of the overhead will be sandbox process creation. Not compilation.

This problem will go away as soon as the PolkaVM will move into the client. There we will have a global engine that stays alive for the whole life time of the client process.

[xermicus]

Thanks for pointing this out. But that will change once the JIT backend is integrated properly?

[xermicus]

Ah okay just saw your amended comment. Nice. For benchmarks this is quiet important: We want to get fine-grained insights into the different phases of the execution.

I think the wall-time measurements should just be implemented in the pallet? Hidden underneath the runtime benchmarks feature. So the benchmarking infrastructure can just request those directly.

[athei]

I think the wall-time measurements should just be implemented in the pallet?

Probably. We could use the tracing feature for that. Like a custom performance trace type. However, even that might not be enough. Depending on how we design the virtualization host functions. If they just have a single shot compile + instantiate + run API we would not be able to collect this data in the pallet. So we probably want to mirror the PolkaVM API there with different objects for Module and Instance. Makes it a bit more complicated but it seems useful.