[Bf-committers] [Bf-blender-cvs] [26206] Compiling issue

[Erwin Coumans]

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 <joeedh at 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.coumans at 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 <ideasman42 at 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 <joeedh at 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 <joeedh at 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 <brecht at 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 <joeedh at 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 at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>>
>>>
>>>
>>> --
>>> - Campbell
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers