[Rd] Help to create bugzilla account
selivanov.dmitriy at gmail.com
Sun Aug 13 13:15:10 CEST 2017
Very interesting information about switching glibc malloc to jemalloc.
So I see action plan as following:
1. set up some benchmark (need to think about design)
2. Run it on ubuntu machine with default glibc malloc
3. Run it with malloc_trim passed with reg.finalizer()
4. Run it with jemalloc
5. Review results and if they will look better than with glibc malloc -
possibly consider switch R builds to use jemalloc on Debian, Ubuntu
Can't promise about timeline, but I will definitely try to investigate.
2017-08-13 1:36 GMT+04:00 Dirk Eddelbuettel <edd at debian.org>:
> On 12 August 2017 at 15:10, luke-tierney at uiowa.edu wrote:
> | As the Python posts poitns out, it is possible to use alternate malloc
> | implementations, either rebuilding R to use them or using LD_PRELOAD.
> | On Ubuntu for example, you can have R use jemalloc with
> | sudo apt-get install libjemalloc1
> | env LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1 R
> | This does not seem to hold onto memory to the same degree, but I don't
> | know about any other aspect of its performance.
> I don't really know anything about malloc versus jemalloc internals but I
> affirm that redis -- an in-memory database written in single-threaded C for
> high performance -- in its Debian builds has been using jemalloc for years,
> presumably by choice of the maintainer. (We are very happy users of [a
> patched] redis at work; lots of writes; very good uptime.)
> Having the ability to switch to jemalloc, we could design a test bench and
> compare what the impact is.
> Similarly, if someone cared, I could (presumably) alter the default R build
> for Debian and Ubunto to also switch to jemalloc.
> Anybody feel like doing some empirics?
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
[[alternative HTML version deleted]]
More information about the R-devel