Cheri-research/snmalloc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update README.md (#698)

Browse Source
This commit is contained in:
Matthew Parkinson
2024-11-28 13:53:08 +00:00
committed by GitHub
parent 4efc0e7d02
commit 564c88b07c
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/release/0.7/README.md
View File

@@ -40,7 +40,7 @@ To address this, we analysed what was doing while holding the lock.
We found that we were doing a several things that were causing more time to be spent inside the lock than was necessary.
Overall, we improve the start-up time of `snmalloc` in high thread scenarios as follows:
We have a particularly tough benchmark for testing [startup time](../src/test/perf/startup/startup.cc).
We have a particularly tough benchmark for testing [startup time](../../../src/test/perf/startup/startup.cc).
We used a machine with 72 hardware threads.
The benchmark causes all the threads to synchronise on starting their first allocation.
This means all 72 threads are contending on the lock at the same time to get their allocator initialised.
@@ -121,7 +121,7 @@ It does not increase the size of the pagemap.
We have built a simple example inspired by Google's `miracle_ptr`,
that uses this feature to provide the reference counting for all allocations, but out-of-band.
See [miracle_ptr](../src/test/func/miracle_ptr/miracle_ptr.cc) for our current experiment.
See [miracle_ptr](../../../src/test/func/miracle_ptr/miracle_ptr.cc) for our current experiment.
We are still experimenting with this feature, and would love to hear your feedback.
## Conclusion