www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Nedmalloc

reply janderson <askme me.com> writes:
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
May 03 2008
parent reply "Craig Black" <craigblack2 cox.net> writes:
"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
May 04 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
May 04 2008
prev sibling parent janderson <askme me.com> writes:
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
May 04 2008