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

[joe]

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
>