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?

ah. this could be right - obviously devil in the details and hard to tell without running the numbers^TM but I can see that happening or the perf gain not being big enough for the dev time

basically i’m making the argument that simple machines like the EVM are probably optimized pretty well by their implementation languages compiler such that JIT & multi-op ops won’t show much benefit

reasoning being that LLVM likely produces better asm + reduces branch prediction misses 

i could def be wrong