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 <e...@debian.org>: > > On 12 August 2017 at 15:10, luke-tier...@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. > > Interesting. > > I don't really know anything about malloc versus jemalloc internals but I > can > 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 > gently > 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? > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- Regards Dmitriy Selivanov [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
