Looking for documentation of D's lower-level aspects.

[Dmitry Olshansky]

On 24.10.2011 5:57, Sean Silva wrote:
> == Quote from Dmitry Olshansky (dmitry.olsh at gmail.com)'s article
>> Less efficient is a moot point.
>> When you do iteration and other stuff you'd use range, like you'd
> use
>> iterators in c++. Range gets stack/register allocated pointers
> directly
>> to data (or close to it, that depends on container) so the only
> extra
>> cost in reference type compared to value is the first indirect
> access to
>> construct range and it's negligible.
>
> The problem isn't the speed of iteration, it's the extra heap traffic
> that is involved. I mean, for you average app this isn't going to
> matter; those are the apps that can just as easily be written in
> Java/C#. But it can be a problem for serious systems code (the kind
> that is pretty much always written in C/C++).

While we are going into very specialized territory, I must note that 
there would never be a clear winner in this battle.
E.g. null reference saves you from one nice overhead - default 
initialization / checking for it. And while it was some time ago, I do 
remember that some std vectors preallocated space on *heap* for around 
10 elements, this might not be true now, of course.

>
> For example, if you look in the LLVM source tree, you'll see that they
> bend over backwards to avoid heap allocations. For example, in some
> cases, std::vector causes too much heap traffic so they have
> SmallVector which preallocates a certain amount of storage *inside* of
> the object itself in order to avoid heap traffic if the number of
> elements doesn't exceed some predetermined amount.

Like I said before you can place class instances wherever you want to, 
in this case it's most likely a pool or free list, stack space. The only 
difference is that manual memory management is not that common in D yet 
and is fully explicit, done on case by case basis ( no class allocators 
etc. ). And "small string optimization" also is not going away, that's 
for sure.
Seeing that you are concerned by memory layouts and such, you might as 
well add some thought power to push forward allocators design. IIRC 
David Simcha is working on a version 2 proposal for it.

Even still, LLVM
> uses std::vector all over the place, and it I've never seen a
> std::vector embedded in a class by reference; it is always held by
> value precisely because then you don't do an unnecessary heap
> allocation.

And let me guess these objects are passed by... reference? And why? - 
because they are too big value types, that sort of defeats the value 
type doctrine here.

>
> I'm positive that if std::vector involved a heap allocation for the
> vector object itself, llvm would basically have rewritten a heap-less
> vector object, just like they have done in the more extreme case for
> SmallVector. But the thing is that in D, it is possible to write an
> easy-to-use vector for which it is a one-liner to switch between GC
> heap-allocated vector object, by-value vector, preallocated internal
> vector (like SmallVector), and beyond!

I note that heap/no heap is completely orthogonal matter, the default is 
however safe and reasonably fast. And IMO changing storage most of the 
time involves some work behind the scenes to get it as "one-liner".

>
> I admit, I'm very biased because my use case for D is low-level
> systems programming a la C/C++, so naturally I want a standard library
> that will not compromise on aspects that are important for the kinds
> of programs that I write. Nonetheless, if the goal is to have "good
> enough" containers, then it doesn't matter, but if the goal is to have
> "truly optimal" containers (as I think it should be; D is certainly
> powerful enough to pull it off elegantly), then it does matter.

Aye, being a C++ turncoat myself I can understand this sentiment ;)

-- 
Dmitry Olshansky