DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu

[Jonathan M Davis]

On Sunday, June 30, 2013 19:20:47 Steven Schveighoffer wrote:
> On Sun, 30 Jun 2013 15:51:32 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Sunday, June 30, 2013 21:05:41 CJS wrote:
> >> In the talk Andrei seems to mentions that D's associative arrays
> >> are lacking in performance somehow. I'm very new to D, but it's
> >> not obvious to me what the shortcoming is. I assume it's that for
> >> some reason it's hard to specialize associative arrays to specfic
> >> types to give increased performance in specfic cases, but I'm
> >> unclear why that would be difficult. Could someone please
> >> elaborate?
> > 
> > There's one implementation, and you can't swap it out, whereas different
> > use
> > cases may perform better with different implementations. On top of that,
> > the
> > current implementation is rather buggy and fragile, but that's an
> > implementation issue rather than an inherent one.
> 
> No, the main issue is the current one is runtime-only, and so simple
> function calls such as toHash and opCmp cannot be inlined.

Yeah. That's a big problem. We really need to templatize all that - though the 
current implementation is enough of a mess to make that difficult.

> You absolutely can change implementations (Walter did a few years ago from
> tree-based collision resolution to linked-list based).  What you can't do
> is switch to a fully generated AA, or change the compiler-expected API.

Okay. I didn't know that. But I think that they key issue with swapping out 
the implementation is not whether you can swap out the implementation for your 
whole program but rather being able to choose different implementations for 
different parts of your program. If you really care about your containers 
enough to worry about optimizing them for your particular use cases, then 
unless you only have one use case within your program, there's a good chance 
that you're going to want different implementations for different parts of your 
program. With library containers, that's as simple as swapping which one you 
use. With the bulit-in stuff like AAs, you can't do that. You only get one 
(even if you can make it different across programs).

Now, if you just use library types, you don't have that problem, so in the 
long run, folks who really want to optimize their containers will probably do 
that. And if they _really_ want to optimize their containers, they're probably 
writing them themselves anyway.

Regardless, while having a built-in AA simplifies the common case, it _is_ more 
limiting, and if you really care about how your AAs function, you're going to 
have to use a library solution (even if the bult-in AAs have a solid 
implementation).

- Jonathan M Davis