D component programming is a joke (Was: Re: Component programming)

bearophile bearophileHUGS at lycos.com
Wed Jul 31 15:23:52 PDT 2013


Justin Whear:

> If anything, component programming is just functional 
> programming + templates and some nice syntactic sugar.
> And a healthy dose of pure awesome.

What D calls "component programming" is very nice and good, but 
in D it's almost a joke.

Currently this code inlines nothing (the allocations, the 
difference and the product):


import std.numeric: dotProduct;
int main() {
     enum N = 50;
     auto a = new int[N];
     auto b = new int[N];
     auto c = new int[N];
     c[] = a[] - b[];
     int result = dotProduct(c, c);
     return result;
}


If you write it in component-style (using doubles here):


import std.math;
import std.algorithm, std.range;

int main() {
     enum N = 50;
     alias T = double;
     auto a = new T[N];
     auto b = new T[N];

     return cast(int)zip(a, b)
            .map!(p => (p[0] - p[1]) ^^ 2)
            .reduce!q{a + b};
}


The situation gets much worse, you see many functions in the 
binary, that even LDC2 often not able to inline. The GHC Haskell 
compiler turns similar "components" code in efficient SIMD asm 
(that uses packed doubles, like double2), it inlines everything, 
merges the loops, produces a small amount of asm output, and 
there is no "c" intermediate array. In GHC "component 
programming" is mature (and Intel is developing an Haskell 
compiler that is even more optimizing), while in D/dmd/Phobos 
this stuff is just started. GHC has twenty+ years of head start 
on this and it shows.

The situation should be improved for D/dmd/Phobos, otherwise such 
D component programming remains partially a dream, or a toy.

Bye,
bearophile


More information about the Digitalmars-d mailing list