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
