Adjusting of the prices benchmarks after sanity check benchmarks

[xgreenx]

After running sanity check benchmarks, we've got inconsistent results for some opcodes. Part of that is because of the wrong configuration of the price benchmarks, some of them because of the wrong configuration of the sanity check benchmarks.

This PR addresses them and produces more consistent results.

[MitchTurner]

I'm not following this what this is for. These each seem to be converted to the same DatabaseTransaction type under the hood.

[xgreenx]

It is converted to the same type, but inclusion depth increases with each DatabaseTransaction.

During the execution of the block we have several layers of DatabaseTransaction.

When you call get on DatabaseTransaction, it goes to the internal database, which is DatabaseTransaction, that goes to another DatabaseTransaction that goes to RocksDB. 3 layers of DatabaseTransaction simulates the real execution environment complexity.

[MitchTurner]

Hmm. Okay. This might be naive of me, but I feel like we should be benching against the surface above where this happens, that way we don't have to simulate it. That might not be possible, and I'm not able to suggest a way to do it, so I'm not gonna push too hard on that.

[MitchTurner]

The sanity check we are doing 0 and here we do (1 << 18) - 1. Is that okay that they are different?

[xgreenx]

With a sanity check, we may run out of memory before running out of gas. While in cost benchmarks we revert the state of VM after each iteration.

There is no difference in using 0 or u18::MAX with the current implementation, but we need this difference to potentially catch mismatching in sanity check benchmarks and cost benchmarks.

[bvrooman]

Can you provide some context on why we want these extra op codes on post call?

It looks like you're setting register 0x27, which is the $rc in the upcoming srwq opcode, to the script data pointer, then bumping it by a contact ID, a word, a word, and lastly, an asset ID. Is this some sort of additional setup for the srwq at the next iteration?

[xgreenx]

The VmBench::contract_using_db already sets some script data inside, so we need to skip data set by the contract_using_db to get access to the data that we set inside of the benchmark in line 614.

[MitchTurner]

Doesn't this affect the execution time?

[xgreenx]

The same idea as with aloc. There is no difference in the current implementation, but maybe later, it can help us catch some mismatching in cost and results from sanity check.

[Dentosal]

nit:

Suggested change

	if !reason.contains("OutOfGas") {
	panic!("The test failed because of {}", reason);
	}
	assert!(reason.contains("OutOfGas"), "The test failed because of {reason}");