Just bring this topic a again.  Would it be possible to get Nedalloc either into Tango or Phobos?  It would make sense for D to have the fastest allocator.  It would be a very easy upgrade to D's speed which is one of D's marketing points.  Nedalloc was already ported by someone.

http://nedprod.com/programs/portable/nedmalloc/index.html

-Joel

"janderson" <askme@me.com> wrote in message news:fvif08$1f4v$1@digitalmars.com...
> Just bring this topic a again.  Would it be possible to get Nedalloc either into Tango or Phobos?  It would make sense for D to have the fastest allocator.  It would be a very easy upgrade to D's speed which is one of D's marketing points.  Nedalloc was already ported by someone.
>
> http://nedprod.com/programs/portable/nedmalloc/index.html
>
> -Joel

I think the problem here is that people like you and I that care about the manual allocators are in the minority.  Probably the vast majority of D programmers don't use manual allocation at all, so the motivation to incorporate a faster manual allocator is small, even if it is trivial to do so.  IMO, a big reason that so few D programmers use manual allocation is that not many programmers that care about performance are programming in D. This is because D is slow for many tasks for two primary reasons: slow GC and a poor compiler optimization.  (Fortunately, manual allocation can be used instead of GC.)  While optimizing the GC and the compiler are big tasks, incorporating nedmalloc is trivial, and represents a very large speedup for applications that use manual allocation.

-Craig 

Craig Black:
> I think the problem here is that people like you and I that care about the manual allocators are in the minority.  Probably the vast majority of D programmers don't use manual allocation at all, so the motivation to incorporate a faster manual allocator is small,

In most of my code the usual speed of D automatic allocation is enough. But once in while I enjoy the C heap and the higher speed/flexibility is allows me, and in those situations I'd like a good allocator. (But from few tests I have seen that the GC malloc isn't that much slower than dmalloc... maybe I'll need more benchmarks).

Bye,
bearophile

Craig Black wrote:
> "janderson" <askme@me.com> wrote in message news:fvif08$1f4v$1@digitalmars.com...
>> Just bring this topic a again.  Would it be possible to get Nedalloc either into Tango or Phobos?  It would make sense for D to have the fastest allocator.  It would be a very easy upgrade to D's speed which is one of D's marketing points.  Nedalloc was already ported by someone.
>>
>> http://nedprod.com/programs/portable/nedmalloc/index.html
>>
>> -Joel
> 
> I think the problem here is that people like you and I that care about the manual allocators are in the minority.  Probably the vast majority of D programmers don't use manual allocation at all, so the motivation to incorporate a faster manual allocator is small, even if it is trivial to do so.  IMO, a big reason that so few D programmers use manual allocation is that not many programmers that care about performance are programming in D. This is because D is slow for many tasks for two primary reasons: slow GC and a poor compiler optimization.  (Fortunately, manual allocation can be used instead of GC.)  While optimizing the GC and the compiler are big tasks, incorporating nedmalloc is trivial, and represents a very large speedup for applications that use manual allocation.
> 
> -Craig

Some good points. Its probably possible to implement nedmalloc as the backend for the GC.  ie just handle the malloc and free parts at let the GC handle traversal and dirty block determination.  Although that would take some work.

-Joel