A place for talking about the Ethereum Virtual Machine on Farcaster.

crossposting this EVM optimization idea, tl;dr:
1. execute N opcodes at once, define specialized handlers
2. train a transformer to predict stack/mem view given a view of the current mem/stack and a sequence of previous/next opcodes

crossposting this EVM optimization idea, tl;dr:
1. execute N opcodes at once, define specialized handlers
2. train a transformer to predict stack/mem view given a view of the current mem/stack and a sequence of previous/next opcodes

https://twitter.com/gakonst/status/1714411279765688586

i’m not totally convinced this actually will result in much of a speed up personally

this comes down to stack machines being extremely trivial to convert into machine code in the first place (see this talk: https://youtu.be/umSuLpjFUf8?feature=shared)

i think it may end up resulting in more branch pred misses

cto & general partner @paradigm. ceo /ithaca. working with /rust on /ethereum. building /reth and /foundry. https://gakonst.com

I went thru the talk quickly and didnt find a reason why this technique is not useful? are you saying jit/aot is better?

jiting evm code has analysis costz for contracts you cannot convert to machine code ahead of time, so even then ngrams seem useful. 

also how do you gas meter in machine code?

wouldn't you need the transformer to be 100% accurate to be useful? in which case, does it just become a big lookup table?