FVM can execute messages concurrently in separate CPU threads, assuming absence of dependencies between the messages; state updates are merged in a trivial way at the end of concurrent execution. This is a prerequisite for all the subsequent work. Performance measurement confirms the viability of parallel execution for increasing FEVM performance.
Steps:
[x] #209
[ ] Team week – deeper understanding and design decisions (1w)
[ ] Setup an FEVM testbed and run a hello-world example (1w)
[ ] Implement essential mechanisms to concurrently execute FEVM on a thread pool, discarding state updates (2w)
[ ] Implement a basic mechanism to merge state updates from concurrent execution of F(E)VM (2w)
[ ] Implement a benchmark with very simple synthetic workload (1w)
[ ] Perform experiments and analyze the results; start preparing for implementing the prototype (1w)
Risks and alternatives:
This sub-milestone is now fully packed in terms of timeline; any unknown major obstacle may require rescoping
It may require more time to understand how FVM works in order to avoid misconception and wasted efforts. Alternatives:
Stretch the timeline for the unknown unknowns?
Yann’s code may not be suitable for the current version of FVM. Alternatives:
Extend the timeline and implement the required functionality based on the current FVM code
We may miss low-hanging fruits specific to FEVM that would allow us to create substantial impact faster than if directly targeting the Block-STM-based solution. Alternatives:
Prioritize implementing a very simple preliminary benchmark and performance analysis of FEVM? (would need renaming)
FVM can execute messages concurrently in separate CPU threads, assuming absence of dependencies between the messages; state updates are merged in a trivial way at the end of concurrent execution. This is a prerequisite for all the subsequent work. Performance measurement confirms the viability of parallel execution for increasing FEVM performance.
Steps:
Risks and alternatives:
ETA: 2023-03-31