On Wednesday, 29 December 2021 at 16:51:47 UTC, rempas wrote:
> On Wednesday, 29 December 2021 at 16:27:22 UTC, max haughton wrote:
> Inlining + constant propagation. Fancier iterations on those exist too but 90% of the speedup will come from those since for it to matter they likely would've been used in first place.
Sounds like black magic? So If I write this:
int add(int num, int num2) { return num1 + num2; }
void main() {
int number = add(10, 20);
}
The parameters are literals so will D translate this to:
int add(int num, int num2) { return num1 + num2; } // Normal one
int add_temp_func() { return 30; } // Created for the function call in main. No `add` instruction
void main() {
int number = add(10, 20); // Will actually create and call "add_temp_func"
}
Or even better, this:
int add(int num, int num2) { return num1 + num2; }
void main() {
int number = add(10, 20); // What we will type and it will get replaced with the following line
int number = 30; // So it calculates the result at compile times and doesn't even do a function call
}
Is this what D can do? This is what I'm talking about when saying been able to use values at compile time.
This is handled by the compiler backend. The simplest way it can do this kind of optimization is by "inlining" the function.
This is done by transplanting the function body into the place it's used. At this point the compiler simply sees "= 30 + 30" which it can trivially turn into "= 60" through something called constant-folding.
The compiler can create new function bodies (like the temp one you introduce above) but this is a much more niche optimization. They favour inlining much more aggressively.
I'm tempted to do a YouTube video of a D program being compiled all the way down the machine code, to show what the compiler does for you.