Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #4676 > unrolled thread
| Started by | Horizon68 <horizon@horizon.com> |
|---|---|
| First post | 2018-10-15 15:47 -0700 |
| Last post | 2018-10-15 16:00 -0700 |
| Articles | 2 — 1 participant |
Back to article view | Back to comp.programming.threads
About memory allocators.. Horizon68 <horizon@horizon.com> - 2018-10-15 15:47 -0700
Re: About memory allocators.. Horizon68 <horizon@horizon.com> - 2018-10-15 16:00 -0700
| From | Horizon68 <horizon@horizon.com> |
|---|---|
| Date | 2018-10-15 15:47 -0700 |
| Subject | About memory allocators.. |
| Message-ID | <pq35ds$g3t$6@dont-email.me> |
Hello... About memory allocators.. I think that mingw uses MSVCRT memory allocator that scales well and that is better than jemalloc and better than hoard, please notice it here on the following benchmark: https://github.com/andremussche/scalemm But GCC on Linux uses ptmalloc2 memory allocator.. I have just took a look at the memory allocator of the GCC C and C++ compiler on Linux that is called ptmalloc2, and on a UMA machine with four 10-core 2GHz Intel Xeon E7-4850 processors supporting two hardware threads per core, the benchmark of the following paper shows that ptmalloc2 is "scaling" decently, so i think that ptmalloc2 is a decent choice. Please read this paper to notice it: https://arxiv.org/pdf/1503.09006.pdf I have used gcc mingw to compile my scalable counting networks that use a lot the MSVCRT memory allocator, thus they are scalable, so my scalable reference counting with efficient support of weak references does too scale very well, and my efficient Threadpool engines that scale very well do scale very well too. You can download them from my website: https://sites.google.com/site/scalable68/ Thank you, Amine Moulay Ramdane.
[toc] | [next] | [standalone]
| From | Horizon68 <horizon@horizon.com> |
|---|---|
| Date | 2018-10-15 16:00 -0700 |
| Message-ID | <pq3665$g3t$19@dont-email.me> |
| In reply to | #4676 |
On 10/15/2018 3:47 PM, Horizon68 wrote: > Hello... > > About memory allocators.. > > I think that mingw uses MSVCRT memory allocator that scales well and > that is better than jemalloc and better than hoard, please notice it I correct: I mean microsoft MSVCRT memory allocator scales better than jeMalloc and better than hoard. > here on the following benchmark: > > https://github.com/andremussche/scalemm > > But GCC on Linux uses ptmalloc2 memory allocator.. > > I have just took a look at the memory allocator of the GCC C and C++ > compiler on Linux that is called ptmalloc2, and on a UMA machine with > four 10-core 2GHz Intel Xeon E7-4850 processors supporting two > hardware threads per core, the benchmark of the following > paper shows that ptmalloc2 is "scaling" decently, so i think > that ptmalloc2 is a decent choice. > > Please read this paper to notice it: > > https://arxiv.org/pdf/1503.09006.pdf > > > I have used gcc mingw to compile my scalable counting networks that > use a lot the MSVCRT memory allocator, thus they are scalable, > so my scalable reference counting with efficient support of weak > references does too scale very well, and my efficient Threadpool engines > that scale very well do scale very well too. > > You can download them from my website: > > https://sites.google.com/site/scalable68/ > > > > > Thank you, > Amine Moulay Ramdane.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.programming.threads
csiph-web