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

Make sigcache faster, more efficient, larger #6918

Merged
merged 3 commits into from Nov 12, 2015
Merged

Conversation

@sipa
Copy link
Member

sipa commented Oct 30, 2015

  • Changes the -maxsigcachesize argument from entries to megabytes
  • Change the default to 40 MiB (as opposed to ~10 MiB before), corresponding to over 500000 entries on 64-bit systems.
  • Store salted SHA256 hashes in the cache, rather than full entries.
  • Switch implementation from std::set to boost::unordered_set (smaller and faster)
  • Remove cache entries after having been validated inside a block, to keep the cache fresh.
@sipa sipa force-pushed the sipa:smallsigcache branch Oct 30, 2015
@morcos
Copy link
Member

morcos commented Oct 30, 2015

Concept ACK

Sent from my iPhone

On Oct 30, 2015, at 6:20 PM, Pieter Wuille notifications@github.com wrote:

Changes the -maxsigcachesize argument from entries to megabytes
Change the default to 40 MiB (as opposed to ~10 MiB before), corresponding to over 500000 entries on 64-bit systems.
Store salted SHA256 hashes in the cache, rather than full entries.
Switch implementation from std::set to boost::unordered_set (smaller and faster)
You can view, comment on, or merge this pull request online at:

#6918

Commit Summary

Make sigcache faster and more efficient
File Changes

M src/init.cpp (3)
M src/script/sigcache.cpp (80)
M src/script/sigcache.h (4)
Patch Links:

https://github.com/bitcoin/bitcoin/pull/6918.patch
https://github.com/bitcoin/bitcoin/pull/6918.diff

Reply to this email directly or view it on GitHub.

@pstratem
Copy link
Contributor

pstratem commented Oct 30, 2015

concept ACK

@laanwj laanwj added the Validation label Oct 30, 2015
@dcousens
dcousens reviewed Oct 30, 2015
View changes
src/script/sigcache.cpp Outdated

boost::unique_lock<boost::shared_mutex> lock(cs_sigcache);

while (static_cast<int64_t>(setValid.size()) > nMaxCacheSize)
while (memusage::DynamicUsage(setValid) > nMaxSize)

This comment has been minimized.

Copy link
@dcousens

dcousens Oct 30, 2015

Contributor

OOI, what is the time complexity of memusage::DynamicUsage?

This comment has been minimized.

Copy link
@sipa

sipa Oct 30, 2015

Author Member

O(1).

}

sigdata_type k(hash, vchSig, pubKey);
setValid.insert(k);
setValid.insert(entry);

This comment has been minimized.

Copy link
@dcousens

dcousens Oct 30, 2015

Contributor

nit: technically, this would mean it could briefly be greater than the allowed memory limits.

This comment has been minimized.

Copy link
@sipa

sipa Oct 30, 2015

Author Member

correct, but we're talking about ~80 bytes...

@dcousens
Copy link
Contributor

dcousens commented Oct 30, 2015

concept ACK, utACK 👍

bool
Get(const uint256 &hash, const std::vector<unsigned char>& vchSig, const CPubKey& pubKey)
Get(const uint256& entry)

This comment has been minimized.

Copy link
@dcousens

dcousens Oct 30, 2015

Contributor

Get is such a weird name, its really more like Contains?

This comment has been minimized.

Copy link
@instagibbs

instagibbs Nov 2, 2015

Member

I think it's going for a getter/setter paradigm(see: Set function below), but I think the names could indeed be improved. It's confusing to have "Set" be both the type of data structure and the primary way of updating it, imo.

{
boost::shared_lock<boost::shared_mutex> lock(cs_sigcache);
return setValid.count(entry);

This comment has been minimized.

Copy link
@dcousens

dcousens Oct 30, 2015

Contributor

std::static_cast<bool>(count) or count > 0?

@sipa sipa force-pushed the sipa:smallsigcache branch Oct 30, 2015
@sipa sipa force-pushed the sipa:smallsigcache branch to 0b9e9dc Oct 31, 2015
@sipa
Copy link
Member Author

sipa commented Oct 31, 2015

Added a commit that removes cache entries after they've been seen in a block, so the cache remains fresh.

@dcousens
Copy link
Contributor

dcousens commented Oct 31, 2015

re-ACK

class CSignatureCacheHasher
{
public:
size_t operator()(const uint256& key) const {

This comment has been minimized.

Copy link
@Diapolo

Diapolo Oct 31, 2015

Just a qustion to understand the motivation, why is here the opening bracket in the same line and below (line 48) it's on a new line?

@gmaxwell

This comment has been minimized.

Copy link

gmaxwell commented on src/script/sigcache.cpp in 830e3f3 Nov 1, 2015

"A bucket is a slot in the container's internal hash table to which elements are assigned based on their hash value.", I suspect this will not give you a uniform member of the set. Edit: Hm. no, you're using the bucket iterator below (not helpfully named.)

This comment has been minimized.

Copy link
Owner Author

sipa replied Nov 1, 2015

It certainly is not uniform given a known hash function. The effective hash function itself is (presumably) indistinguishable from random due to the 256-bit per-cache salt.

This comment has been minimized.

Copy link
Owner Author

sipa replied Nov 1, 2015

It is, however, slightly biased towards removing more recent values, as those are placed (I expect) at the beginning of the linked lists within the bucket. I can iterate to remove the last element in the bucket instead, biasing it in favor of removing older entries.

@gmaxwell

This comment has been minimized.

Copy link

gmaxwell commented on 0b9e9dc Nov 1, 2015

I don't see how this avoids the trial validation in getblocktemplate from wiping out the cache.

This comment has been minimized.

Copy link
Owner Author

sipa replied Nov 2, 2015

It doesn't.

This comment has been minimized.

Copy link

gmaxwell replied Nov 2, 2015

It needs to, otherwise this change will trash validation performance for miners.

This comment has been minimized.

Copy link
Owner Author

sipa replied Nov 2, 2015

Fixed.

@sipa
Copy link
Member Author

sipa commented Nov 2, 2015

Added a commit to not wipe the cache from TBV.

@sipa
Copy link
Member Author

sipa commented Nov 2, 2015

Currently gathering statistics about the cache size - hitrate relation.

@instagibbs
Copy link
Member

instagibbs commented Nov 2, 2015

utACK

@gmaxwell gmaxwell added this to the 0.12.0 milestone Nov 5, 2015
@sdaftuar
Copy link
Member

sdaftuar commented Nov 6, 2015

Concept ACK. However in my first attempt at benchmarking I'm not seeing any speedup with this code change (in fact block verification times seem to have gotten very, very slightly slower for some reason). Will continue to debug and try to see if my benchmarking is broken, or if there's some effect here we're missing.

@sipa
Copy link
Member Author

sipa commented Nov 11, 2015

@sdaftuar The results #6976 indicate that this improves things. Does that contradict your earlier findings?

@sdaftuar
Copy link
Member

sdaftuar commented Nov 11, 2015

Sorry forgot to update with my results. I ran longer studies comparing the old and new behavior more carefully and yes I agree this does improve things. I saw roughly a 5% speed up in processing all the October historical data using the new default cache size compared with the old implementation (running with a sig cache of approximately the same size).

ACK

@gmaxwell
Copy link
Contributor

gmaxwell commented Nov 11, 2015

ACK

@laanwj laanwj merged commit 69d373f into bitcoin:master Nov 12, 2015
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
laanwj added a commit that referenced this pull request Nov 12, 2015
69d373f Don't wipe the sigcache in TestBlockValidity (Pieter Wuille)
0b9e9dc Evict sigcache entries that are seen in a block (Pieter Wuille)
830e3f3 Make sigcache faster and more efficient (Pieter Wuille)
zkbot added a commit to zcash/zcash that referenced this pull request May 14, 2018
Bitcoin 0.12 performance improvements

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6918
- bitcoin/bitcoin#6932

Part of #2074.
zkbot added a commit to zcash/zcash that referenced this pull request May 14, 2018
Bitcoin 0.12 performance improvements

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6918
- bitcoin/bitcoin#6932

Part of #2074.
zkbot added a commit to zcash/zcash that referenced this pull request May 31, 2018
Bitcoin 0.12 performance improvements

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6918
- bitcoin/bitcoin#6932

Part of #2074.
zkbot added a commit to zcash/zcash that referenced this pull request Nov 30, 2018
Bitcoin 0.12 performance improvements

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6918
- bitcoin/bitcoin#6932

Part of #2074.
milesmanley added a commit to zelcash/zelcash that referenced this pull request Mar 5, 2019
Bitcoin 0.12 performance improvements

Cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#6918
- bitcoin/bitcoin#6932

Part of #2074.
furszy added a commit to PIVX-Project/PIVX that referenced this pull request Jun 18, 2020
6706c20 Don't wipe the sigcache in TestBlockValidity (furszy)
c69e354 Evict sigcache entries that are seen in a block (Pieter Wuille)
fb3a4a6 Make sigcache faster and more efficient (Pieter Wuille)

Pull request description:

  Coming from bitcoin#6918 .

  > Changes the -maxsigcachesize argument from entries to megabytes
  > Change the default to 40 MiB (as opposed to ~10 MiB before), corresponding to over 500000 entries on 64-bit systems.
  > Store salted SHA256 hashes in the cache, rather than full entries.
  > Switch implementation from std::set to boost::unordered_set (smaller and faster)
  > Remove cache entries after having been validated inside a block, to keep the cache fresh.

  -----

  This is the first step towards an up-to-date sigcache. Next one will be to back port the CuckooCache implementation.

ACKs for top commit:
  random-zebra:
    ACK 6706c20
  Fuzzbawls:
    utACK 6706c20

Tree-SHA512: 3b96c6a9bbbfc5c335644bf66a3605575f66ace88046411386c6a28eee37a6537bac7e25e3eebc4a2b07a82b918385ac82b68349655ab3d7e32a018ef240a908
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants
You can’t perform that action at this time.