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

test out experimental outlined hashmap design #60470

Closed
wants to merge 2 commits into from

Conversation

Gankra
Copy link
Contributor

@Gankra Gankra commented May 2, 2019

sorry, need to do this to get try builds for rust-lang/hashbrown#76

Can someone kick off whatever the perf/profiling/benchmark version of try is now? Want to see how this change affects rustc's perf and memory usage.

(Might also need to do this a few times to test out different versions of the patch)

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 2, 2019
@Centril
Copy link
Contributor

Centril commented May 2, 2019

@bors try

@bors
Copy link
Contributor

bors commented May 2, 2019

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout thin-hashbrown (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self thin-hashbrown --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:2de27259:start=1556798934876314034,finish=1556799021839251297,duration=86962937263
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:01:11] 
######################################################################## 100.0%
[00:01:11] extracting /checkout/obj/build/cache/2019-04-11/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
[00:01:11]     Updating crates.io index
[00:01:27]     Updating git repository `https://github.com/gankro/hashbrown`
[00:01:29]   Downloaded cc v1.0.35
[00:01:29]   Downloaded filetime v0.2.4
[00:01:29]   Downloaded num_cpus v1.8.0
[00:01:29]   Downloaded cmake v0.1.38
---
tidy check
[00:03:21] * 570 error codes
[00:03:21] * highest error code: E0725
[00:03:22] * 254 features
[00:03:22] invalid source: "git+https://github.com/gankro/hashbrown?branch=singleton#99e5ba92e83a6ad40cbc5c9d79dd18a07592ebf1"
[00:03:22] some tidy checks failed
[00:03:22] 
[00:03:22] 
[00:03:22] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:03:22] 
[00:03:22] 
[00:03:22] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:22] Build completed unsuccessfully in 0:00:45
[00:03:22] Build completed unsuccessfully in 0:00:45
[00:03:22] Makefile:67: recipe for target 'tidy' failed
[00:03:22] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:035ddb88
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu May  2 12:13:54 UTC 2019
---
travis_time:end:0a9910d0:start=1556799234853743379,finish=1556799234858222830,duration=4479451
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0cd53e8c
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0c5cc4c0
travis_time:start:0c5cc4c0
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:052569ba
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@Gankra Gankra force-pushed the thin-hashbrown branch from 021b873 to cdf5aa7 Compare May 2, 2019 12:31
@Gankra
Copy link
Contributor Author

Gankra commented May 2, 2019

uh... is testing out git deps not allowed?

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:05dca1d5:start=1556800370232319706,finish=1556800372251075153,duration=2018755447
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
#######################################################                   76.7%
######################################################################## 100.0%
[00:01:58] extracting /checkout/obj/build/cache/2019-04-11/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
[00:01:58]     Updating crates.io index
[00:02:15]     Updating git repository `https://github.com/gankro/hashbrown`
[00:02:17]   Downloaded cc v1.0.35
[00:02:17]   Downloaded num_cpus v1.8.0
[00:02:18]   Downloaded lazy_static v0.2.11
[00:02:18]   Downloaded cmake v0.1.38
---
tidy check
[00:04:10] * 570 error codes
[00:04:10] * highest error code: E0725
[00:04:11] * 254 features
[00:04:11] invalid source: "git+https://github.com/gankro/hashbrown?branch=singleton#99e5ba92e83a6ad40cbc5c9d79dd18a07592ebf1"
[00:04:11] some tidy checks failed
[00:04:11] 
[00:04:11] 
[00:04:11] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:11] 
[00:04:11] 
[00:04:11] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:11] Build completed unsuccessfully in 0:00:44
[00:04:11] Build completed unsuccessfully in 0:00:44
[00:04:11] make: *** [tidy] Error 1
[00:04:11] Makefile:67: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:020df69c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu May  2 12:37:14 UTC 2019
---
travis_time:end:157a3bf8:start=1556800635685996956,finish=1556800635691102696,duration=5105740
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:07a24d72
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:066bcd73
travis_time:start:066bcd73
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:2703ee32
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@alexcrichton
Copy link
Member

You may need to either update or disable tidy, but I suspect tidy doesn't run on the try builders

@bors: try

@bors
Copy link
Contributor

bors commented May 2, 2019

⌛ Trying commit cdf5aa71b5599e38673b417cad27ff1dac022a7f with merge a9744339ba99b73c26c8ba5d512f11b4807a22e8...

@bors
Copy link
Contributor

bors commented May 2, 2019

☀️ Try build successful - checks-travis
Build commit: a9744339ba99b73c26c8ba5d512f11b4807a22e8

@Gankra
Copy link
Contributor Author

Gankra commented May 2, 2019

this appears to not have done any benchmarking..?

@Centril
Copy link
Contributor

Centril commented May 2, 2019

@rust-timer build a9744339ba99b73c26c8ba5d512f11b4807a22e8

@rust-timer
Copy link
Collaborator

Success: Queued a9744339ba99b73c26c8ba5d512f11b4807a22e8 with parent 758dc9a, comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit a9744339ba99b73c26c8ba5d512f11b4807a22e8

@Gankra
Copy link
Contributor Author

Gankra commented May 2, 2019

Ok, cool, here's the next commit to run on rust-timer.

@Centril
Copy link
Contributor

Centril commented May 2, 2019

@bors try

@bors
Copy link
Contributor

bors commented May 2, 2019

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout thin-hashbrown (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self thin-hashbrown --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@Gankra Gankra force-pushed the thin-hashbrown branch from a40162a to a5fd9ef Compare May 2, 2019 22:27
@Gankra
Copy link
Contributor Author

Gankra commented May 2, 2019

rebased

@Centril
Copy link
Contributor

Centril commented May 2, 2019

@bors try

@bors
Copy link
Contributor

bors commented May 2, 2019

⌛ Trying commit a5fd9ef with merge 65b5892de48860c42b97e6091b09e60ae160b1a8...

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:021b2ec0:start=1556836126801678746,finish=1556836127708196578,duration=906517832
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
    100% |████████████████████████████████| 51kB 21.7MB/s 
Collecting colorama<=0.3.9,>=0.2.5 (from awscli)
  Downloading https://files.pythonhosted.org/packages/db/c8/7dcf9dbcb22429512708fe3a547f8b6101c0d02137acbd892505aee57adf/colorama-0.3.9-py2.py3-none-any.whl
Collecting botocore==1.12.141 (from awscli)
  Downloading https://files.pythonhosted.org/packages/af/72/bb5092d4f8a7b6c9a4508b784cdfed6d856e2a202383c345a66da71cc612/botocore-1.12.141-py2.py3-none-any.whl (5.4MB)
    0% |▏                               | 20kB 26.8MB/s eta 0:00:01
    0% |▏                               | 30kB 34.5MB/s eta 0:00:01
    0% |▎                               | 40kB 39.5MB/s eta 0:00:01
    0% |▎                               | 51kB 41.3MB/s eta 0:00:01
---
[00:01:47] 
######################################################################## 100.0%
[00:01:47] extracting /checkout/obj/build/cache/2019-04-11/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
[00:01:48]     Updating crates.io index
[00:02:04]     Updating git repository `https://github.com/gankro/hashbrown`
[00:02:06]   Downloaded filetime v0.2.4
[00:02:06]   Downloaded cc v1.0.35
[00:02:06]   Downloaded cmake v0.1.38
[00:02:06]   Downloaded toml v0.4.10
---
tidy check
[00:03:57] * 570 error codes
[00:03:57] * highest error code: E0725
[00:03:57] * 254 features
[00:03:58] invalid source: "git+https://github.com/gankro/hashbrown?branch=singleton#09ed47028875a10cb6ad9ffeceb61cc4a5c9d690"
[00:03:58] some tidy checks failed
[00:03:58] 
[00:03:58] 
[00:03:58] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:03:58] 
[00:03:58] 
[00:03:58] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:58] Build completed unsuccessfully in 0:00:45
[00:03:58] Build completed unsuccessfully in 0:00:45
[00:03:58] make: *** [tidy] Error 1
[00:03:58] Makefile:67: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0703a43c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Thu May  2 22:32:57 UTC 2019
---
travis_time:end:0c3d17c4:start=1556836378619553784,finish=1556836378624690117,duration=5136333
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:010d59ac
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:2258f832
travis_time:start:2258f832
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:19f08d70
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@Centril
Copy link
Contributor

Centril commented May 2, 2019

@bors delegate+ for trying :)

@bors
Copy link
Contributor

bors commented May 2, 2019

✌️ @gankro can now approve this pull request

@bors
Copy link
Contributor

bors commented May 3, 2019

☀️ Try build successful - checks-travis
Build commit: 65b5892de48860c42b97e6091b09e60ae160b1a8

@Gankra
Copy link
Contributor Author

Gankra commented May 3, 2019

@rust-timer build 65b5892

@rust-timer
Copy link
Collaborator

Insufficient permissions to issue commands to rust-timer.

@Gankra
Copy link
Contributor Author

Gankra commented May 3, 2019

r i p

@alexcrichton
Copy link
Member

@rust-timer build 65b5892de48860c42b97e6091b09e60ae160b1a8

@rust-timer
Copy link
Collaborator

Success: Queued 65b5892de48860c42b97e6091b09e60ae160b1a8 with parent 08bfe16, comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit 65b5892de48860c42b97e6091b09e60ae160b1a8

@Gankra
Copy link
Contributor Author

Gankra commented May 3, 2019

Summary of situation: the servo devs noticed that the size_of HashMap had ballooned with the landing of hashbrown. Ultimately this was deemed an acceptable tradeoff given that hashbrown is significantly faster, and significantly reduces overall memory usage.

Still, this piqued my interest, and I pursued a change to hashbrown's implementation which moved most of the fields from the body of the HashMap struct to a header at the start of hashbrown's allocation (with the exception of the often-zero-sized BuildHasher).

The theoretical advantages of this are:

  • cheaper to move around HashMaps (its just a pointer!)
  • reduced memory footprint of things which need to reserve space for maybe-hashmaps, like Option<HashMap>::None and SomeCollection<HashMap>
  • things which contain rarely-used HashMaps are more cache-friendly (less junk to walk over)
  • reduced absolute memory usage for HashMap::new(), as the inline fields were moved to the empty singleton (which already existed, but was previously just for the ctrl array)

The theoretical disadvantages of this are:

  • Potentially more cache misses accessing a cold map, needing to now access the pointer to the header, the header, and then finally the ctrl array.
  • Potentially harder for llvm to understand/optimize outlined fields
  • A few more "am I the singleton?" checks in the implementation (mostly on slow paths like resizing)

Ok, so, here's the results I have for two different implementation strategies (based on whether the hashmap's pointer points at the header or the ctrl array):

header:

ctrl:

My non-expert opinion of the rust-timer results indicates this is in the noise. While the pure hashmap benchmarks indicate this is slightly worse. So absent any indication that this is really useful, it seems like this approach should be abandoned.

Would appreciate feedback from people who are more familiar with rust-timer results and performance tuning, though.

CC @rust-lang/wg-compiler-performance @Amanieu

@eddyb
Copy link
Member

eddyb commented May 3, 2019

Now if only we were collecting more perf counters, like cache misses, this would be more interesting.

@Mark-Simulacrum
Copy link
Member

Thanks! Visiting this from triage -- I'm going to close this PR in favor of rust-lang/hashbrown#76 where further discussion I think should happen (since that's where the underlying work needs to happen) and there's not much activity on this PR; I suspect the conclusion that this isn't necessarily worth the implementation complexity may be accurate. If someone's interested, I would suggest running some benchmarks under cachegrind to get cache statistics (or use perf stat -ddd, possibly).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants