OP | Count | Total | % | Cum % |
---|---|---|---|---|
PUSH1 | 37,886,773 | 37,886,773 | 11.12% | 11.12% |
PUSH2 | 28,280,939 | 66,167,712 | 8.30% | 19.43% |
POP | 24,003,852 | 90,171,564 | 7.05% | 26.47% |
JUMPDEST | 22,374,953 | 112,546,517 | 6.57% | 33.04% |
SWAP1 | 18,110,085 | 130,656,602 | 5.32% | 38.36% |
DUP2 | 17,393,988 | 148,050,590 | 5.11% | 43.47% |
DUP1 | 16,132,946 | 164,183,536 | 4.74% | 48.20% |
JUMPI | 14,963,477 | 179,147,013 | 4.39% | 52.60% |
#include <stdlib.h> | |
#include <string.h> | |
#include <time.h> | |
#include <stdio.h> | |
namespace interp { | |
enum ops { STOP, ADD, SUB, MUL, DIV }; | |
const char* op_stop(long*&,const char* PC) { |
// https://people.csail.mit.edu/rivest/Rivest-rc5rev.pdf | |
#include <stdint.h> | |
#include <string.h> | |
#include <math.h> | |
uint32_t shift_left(uint32_t v, uint32_t n) { | |
return v << n; | |
// return v * pow(2, n); | |
} |
gcolvin@Dell:~/ether/perf-tests/test/unittests/performance$ make -f tests.mk ETHVM-JIT=./ethvm add256.ran | |
echo ethvm-jit; time -p ./ethvm --vm jit test add256.bin; touch add256.ran | |
ethvm-jit | |
; ModuleID = '7665577a0bc6fbdb1b11cddad76dad92559f0915def3ec7cbb39ad92ae658c11F' | |
source_filename = "7665577a0bc6fbdb1b11cddad76dad92559f0915def3ec7cbb39ad92ae658c11F" | |
%Runtime = type { %RuntimeData*, %Env*, %Array } | |
%RuntimeData = type { i64, i64, i8*, i64, i256, i8*, i64, i256, i256, i64 } | |
%Env = type opaque | |
%Array = type { i256*, i64, i64 } |
gcolvin@Dell:~/ether/perf-tests/test/unittests/performance$ make -f tests.mk ETHVM-JIT=./ethvm add256.ran | |
echo ethvm-jit; time -p ./ethvm --vm jit test add256.bin; touch add256.ran | |
ethvm-jit | |
; ModuleID = '7665577a0bc6fbdb1b11cddad76dad92559f0915def3ec7cbb39ad92ae658c11F' | |
source_filename = "7665577a0bc6fbdb1b11cddad76dad92559f0915def3ec7cbb39ad92ae658c11F" | |
%Runtime = type { %RuntimeData*, %Env*, %Array } | |
%RuntimeData = type { i64, i64, i8*, i64, i256, i8*, i64, i256, i256, i64 } | |
%Env = type opaque | |
%Array = type { i256*, i64, i64 } |
// For example take this code | |
// XPUSH(1,1) ff | |
// XPUSH(1,1) ee | |
// XAND(1,1) | |
// run it through the preprocessor and tr | |
// gcc -E -P -x c-header -include masm.h test.evm | tr -d [:space:] | |
// and get this output | |
// e011ffe011eed611 | |
// Haven't figured out labels yet, might have to just count. | |
// No, this is not suitable for real work, but will suffice |
I've been thinking on an effective cache of compiled bytecode that is difficult to attack. LRU, FIFO, and related eviction/retention policies are easily attacked with round robin access. Currently there are about 4 GB worth of compiled contract code on tth blockchain. Two policies seem safe. I'd like to discuss whether they are in fact effective and safe.
- Random eviction:
The number of transactions per contract is Zipf distributed with alpha=1; I estimate that if you cached 1/4 of the contracts you'd get a hit ratio of about 80-90%. Probably worth it, and it seems expensive to DoS. To degrade the cache you have to pollute it with spam, and the more spam you put in the higher the probability of it getting kicked out. If you managed to get the cache half-full of spam then you would have to keep paying for half of all transactions to keep it that way.
- Expensive retention:
The retention formula is F = geo/m
, where the factors are moving averages of
g
= gas use