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

[joe]

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