• janderson (6/6) May 03 2008 Just bring this topic a again. Would it be possible to get Nedalloc
• Craig Black (14/20) May 04 2008 I think the problem here is that people like you and I that care about t...
• bearophile (4/8) May 04 2008 In most of my code the usual speed of D automatic allocation is enough. ...
• janderson (6/31) May 04 2008 Some good points. Its probably possible to implement nedmalloc as the

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

"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 

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

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