Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests: external evm benchmarks #24050

Merged
merged 2 commits into from
Jan 28, 2022
Merged

Conversation

chfast
Copy link
Member

@chfast chfast commented Dec 3, 2021

I converted evmone's benchmarks to StateTest format and they are available at https://github.com/ipsilon/evm-benchmarks. Here added as a git submodule. We are still discussing how exactly extract and maintain the benchmark suite outside of the evmone project.

Then I copied a lot of code from TestState() to create BenchmarkState() with the goal to use the lowest EVM execute function possible. I stopped at EVM.Call() but I believe even Interpreter.Run() is possible.

If some refactoring is done, some code can be shared between TestState() and BenchmarkState(). But the test runner is quite convoluted with reflect being used at some level...

go test -run - -bench='.*' ./tests/...

@chfast
Copy link
Member Author

chfast commented Dec 3, 2021

Comparison between evm run --bench and go test -bench.

name                             old time/op  new time/op  delta
micro/memory_grow_mload/nogrow    219µs ± 0%   230µs ± 1%   +4.81%  (p=0.000 n=18+18)
micro/memory_grow_mload/by1       230µs ± 1%   239µs ± 0%   +4.06%  (p=0.000 n=20+19)
micro/memory_grow_mload/by16      292µs ± 1%   283µs ± 0%   -3.11%  (p=0.000 n=19+20)
micro/memory_grow_mload/by32      367µs ± 1%   340µs ± 1%   -7.54%  (p=0.000 n=20+19)
micro/signextend/zero             390µs ± 1%   430µs ± 1%  +10.27%  (p=0.000 n=20+18)
micro/signextend/one              406µs ± 1%   445µs ± 1%   +9.46%  (p=0.000 n=20+20)
micro/jump_around/empty           145µs ± 1%   143µs ± 1%   -1.00%  (p=0.000 n=17+20)
micro/memory_grow_mstore/nogrow   445µs ± 0%   460µs ± 1%   +3.39%  (p=0.000 n=19+20)
micro/memory_grow_mstore/by1      460µs ± 1%   473µs ± 1%   +2.82%  (p=0.000 n=20+19)
micro/memory_grow_mstore/by16     539µs ± 0%   534µs ± 0%   -0.93%  (p=0.000 n=18+18)
micro/memory_grow_mstore/by32     607µs ± 1%   575µs ± 1%   -5.22%  (p=0.000 n=20+19)
micro/JUMPDEST_n0/empty          2.74ms ± 0%  3.13ms ± 1%  +14.07%  (p=0.000 n=19+20)
main/sha1_divs/empty              196µs ± 1%   202µs ± 0%   +3.07%  (p=0.000 n=20+20)
main/sha1_divs/1351              3.95ms ± 0%  4.12ms ± 0%   +4.16%  (p=0.000 n=20+19)
main/sha1_divs/2737              7.71ms ± 0%  8.05ms ± 0%   +4.42%  (p=0.000 n=19+20)
main/sha1_divs/5311              15.1ms ± 0%  15.7ms ± 0%   +4.31%  (p=0.000 n=18+19)
main/weierstrudel/0               471µs ± 0%   478µs ± 1%   +1.60%  (p=0.000 n=18+20)
main/weierstrudel/1               980µs ± 1%  1004µs ± 0%   +2.43%  (p=0.000 n=20+18)
main/weierstrudel/3              1.54ms ± 1%  1.58ms ± 0%   +2.73%  (p=0.000 n=20+20)
main/weierstrudel/9              3.18ms ± 0%  3.28ms ± 1%   +2.99%  (p=0.000 n=20+20)
main/weierstrudel/14             4.55ms ± 1%  4.71ms ± 1%   +3.38%  (p=0.000 n=18+20)
main/sha1_shifts/empty            151µs ± 0%   153µs ± 0%   +1.57%  (p=0.000 n=20+17)
main/sha1_shifts/1351            3.09ms ± 0%  3.19ms ± 0%   +3.24%  (p=0.000 n=14+19)
main/sha1_shifts/2737            6.02ms ± 0%  6.21ms ± 0%   +3.21%  (p=0.000 n=17+20)
main/sha1_shifts/5311            11.8ms ± 1%  12.2ms ± 1%   +3.19%  (p=0.000 n=19+20)
main/blake2b_huff/empty           100µs ± 0%   102µs ± 0%   +2.60%  (p=0.000 n=18+18)
main/blake2b_huff/2805nulls      1.90ms ± 1%  2.00ms ± 1%   +5.26%  (p=0.000 n=20+20)
main/blake2b_huff/5610nulls      3.70ms ± 0%  3.89ms ± 0%   +5.00%  (p=0.000 n=19+18)
main/blake2b_huff/8415nulls      5.43ms ± 1%  5.69ms ± 0%   +4.86%  (p=0.000 n=20+18)
main/blake2b_shifts/2805nulls    14.2ms ± 2%  15.3ms ± 1%   +7.48%  (p=0.000 n=20+20)
main/blake2b_shifts/5610nulls    28.1ms ± 0%  30.6ms ± 1%   +8.71%  (p=0.000 n=18+20)
main/blake2b_shifts/8415nulls    41.9ms ± 0%  45.6ms ± 0%   +9.00%  (p=0.000 n=16+18)
[Geo mean]                       1.40ms       2.42ms       +73.04%

@chfast chfast force-pushed the evm_benchmarks branch 2 times, most recently from cf433bd to f4603b1 Compare December 8, 2021 20:47
@chfast chfast marked this pull request as ready for review December 8, 2021 20:48
@chfast
Copy link
Member Author

chfast commented Dec 8, 2021

I changed the implementation to use Interpreter.Run(). I did this to proof this is possible, but now I think this may be bad design because StateTest uses EVM.Call() and evm run uses runtime.Call() so we have 3 different entry points for EVM execution.

Using one of the Call() functions may be better. And we may improve the performance of this part later too.

@chfast
Copy link
Member Author

chfast commented Dec 8, 2021

@holiman, please check if jumpdest analysis is cached for these runs.

@holiman
Copy link
Contributor

holiman commented Dec 10, 2021

@holiman, please check if jumpdest analysis is cached for these runs.

Yeah, so apparently the Run does one analysis per benchmark, whereas the Call variants does b.N:

BenchmarkEVM/main/blake2b_huff/London/0/Run-6              10000            115034 ns/op                 1.000 analysis
BenchmarkEVM/main/blake2b_huff/London/1/Run-6                493           3029761 ns/op                 1.000 analysis
BenchmarkEVM/main/blake2b_huff/London/2/Run-6                236           5618322 ns/op                 1.000 analysis
BenchmarkEVM/main/blake2b_huff/London/3/Run-6                164           7499899 ns/op                 1.000 analysis
BenchmarkEVM/main/blake2b_huff/London/4/Run-6                 22          56706663 ns/op                 1.000 analysis
BenchmarkEVM/main/blake2b_huff/London/0/Call-6              8616            141017 ns/op              8616 analysis
BenchmarkEVM/main/blake2b_huff/London/1/Call-6               469           2526879 ns/op               469.0 analysis
BenchmarkEVM/main/blake2b_huff/London/2/Call-6               238           4763046 ns/op               238.0 analysis
BenchmarkEVM/main/blake2b_huff/London/3/Call-6               160           7526510 ns/op               160.0 analysis
BenchmarkEVM/main/blake2b_huff/London/4/Call-6                19          54531691 ns/op                19.00 analysis

@holiman
Copy link
Contributor

holiman commented Dec 10, 2021

It might be possible to fix this via a hack. Instead of

			sender := vm.AccountRef(msg.From())
			b.ResetTimer()

			for n := 0; n < b.N; n++ {
				// Execute the message.
				snapshot := statedb.Snapshot()
				_, _, err = evm.Call(sender, *msg.To(), msg.Data(), msg.Gas(), msg.Value())

You make the sender a Contract. That way, the c.jumpdests will be populated (and reused) via the child call.

Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose Call might be 'correcter', but I also think we should avoid including jumpdest analysis time in these benchmarks

tests/state_test.go Outdated Show resolved Hide resolved
tests/state_test.go Outdated Show resolved Hide resolved
@chfast
Copy link
Member Author

chfast commented Dec 15, 2021

I suppose Call might be 'correcter', but I also think we should avoid including jumpdest analysis time in these benchmarks

Maybe the way is to be have API with more explicit code analysis handling.

@chfast
Copy link
Member Author

chfast commented Dec 21, 2021

Any resolution to this?

@holiman
Copy link
Contributor

holiman commented Dec 21, 2021

Maybe the way is to be have API with more explicit code analysis handling.

Do you have any proposal? I suggested a way to hack around it -- do you think there's some better way to do it? I don't really have any good alternatives.

@chfast
Copy link
Member Author

chfast commented Dec 21, 2021

Wrapping with another Call seems not easy and wrong because this explicitly modifies the StateTest structure. But I can try to do this to see how this work.

Alternative is to have more explicit code analysis cache management, i.e. analyze the code with one API outside of the loop and pass it to Call() inside the loop. So far the Contract abstraction which looks up it's sender seems very convoluted. But this seems to be longer work and we need EVM benchmark now.

@chfast
Copy link
Member Author

chfast commented Dec 21, 2021

BTW, how do you collect "analysis" stats for benchmarks?

@chfast
Copy link
Member Author

chfast commented Dec 21, 2021

I did one more commit which looks a bit better (and looks better IMHO) but in general the loop seems to be getting little faster but this is not visible in benchmarks doing more than just JUMPDEST.

name                                   old time/op    new time/op    delta
SimpleLoop/staticcall-identity-100M-8     203ms ± 0%     205ms ± 2%    ~     (p=0.156 n=9+10)
SimpleLoop/call-identity-100M-8           283ms ± 1%     282ms ± 1%  -0.47%  (p=0.029 n=10+10)
SimpleLoop/loop-100M-8                    281ms ± 1%     276ms ± 1%  -1.79%  (p=0.000 n=10+10)
SimpleLoop/call-nonexist-100M-8           631ms ± 2%     624ms ± 0%  -1.06%  (p=0.000 n=10+9)
SimpleLoop/call-EOA-100M-8                279ms ± 1%     274ms ± 1%  -1.62%  (p=0.000 n=9+10)
SimpleLoop/call-reverting-100M-8          557ms ± 0%     559ms ± 1%    ~     (p=0.075 n=10+10)
[Geo mean]                                341ms          339ms       -0.65%
name                                  old time/op  new time/op  delta                                                                                                                                                             
micro/memory_grow_mload/nogrow         212µs ± 1%   208µs ± 1%   -2.04%  (p=0.000 n=19+20)                                                                                                                                        
micro/memory_grow_mload/by1            223µs ± 1%   218µs ± 1%   -1.86%  (p=0.000 n=18+20)                                                                                                                                        
micro/memory_grow_mload/by16           285µs ± 0%   281µs ± 1%   -1.45%  (p=0.000 n=18+20)                                                                                                                                        
micro/memory_grow_mload/by32           358µs ± 1%   354µs ± 1%   -1.24%  (p=0.000 n=20+20)                                                                                                                                        
micro/signextend/zero                  355µs ± 0%   307µs ± 1%  -13.27%  (p=0.000 n=20+17)                                                                                                                                        
micro/signextend/one                   369µs ± 1%   320µs ± 1%  -13.35%  (p=0.000 n=19+20)                                                                                                                                        
micro/loop_with_many_jumpdests/empty  1.69µs ± 2%  1.68µs ± 2%     ~     (p=0.433 n=20+20)                                                                                                                                        
micro/jump_around/empty                135µs ± 1%   132µs ± 1%   -1.80%  (p=0.000 n=20+20)                                                                                                                                        
micro/memory_grow_mstore/nogrow        449µs ± 0%   438µs ± 1%   -2.49%  (p=0.000 n=18+20)                                                                                                                                        
micro/memory_grow_mstore/by1           464µs ± 1%   452µs ± 1%   -2.62%  (p=0.000 n=20+20)                                                                                                                                        
micro/memory_grow_mstore/by16          523µs ± 0%   535µs ± 0%   +2.22%  (p=0.000 n=20+20)                                                                                                                                        
micro/memory_grow_mstore/by32          602µs ± 1%   600µs ± 1%   -0.29%  (p=0.015 n=20+19)                                                                                                                                        
micro/JUMPDEST_n0/empty               2.58ms ± 0%  2.34ms ± 0%   -9.39%  (p=0.000 n=18+17)                                                                                                                                        
main/sha1_divs/empty                   176µs ± 0%   179µs ± 1%   +1.26%  (p=0.000 n=19+20)                                                                                                                                        
main/sha1_divs/1351                   3.55ms ± 1%  3.59ms ± 1%   +1.10%  (p=0.000 n=19+19)
main/sha1_divs/2737                   6.92ms ± 0%  7.00ms ± 0%   +1.17%  (p=0.000 n=17+18)
main/sha1_divs/5311                   13.5ms ± 0%  13.7ms ± 1%   +1.33%  (p=0.000 n=20+20)
main/weierstrudel/0                    446µs ± 0%   444µs ± 0%   -0.62%  (p=0.000 n=20+19)
main/weierstrudel/1                    923µs ± 0%   913µs ± 1%   -1.16%  (p=0.000 n=18+19)
main/weierstrudel/3                   1.45ms ± 0%  1.44ms ± 0%   -0.89%  (p=0.000 n=19+17)
main/weierstrudel/9                   3.03ms ± 1%  2.99ms ± 1%   -1.25%  (p=0.000 n=20+19)
main/weierstrudel/14                  4.33ms ± 0%  4.28ms ± 1%   -1.04%  (p=0.000 n=19+20)
main/sha1_shifts/empty                 132µs ± 1%   137µs ± 0%   +3.54%  (p=0.000 n=20+20)
main/sha1_shifts/1351                 2.71ms ± 1%  2.79ms ± 0%   +2.96%  (p=0.000 n=20+20)
main/sha1_shifts/2737                 5.28ms ± 0%  5.43ms ± 0%   +2.91%  (p=0.000 n=18+18)
main/sha1_shifts/5311                 10.3ms ± 0%  10.6ms ± 0%   +3.10%  (p=0.000 n=18+19)
main/blake2b_huff/empty               95.7µs ± 0%  96.3µs ± 0%   +0.67%  (p=0.000 n=17+18)
main/blake2b_huff/2805nulls           1.85ms ± 0%  1.86ms ± 0%   +0.33%  (p=0.000 n=19+20)
main/blake2b_huff/5610nulls           3.59ms ± 0%  3.61ms ± 0%   +0.40%  (p=0.000 n=17+19)
main/blake2b_huff/8415nulls           5.26ms ± 0%  5.28ms ± 1%   +0.40%  (p=0.000 n=19+19)
main/blake2b_shifts/2805nulls         13.1ms ± 2%  13.2ms ± 2%   +1.13%  (p=0.001 n=19+17)
main/blake2b_shifts/5610nulls         25.9ms ± 2%  26.2ms ± 1%   +1.53%  (p=0.000 n=17+19)
main/blake2b_shifts/8415nulls         38.4ms ± 1%  39.2ms ± 2%   +2.01%  (p=0.000 n=17+18)
[Geo mean]                            1.07ms       1.06ms        -0.96%

@holiman
Copy link
Contributor

holiman commented Dec 29, 2021

BTW, how do you collect "analysis" stats for benchmarks?

The b has support for custom metrics, e.g. b.ReportMetric(float64(b.N),"foobar"). So I hacked in a global counter to count each analysis, then added it as a custom metric.

@holiman
Copy link
Contributor

holiman commented Dec 29, 2021

This makes the analysis become reused:

diff --git a/core/vm/analysis.go b/core/vm/analysis.go
index 449cded2a8..5a4fe12d03 100644
--- a/core/vm/analysis.go
+++ b/core/vm/analysis.go
@@ -66,8 +66,11 @@ func (bits *bitvec) codeSegment(pos uint64) bool {
 	return ((*bits)[pos/8] & (0x80 >> (pos % 8))) == 0
 }
 
+var AnalysisCount = uint64(0)
+
 // codeBitmap collects data locations in code.
 func codeBitmap(code []byte) bitvec {
+	AnalysisCount++
 	// The bitmap is 4 bytes longer than necessary, in case the code
 	// ends with a PUSH32, the algorithm will push zeroes onto the
 	// bitvector outside the bounds of the actual code.
diff --git a/tests/state_test.go b/tests/state_test.go
index 8ffa001c0b..9905a6cf9f 100644
--- a/tests/state_test.go
+++ b/tests/state_test.go
@@ -184,6 +184,11 @@ func runBenchmark(b *testing.B, t *StateTest) {
 		key := fmt.Sprintf("%s/%d/Run", subtest.Fork, subtest.Index)
 
 		b.Run(key, func(b *testing.B) {
+			vm.AnalysisCount = 0
+			defer func() {
+				b.ReportMetric(float64(vm.AnalysisCount), "analysis")
+			}()
+
 			vmconfig := vm.Config{}
 			config, eips, err := GetChainConfig(subtest.Fork)
 			if err != nil {
@@ -235,6 +240,11 @@ func runBenchmarkCall(b *testing.B, t *StateTest) {
 		key := fmt.Sprintf("%s/%d/Call", subtest.Fork, subtest.Index)
 
 		b.Run(key, func(b *testing.B) {
+			vm.AnalysisCount = 0
+			defer func() {
+				b.ReportMetric(float64(vm.AnalysisCount), "analysis")
+			}()
+
 			vmconfig := vm.Config{}
 
 			config, eips, err := GetChainConfig(subtest.Fork)
@@ -284,7 +294,8 @@ func runBenchmarkCall(b *testing.B, t *StateTest) {
 			context.BaseFee = baseFee
 			evm := vm.NewEVM(context, txContext, statedb, config, vmconfig)
 
-			sender := vm.AccountRef(msg.From())
+			sender := vm.NewContract(vm.AccountRef(msg.From()), vm.AccountRef(msg.From()),
+				nil, 0)
 			b.ResetTimer()
 			for n := 0; n < b.N; n++ {
 				// Execute the message.

@chfast
Copy link
Member Author

chfast commented Jan 3, 2022

I compared two implementation variants: Run (old) and Call (new). The difference is small and does not which variant is faster. So I'm for staying with "Call" variant.

name                                               old time/op  new time/op  delta
EVM/main/blake2b_huff/London/0/Run-8               85.1µs ± 1%  85.8µs ± 1%  +0.84%  (p=0.000 n=9+9)
EVM/main/blake2b_huff/London/1/Run-8               1.84ms ± 1%  1.85ms ± 0%  +0.21%  (p=0.035 n=9+10)
EVM/main/blake2b_huff/London/2/Run-8               3.59ms ± 0%  3.60ms ± 0%  +0.31%  (p=0.003 n=8+8)
EVM/main/blake2b_huff/London/3/Run-8               5.38ms ± 0%  5.28ms ± 0%  -1.82%  (p=0.000 n=8+10)
EVM/main/blake2b_huff/London/4/Run-8               41.4ms ± 2%  41.0ms ± 0%    ~     (p=0.481 n=10+10)
EVM/main/blake2b_shifts/London/0/Run-8             12.7ms ± 0%  12.7ms ± 0%    ~     (p=0.274 n=8+10)
EVM/main/blake2b_shifts/London/1/Run-8             25.4ms ± 1%  25.6ms ± 1%    ~     (p=0.052 n=10+10)
EVM/main/blake2b_shifts/London/2/Run-8             37.8ms ± 0%  37.9ms ± 0%  +0.35%  (p=0.001 n=9+10)
EVM/main/blake2b_shifts/London/3/Run-8              294ms ± 1%   294ms ± 1%    ~     (p=0.190 n=10+10)
EVM/main/sha1_divs/London/0/Run-8                   175µs ± 2%   173µs ± 1%    ~     (p=0.105 n=10+10)
EVM/main/sha1_divs/London/1/Run-8                  3.59ms ± 2%  3.54ms ± 1%  -1.43%  (p=0.023 n=10+10)
EVM/main/sha1_divs/London/2/Run-8                  7.03ms ± 2%  6.91ms ± 1%  -1.64%  (p=0.015 n=10+10)
EVM/main/sha1_divs/London/3/Run-8                  13.9ms ± 0%  13.5ms ± 1%  -2.81%  (p=0.000 n=9+10)
EVM/main/sha1_divs/London/4/Run-8                   166ms ± 3%   165ms ± 1%    ~     (p=0.315 n=10+10)
EVM/main/sha1_shifts/London/0/Run-8                 130µs ± 3%   128µs ± 1%    ~     (p=0.165 n=10+10)
EVM/main/sha1_shifts/London/1/Run-8                2.69ms ± 9%  2.66ms ± 1%    ~     (p=0.143 n=10+10)
EVM/main/sha1_shifts/London/2/Run-8                5.24ms ± 3%  5.18ms ± 0%    ~     (p=0.481 n=10+10)
EVM/main/sha1_shifts/London/3/Run-8                10.4ms ± 4%  10.2ms ± 1%    ~     (p=0.143 n=10+10)
EVM/main/sha1_shifts/London/4/Run-8                 125ms ± 3%   123ms ± 0%    ~     (p=1.000 n=10+10)
EVM/main/weierstrudel/London/0/Run-8                427µs ± 0%   428µs ± 0%  +0.37%  (p=0.001 n=10+10)
EVM/main/weierstrudel/London/1/Run-8                891µs ± 1%   891µs ± 1%    ~     (p=0.780 n=10+9)
EVM/main/weierstrudel/London/2/Run-8               1.41ms ± 0%  1.41ms ± 0%    ~     (p=0.971 n=10+10)
EVM/main/weierstrudel/London/3/Run-8               2.97ms ± 0%  2.96ms ± 1%  -0.33%  (p=0.019 n=10+10)
EVM/main/weierstrudel/London/4/Run-8               4.25ms ± 1%  4.24ms ± 0%    ~     (p=0.122 n=10+8)
EVM/micro/JUMPDEST_n0/London/0/Run-8               2.58ms ± 0%  2.58ms ± 0%  +0.19%  (p=0.002 n=9+9)
EVM/micro/jump_around/London/0/Run-8                116µs ± 1%   117µs ± 1%  +0.56%  (p=0.003 n=10+10)
EVM/micro/loop_with_many_jumpdests/London/0/Run-8  39.1ms ± 1%  39.1ms ± 0%    ~     (p=0.447 n=10+9)
EVM/micro/memory_grow_mload/London/0/Run-8          211µs ± 2%   209µs ± 0%    ~     (p=0.447 n=10+9)
EVM/micro/memory_grow_mload/London/1/Run-8          218µs ± 2%   221µs ± 1%  +1.36%  (p=0.001 n=9+10)
EVM/micro/memory_grow_mload/London/2/Run-8          262µs ± 1%   264µs ± 0%  +0.87%  (p=0.000 n=10+10)
EVM/micro/memory_grow_mload/London/3/Run-8          318µs ± 2%   321µs ± 1%    ~     (p=0.075 n=10+10)
EVM/micro/memory_grow_mstore/London/0/Run-8         434µs ± 1%   436µs ± 0%  +0.32%  (p=0.040 n=9+9)
EVM/micro/memory_grow_mstore/London/1/Run-8         448µs ± 1%   451µs ± 0%  +0.62%  (p=0.001 n=9+10)
EVM/micro/memory_grow_mstore/London/2/Run-8         494µs ± 0%   497µs ± 0%  +0.55%  (p=0.000 n=10+10)
EVM/micro/memory_grow_mstore/London/3/Run-8         547µs ± 1%   554µs ± 1%  +1.24%  (p=0.000 n=10+10)
EVM/micro/signextend/London/0/Run-8                 318µs ± 0%   319µs ± 0%  +0.38%  (p=0.008 n=10+9)
EVM/micro/signextend/London/1/Run-8                 332µs ± 0%   334µs ± 0%  +0.38%  (p=0.000 n=10+9)
[Geo mean]                                         2.28ms       2.28ms       -0.27%

Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@holiman holiman added this to the 1.10.16 milestone Jan 21, 2022
@holiman holiman changed the title EVM benchmarks tests: external evm benchmarks Jan 21, 2022
@@ -61,6 +68,7 @@ func TestState(t *testing.T) {
for _, dir := range []string{
stateTestDir,
legacyStateTestDir,
benchmarksDir, // FIXME: This does not seem to work, but we want to test benchmarks!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this fixme about? Do the tests in the benchmarks dir still not work? Something we need to look into or can this comment be removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it actually works as expected. Let me find it in the logs...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These run, however the "benchmark" dir name is omitted.

--- PASS: TestState (0.05s)
    --- PASS: TestState/main/weierstrudel.json (0.05s)
        --- PASS: TestState/main/weierstrudel.json/London/0/trie (0.00s)
        --- PASS: TestState/main/weierstrudel.json/London/0/snap (0.00s)
        --- PASS: TestState/main/weierstrudel.json/London/1/trie (0.00s)
        --- PASS: TestState/main/weierstrudel.json/London/1/snap (0.00s)
        --- PASS: TestState/main/weierstrudel.json/London/2/trie (0.00s)
        --- PASS: TestState/main/weierstrudel.json/London/2/snap (0.00s)
        --- PASS: TestState/main/weierstrudel.json/London/3/trie (0.01s)
        --- PASS: TestState/main/weierstrudel.json/London/3/snap (0.01s)
        --- PASS: TestState/main/weierstrudel.json/London/4/trie (0.01s)
        --- PASS: TestState/main/weierstrudel.json/London/4/snap (0.01s)
    --- PASS: TestState/main/blake2b_huff.json (0.17s)

@holiman holiman merged commit 64c53ed into ethereum:master Jan 28, 2022
@holiman holiman deleted the evm_benchmarks branch January 28, 2022 07:47
sidhujag pushed a commit to syscoin/go-ethereum that referenced this pull request Jan 28, 2022
* tests: add ipsilon/evm-benchmarks git submodule

* tests: plug-in evm-benchmarks
JacekGlen pushed a commit to JacekGlen/go-ethereum that referenced this pull request May 26, 2022
* tests: add ipsilon/evm-benchmarks git submodule

* tests: plug-in evm-benchmarks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants