== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > On 04/24/2011 08:08 PM, Iain Buclaw wrote: > > == Quote from Timon Gehr (timon.g...@gmx.ch)'s article > >> Andrei Alexandrescu wrote: > >>> 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 > > > > Is it correct that the current D GC implementation puts delete'd > > allocations into > > a freelist (or bucket) to be reused when 'new' is invoked again? > I don't know. If it does, an additional level of freelists only hurts. > >> Ok, lets stop. Custom allocators and delete should probably be removed > >> from D: > >> Some of my facts: > >> * freelist is faster if most allocation and deallocation concentrates on > >> only one > >> class. (see attachment) I think this is also the reason it increases DMDs > >> speed. > >> Token and Scope are quite obvious bottlenecks.. > >> * such bottlenecks will most of the time only be detected when development > >> is > >> almost finished. (Almost never for library code, so I don't get why STL > >> uses > >> custom allocators at all.) > >> * premature optimization is evil (see STL custom allocators) > >> * late optimization: it is easy if there are custom allocators. In C++ it > >> is even > >> trivial. Nice design. Still no clue why STL is abusing it. > >> * that form of custom allocators does not play nicely with Ds Garbage > >> collector > >> though, because it changes the semantics of 'new', ergo builtin custom > >> allocators > >> should probably indeed be removed from D. > >> * this makes this form of optimization painful in D without custom > >> allocators. > >> This is what I was instinctively scared about. Fact is: it is also painful > >> with > >> them, because you don't get the 'delete's for free as in C++. I was > >> somewhat > >> inconsiderate on this. > >> * it is possible that hinting the GC is only about twice as bad (again, see > >> attachment). > >> And some notes: > >> * the fact that you think all my points were worthless or wrong implies > >> that you > >> either did not read all of them or have not considered them yourself when > >> making > >> your decision. I think that is scary. > > > > I find it nuts that someone considers blaming/shunning language features > > just to > > mask bad runtime semantics they refuse to fix - but maybe it's just my > > ignorance > > on the subject that professes that view. > I'd appreciate if you provided more detail on that. Far as I can tell > the problem is with the feature under discussion, not some alleged > unwillingness to do work. > Andrei
I was thinking of where one implements an alternative runtime that may not necessarily interface with a GC, or has different semantics on the use of the keyword (the compiler, after all, doesn't know/care what exactly 'delete' does, it just does it's job at emitting the correct action we expect from it). Though it was late night and I perhaps didn't quite put it right anyway. Having literally slept on it though, a runtime with a good GC is one that doesn't offer a choice to 'delete' memory - so I am on your side. Though reflecting from my experience with the D2 GC (thinking from a compiler implementers POV), there isn't much I can really praise about it. Custom (de)allocators I can also see a very good point for removal too, however much a stab in the back for those who can use them in the - perhaps 'one-and-only' - case for a small amount of speed gain. Iain