Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Baseline Interpreter Optimizations #279

Open
chfast opened this issue Dec 21, 2020 · 0 comments
Open

Baseline Interpreter Optimizations #279

chfast opened this issue Dec 21, 2020 · 0 comments

Comments

@chfast
Copy link
Member

chfast commented Dec 21, 2020

List of optimizations to investigate

1. Extend bytecode with 33 zero bytes

This requires copying the original code and adding additional 33 zero bytes in the end. The memcpy is ~20x faster than the current JUMPDEST analysis, but this increases the memory footprint.

The number 33 is because:

  • 32 bytes are needed in case of incomplete PUSH32 at the end of the bytecode,
  • additional one zero byte is needed to work as STOP instruction.

This allows implementing 2 optimizations straight away:

  • remove the "end of code" check from the main loop (replace with "infinite" loop),
  • remove the "end of code" check from PUSH instructions implementations.

It would be nice for clients to load code this way.

2. Optimize PUSH with out-of-bound loads

Requires: 1.

Instead of loading of exact number of bytes, load more and mask them. E.g. for PUSH7 load 8 bytes and mask with 0xffffffffffffff.

3. Implement JUMPDEST analysis with AVX instructions.

Analyze more than single byte at a time.

4. Implement interpreter dispatch with "computed goto".

5. Create custom instruction table.

Currently Baseline uses instruction tables from EVMC. This is not efficient it has to lookup information at least in two tables. Custom table can be created using information from evmone::instr.

Draft: https://github.com/ethereum/evmone/tree/baseline_instruction_table.

6. Combine instruction requirements checks

Combine gas cost check and stack overflow/underflow checks so that we have single if jumping to [[unlikely]] error handling section (where you can figure out exact error code).

7. Inline stack requirements checks

There are 4 groups of instructions:

  • no stack violation possible
  • can cause stack underflow
  • can cause stack overflow
  • DUPs

Most of the time you don't need all checks. And the check latency can be hidden in the instruction implementation.

8. Inline gas cost check

Requires: 7.

Same as 7 plus also inline gas cost check. For some instructions this cost is constant, for some it depends on EVM revision. Also some instructions have "variadic" cost so they are check gas cost condition anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant