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

fix minor regression in txnMerkleToRaw #3608

Conversation

tsachiherman
Copy link
Contributor

Summary

My previous PR was causing a minor regression. Thanks to @jannotti comment, I think that I was able to fix the regression, and added a proper testing for that.

Test Plan

New benchmark result ( no inner method anymore )

goos: darwin
goarch: amd64
pkg: github.com/algorand/go-algorand/data/bookkeeping
cpu: Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
BenchmarkTxnMerkleToRaw/copy-8         	1000000000	         1.129 ns/op	       0 B/op	       0 allocs/op
BenchmarkTxnMerkleToRaw/append-8       	243079730	         4.886 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/algorand/go-algorand/data/bookkeeping	3.183s

Copy link
Contributor

@jannotti jannotti left a comment

Choose a reason for hiding this comment

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

This looks good. Am I understanding properly that the big win came from not needing to build slices, and instead passing the digests as arrays? Maybe that then allowed the copy loop to be unrolled because the size was hardcoded?

@tsachiherman
Copy link
Contributor Author

tsachiherman commented Feb 9, 2022

This looks good. Am I understanding properly that the big win came from not needing to build slices, and instead passing the digests as arrays? Maybe that then allowed the copy loop to be unrolled because the size was hardcoded?

The fact that the size is fixed ( hence no slice ), makes it simpler for the copy, since there is no risk of "overlapping".
Passing large arrays isn't great, since it's usually mean that we have a copy of the array; however, in the case of this method, the compiler can just inline the function and therefore eliminate the argument-copying.

As for the wins in avoiding building a slice : that's also true. The size of a slice is 24 bytes. The size of the digest is 32 bytes. so, the outcome might have been different for bigger slices. For 32 byte slices, passing it as an array seems to perform better.

disabling the function inlining using

//go:noinline
func txnMerkleToRawAppend ...

gave the following results:

goos: darwin
goarch: amd64
pkg: github.com/algorand/go-algorand/data/bookkeeping
cpu: Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
BenchmarkTxnMerkleToRaw/copy-8         	31915742	        36.67 ns/op	      64 B/op	       1 allocs/op
BenchmarkTxnMerkleToRaw/append-8       	36118341	        32.91 ns/op	      64 B/op	       1 allocs/op
PASS
ok  	github.com/algorand/go-algorand/data/bookkeeping	2.651s

I believe that the slowness in the copy-8 above is due to the extra data being copied on the stack.

@codecov-commenter
Copy link

codecov-commenter commented Feb 9, 2022

Codecov Report

Merging #3608 (aea9374) into feature/dilithium-scheme-integration (bd7fcc8) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

Impacted file tree graph

@@                           Coverage Diff                            @@
##           feature/dilithium-scheme-integration    #3608      +/-   ##
========================================================================
- Coverage                                 48.07%   48.06%   -0.02%     
========================================================================
  Files                                       381      381              
  Lines                                     62061    62061              
========================================================================
- Hits                                      29836    29827       -9     
- Misses                                    28807    28814       +7     
- Partials                                   3418     3420       +2     
Impacted Files Coverage Δ
data/bookkeeping/txn_merkle.go 84.61% <100.00%> (ø)
ledger/blockqueue.go 82.18% <0.00%> (-2.88%) ⬇️
agreement/cryptoVerifier.go 75.17% <0.00%> (-2.13%) ⬇️
agreement/proposalManager.go 96.07% <0.00%> (-1.97%) ⬇️
data/abi/abi_type.go 87.67% <0.00%> (-0.95%) ⬇️
data/transactions/verify/txn.go 45.02% <0.00%> (-0.87%) ⬇️
network/wsPeer.go 68.61% <0.00%> (-0.56%) ⬇️
network/wsNetwork.go 62.79% <0.00%> (-0.20%) ⬇️
network/requestTracker.go 71.12% <0.00%> (+0.86%) ⬆️
ledger/acctupdates.go 66.41% <0.00%> (+0.94%) ⬆️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bd7fcc8...aea9374. Read the comment docs.

@tsachiherman tsachiherman merged commit 8c2b31a into algorand:feature/dilithium-scheme-integration Feb 9, 2022
@tsachiherman tsachiherman deleted the tsachi/fixtxnMerkleToRawregression branch February 9, 2022 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants