D Language 2.0

[Leandro Lucarella]

Craig Black, el 19 de enero a las 17:27 me escribiste:
> 
> "Leandro Lucarella" <llucax at gmail.com> wrote in message
> news:20100119173057.GD14794 at llucax.com.ar...
> >Walter Bright, el 18 de enero a las 14:31 me escribiste:
> >>> More seriously, I don't expect D to see much usage in the embedded
> >>>market unless it becomes a huge success on the PC first (if then).
> >>>But nothing you can do on the technical front will change that: it's
> >>>mostly due to prejudice and preconceptions, not an actual
> >>>cost-benefit evaluation of the language.
> >>
> >>Yeah, I know, I run into the pseudo-problem all the time of D using
> >>garbage collection. I point out that you can call/use malloc in D as
> >>easily as you can in C++, but it makes no difference. They're
> >>convinced that gc will send their app to hell. <g>
> >>
> >>I fault Java, C#, Python, etc., for some of this anti-gc silliness
> >>because those languages make it really hard to use malloc. They just
> >>don't believe that malloc is trivial to use in D.
> >
> >Well, I think it's a little D's fault too, because several language
> >features use the GC (and all the stdlib as well). It's trivial to use
> >malloc in D, but, even when it's possible, it's not so easy to completely
> >avoid the GC. You just have to be too careful, and I think the features
> >that use the GC are not very well documented (same for Phobos).
> >
> >So I think the GC-will-get-in-the-way fear in D is not totally
> >unjustified, even when malloc is trivial to use.
> 
> I would have to agree and this is one of my causes for hesisation in
> adopting D.  The code I write requires the highest performance
> possible.  I am concerned that when I port it over to D, I will have
> to avoid using a lot of D features that use the GC (built-in arrays,
> closures, standard library features, etc.)  in order to get the best
> possible performance.  D does not adhere to the C++ zero-overhead
> principle, and I see this as a risk.  So if/when I end up porting my
> code to D I may evolve my own dialect of D that uses only the subset
> of features that tend to provide the best performance.

One thing that can help a lot here is an option for the compiler to avoid
compiling stuff that implicitly call the GC (LDC has an option to avoid
runtime calls altogether, -noruntime, but maybe that's too extreme). That
just helps to avoiding hidden GC usage, you still have to use your own
dialect and you probably have to avoid Phobos too.

> I don't know if the GC will send my code to hell, but if the
> performance drops by more than 20% by porting it from C++ to D, then
> I would be disappointed.  The GC is a huge concern for me, and it's
> not an unreasonable concern.  I got about a 15% performance
> improvement by switching from the system allocator to nedmalloc, so
> my code is very sensitive to heap allocation performance.  I use
> dynamic arrays quite a lot, and if I switched all of these to use
> D's built-in GC-based arrays, I think I would see a tremendous
> performance drop.

Allocation could be very slow, specially in MT programs because of the GC
lock. But you can preallocate or use other tricks like the ones that David
mentioned.

But my point still stands, even when possible, is far from trivial to code
in D avoiding the GC.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
RENUNCIO PARA IR A REZARLE A SAN CAYETANO
	-- Crónica TV