http://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtrace-was-used/
On Sat, Jan 23, 2010 at 5:56 PM, Erwin Coumans <erwin.coum...@gmail.com> wrote: > Dough Lea's malloc was updated a few months ago. I think Unreal Engine > 3 is using it too. > > Do you have a URL of this allocator benchmark? > > Thanks, > Erwin > > Sent from my iPhone > > On Jan 23, 2010, at 15:16, joe <joe...@gmail.com> wrote: > >> jcmalloc seems the best, at least from the profiling results the >> firefox people got with it. Doug lea's malloc is a bit dated, iirc of >> the three or four good ones, it was the worst? can't remember >> precisely, I could easily be wrong. >> >> Joe >> >> On Sat, Jan 23, 2010 at 1:06 PM, Erwin Coumans <erwin.coum...@gmail.com >> > wrote: >>> Have you tried the very fast and popular Doug Lea Malloc, or >>> dlmalloc? >>> >>> ftp://g.oswego.edu/pub/misc/ >>> http://g.oswego.edu/dl/html/malloc.html >>> >>> Cheers, >>> Erwin >>> >>> >>> On 23 January 2010 10:49, Campbell Barton <ideasma...@gmail.com> >>> wrote: >>>> did you try one of the malloc replacements? - should be able to do >>>> it >>>> without rebuilding blender even. >>>> I tried 3 popular malloc replacements (benchmarked with the game >>>> engine) >>>> jemalloc, nedmalloc and hoard IIRC None made much of a difference >>>> for >>>> me though perhaps the BGE isnt a good test case, was also trying on >>>> linux with an optimized build. >>>> >>>> >>>> On Sat, Jan 23, 2010 at 5:21 PM, joe <joe...@gmail.com> wrote: >>>>> This is also something I've had to deal with in the bmesh branch, >>>>> and >>>>> the code I wrote there should never see the light of day in trunk >>>>> (which motivates me to tackle this now :) ). It's really quite >>>>> horrible what I wrote to deal with vgroups performance problems. >>>>> >>>>> Joe >>>>> >>>>> On Sat, Jan 23, 2010 at 8:20 AM, joe <joe...@gmail.com> wrote: >>>>>> The purpose was simple experimentation, since we need to do >>>>>> *something* and at the time I didn't think people would go for >>>>>> using >>>>>> jcmalloc. Vgroups really are a bad source of performance loss, >>>>>> mostly >>>>>> in debug builds (which we need to be usable but aren't in some >>>>>> cases). >>>>>> I was hoping to elicit ideas from other people, and go from >>>>>> there. >>>>>> Anyway, it was silly of me to ignore the possibility of using >>>>>> jcmalloc, which we can probably drop in as a replacement for >>>>>> malloc >>>>>> within guardedalloc itself (and even have compile time options >>>>>> to have >>>>>> guardedalloc go straight through to jcmalloc). >>>>>> >>>>>> Joe >>>>>> >>>>>> On Sat, Jan 23, 2010 at 6:53 AM, Brecht Van Lommel <bre...@blender.org >>>>>> > wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> Right, I replied to the wrong mail, I was talking about the >>>>>>> guardedalloc changes. I understand this is experimental, but I >>>>>>> don't >>>>>>> think some more experimentation will be prove this to be the >>>>>>> right >>>>>>> thing to do. It may well lead to a speedup in simple test >>>>>>> cases, but a >>>>>>> simple use of pooling can lead to much wasted memory and make >>>>>>> problems >>>>>>> worse when running Blender for a while. So it is not clear to >>>>>>> me what >>>>>>> the purpose is here, if this is the start of writing an advanced >>>>>>> memory allocator then I don't think we should try to do that >>>>>>> ourselves, and if not then I don't think this can be good >>>>>>> enough to >>>>>>> put in a release. >>>>>>> >>>>>>> Brecht. >>>>>>> >>>>>>> On Sat, Jan 23, 2010 at 3:19 PM, joe <joe...@gmail.com> wrote: >>>>>>>> What are you talking about specifically? It helps with ghash, >>>>>>>> because >>>>>>>> each bucket node was being allocated individually, causing a >>>>>>>> significant speed problem. This particular solution was very >>>>>>>> appropriate; it's why we have the mempool library in the first >>>>>>>> place. >>>>>>>> >>>>>>>> Now, the experimental code I committed (#ifdef'd out) to >>>>>>>> guardedalloc >>>>>>>> is different (and was a >>>>>>>> different commit even). This particular commit has nothing to >>>>>>>> do with >>>>>>>> that. On that topic, OSX has (or had, anyway) a reputation >>>>>>>> for having >>>>>>>> a system allocator almost as slow as windows; linux is the >>>>>>>> only OS as >>>>>>>> far as I know (other then the BSDs I guess) that doesn't >>>>>>>> suffer from >>>>>>>> this. So it's hardly simply a windows issue. >>>>>>>> >>>>>>>> The overhead we get from guardedalloc isn't all that bad, >>>>>>>> really. I >>>>>>>> wasn't talking about that in the slightest. What I was >>>>>>>> talking about >>>>>>>> was the significant performance loss we get from overusing the >>>>>>>> system >>>>>>>> allocator, which has caused significant problems for me and >>>>>>>> others. I >>>>>>>> committed the code #ifdef'd out, so people who need it can >>>>>>>> play around >>>>>>>> with it but not cause problems for others. There's a reason >>>>>>>> it's >>>>>>>> *experimental*. >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Bf-committers mailing list >>>>>>> Bf-committers@blender.org >>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Bf-committers mailing list >>>>> Bf-committers@blender.org >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>> >>>> >>>> >>>> >>>> -- >>>> - Campbell >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> _______________________________________________ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers