Content
@
0 reply
0 recast
2 reactions
gakonst
@gakonst
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
2 replies
3 recasts
14 reactions
brock
@brock
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
1 reply
0 recast
0 reaction
gakonst
@gakonst
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?
1 reply
0 recast
0 reaction
brock
@brock
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
1 reply
0 recast
1 reaction
gakonst
@gakonst
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
1 reply
0 recast
0 reaction
brock
@brock
i still like the pipelining idea we kicked around awhile back of: call to contract -> immediately start a load a page of storage -> hopefully when we ask for storage val it will have been loaded for us would be cool to see a reth benchmark of % time spent by opcode during exec sync stage
2 replies
0 recast
3 reactions
Dragan Rakita
@draganrakita
io is insignificant with plain state. So this would not give a lot. I did some measurements to check that statement that as a lot of assumption are made that we are io bound. Here is conclusion: https://github.com/bluealloy/revm/pull/499#issuecomment-1589610777
1 reply
0 recast
2 reactions
brock
@brock
i imagine this is with a relatively high quality nvme tho - which for archive nodes is assumed but as reth moves to more pruned nodes, that storage speed requirement may relax and io speed likely actually is a bottleneck (ssd roughly 7x slower, hdds 35x slower)
1 reply
0 recast
3 reactions
