Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #4676 > unrolled thread

About memory allocators..

Started byHorizon68 <horizon@horizon.com>
First post2018-10-15 15:47 -0700
Last post2018-10-15 16:00 -0700
Articles 2 — 1 participant

Back to article view | Back to comp.programming.threads


Contents

  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

#4676 — About memory allocators..

FromHorizon68 <horizon@horizon.com>
Date2018-10-15 15:47 -0700
SubjectAbout 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]


#4677

FromHorizon68 <horizon@horizon.com>
Date2018-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