Update readme.md

Add new benchmark figures
This commit is contained in:
Daan 2019-06-19 16:46:12 -07:00 committed by GitHub
parent d143bb05bb
commit d4167b38e1
WARNING! Although there is a key with this ID in the database it does not verify this commit! This commit is SUSPICIOUS.
GPG key ID: 4AEE18F83AFDEB23

View file

@ -264,11 +264,13 @@ with 128GB ECC memory, running Ubuntu 18.04.1 with LibC 2.27 and GCC 7.3.0.
The first benchmark set consists of programs that allocate a lot: The first benchmark set consists of programs that allocate a lot:
![bench-r5a-4xlarge-t1](doc/bench-r5a-4xlarge-t1.png) ![bench-r5a-1](doc/bench-r5a-1.svg)
![bench-r5a-2](doc/bench-r5a-2.svg)
Memory usage: Memory usage:
![bench-r5a-4xlarge-m1](doc/bench-r5a-4xlarge-m1.png) ![bench-r5a-rss-1](doc/bench-r5a-rss-1.svg)
![bench-r5a-rss-1](doc/bench-r5a-rss-2.svg)
The benchmarks above are (with N=16 in our case): The benchmarks above are (with N=16 in our case):
@ -309,9 +311,6 @@ diffrerences here when running with 16 cores in parallel.
The second benchmark tests specific aspects of the allocators and The second benchmark tests specific aspects of the allocators and
shows more extreme differences between allocators: shows more extreme differences between allocators:
![bench-r5a-4xlarge-t2](doc/bench-r5a-4xlarge-t2.png)
![bench-r5a-4xlarge-m2](doc/bench-r5a-4xlarge-m2.png)
The benchmarks in the second set are (again with N=16): The benchmarks in the second set are (again with N=16):
@ -354,6 +353,14 @@ Hoard allocator is specifically designed to avoid this false sharing and we
are not sure why it is not doing well here (although it still runs almost 5× are not sure why it is not doing well here (although it still runs almost 5×
faster than tcmalloc and jxmalloc). faster than tcmalloc and jxmalloc).
## Benchmarks on a 4-core Intel workstation
![bench-z4-1](doc/bench-z4-1.svg)
![bench-z4-2](doc/bench-z4-2.svg)
![bench-z4-rss-1](doc/bench-z4-rss-1.svg)
![bench-z4-rss-2](doc/bench-z4-rss-2.svg)
# References # References