On 04/24/2011 01:21 PM, Timon Gehr wrote:
Andrei Alexandrescu wrote:
The point is that some naively believe "new" and "delete" are some
simple do and undo actions and as such they somehow deserve the same
level of support. In reality they have dramatically different issues and
are profoundly asymmetric.
The class-specific allocators are an exceedingly bad design carried over
from C++. They will be deprecated from D as well.
Does that imply that the feature is going away after all?
Even C++, where the features you are talking about have existed for many
years, is shunning their use. Good applications make very sparingly use
of "delete" and virtually none uses class-specific allocators.
Experience with C++ is the best proof that the delete keyword and
class-specific allocators have no place in the D programming language.
Andrei
Virtually no good application uses them? The _DMD compiler implementation_ uses
them. Classes 'Token' and 'Scope' have class-specific optimized allocators. I
don't think Walter would have done that if it did not give quite good benefits.
A class-specific freelist-based allocator in fact stands in the way of a
good general-purpose allocator. At Facebook we did extensive
measurements on a variety of applications and workloads and the best
approach was to just disable all STL class-specific allocators (by
defining GLIBCXX_FORCE_NEW) and let jemalloc take care of all
allocations, to great effect.
Today's good general-purpose allocators are as good or usually
considerably better than custom allocators. The one category of custom
allocators that is still significantly better are regions, but they have
quite specific and restricted semantics.
D
is a systems programming language after all. It is not Java or some scripting
language. I don't think D should/can get rid of class-specific allocators if
there
is no good alternative for sane uses. Even if they are not used often and should
not be used often.
C++ is not garbage collected by default. Implementing a GC root class for
example
is another legitimate use case for class-specific allocators. In D, things are
somewhat reverse, class-specific allocators would be used for manual memory
management. D should support that.
So if class-specific allocators go away, what is the alternative? Sure, it is
always possible to allocate using custom functions (for D structs, at least.)
But
then, if allocations of one struct/class turn out to be a bottleneck somewhere
late in the development, the whole code will have to be changed instead of just
the addition of some simple custom class-specific allocator. (This is even worse
when developing a library). Also, just testing the impact of a custom allocator
will be a pain for the same reason. Why is that better?
Timon
It is much better in very many ways, in particular in D. For one simple
argument, consider:
auto obj = new Widget;
Simple modularity considerations would require this operator to have
semantics independent of Widget, such that modular and generic code can
use it properly. Custom class allocators ruin all that, because they
would require the use of delete paired with new, whereas the general
operator requires no action.
Memory allocation and object construction are difficult topics,
particularly in high-performance settings. A seasoned engineer
understands that and does not naively believe that a smattering of
well-intended but very badly executed language support will make that
all easier. (Contrast that with e.g. reference counting semantics using
RAII, which relies on a much better part of the language and does offer
reasonable guarantees.)
I am sorry, you simply have no case - each and every argument you put
forth has no strength or is just wrong. We could spend time on debating
each, but I suspect that would do little toward convincing you of what
is after all a simple fact, but one with many subtle facets. It might
not a good use of our time to further engage in a diatribe on this. The
delete keyword will go, as will class-specific new and delete.
Andrei
