From 564c88b07c53728ec90a88d7d34d0f74d3b0bfff Mon Sep 17 00:00:00 2001 From: Matthew Parkinson Date: Thu, 28 Nov 2024 13:53:08 +0000 Subject: [PATCH] Update README.md (#698) --- docs/release/0.7/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/release/0.7/README.md b/docs/release/0.7/README.md index 17344df..123bbc4 100644 --- a/docs/release/0.7/README.md +++ b/docs/release/0.7/README.md @@ -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