4 ms·

So here is my C version: https://godbolt.org/z/zTe8jocsE https://godbolt.org/z/zTe8jocsE Now tell me I need generics for this to get optimized. (Generics are

by uecker 4y ago

So here is my C version: https://godbolt.org/z/zTe8jocsE https://godbolt.org/z/zTe8jocsE Now tell me I need generics for this to get optimized. (Generics are useful for type safety, which you can add using macros in C, but this is then ugly).

SubjectToChange 4y ago
You might as well argue that (speculative) devirtualization negates the overhead of virtual functions in C++. >Now tell me I need generics for this to get optimized. Generics are explicit and reliably optimized. Implicit function pointer optimization is non-obvious and optimized unreliably.
- uecker 4y ago
  Generics can not reliably be optimized. They create specialized inline code by monomorphization (except partially in Go which is a bit smarter). Specialization and inlining can be good if it leads to simplificatons or bad when it leads to a combinatorial explosion, which is why optimizers are careful with it to avoid code bloat. Generics always create the bloat by default. If this were a good strategy, optimizers would always inline. To reliable devirtualize function pointers in C you need to use non-standard extensions. But the best strategy is not let the optimizer decide and apply this very carefully inly for the few selected cases where it matters.
  - SubjectToChange 4y ago
    > Generics can not reliably be optimized. Choose to believe this, it's your loss. The fact is that performance sensitive domains like browsers/HFT/HPC/ML/etc are almost universally written in heavily templated C++. Just look at linear algebra libraries, C can't compete. > They create specialized inline code by monomorphization Neither generics nor monomorphization imply inlining, that's purely a performance optimization. > (except partially in Go which is a bit smarter). Are you joking? Go, already an extremely bloated language, somehow managed to implement generics with runtime overhead. > Generics always create the bloat by default. Generics only generate code you would have manually written/copied otherwise. > But the best strategy is not let the optimizer decide and apply this very carefully inly for the few selected cases where it matters. Two words, heterogeneous programming.

by uecker 4y ago

SubjectToChange 4y ago

You might as well argue that (speculative) devirtualization negates the overhead of virtual functions in C++. >Now tell me I need generics for this to get optimized. Generics are explicit and reliably optimized. Implicit function pointer optimization is non-obvious and optimized unreliably.

uecker 4y ago
Generics can not reliably be optimized. They create specialized inline code by monomorphization (except partially in Go which is a bit smarter). Specialization and inlining can be good if it leads to simplificatons or bad when it leads to a combinatorial explosion, which is why optimizers are careful with it to avoid code bloat. Generics always create the bloat by default. If this were a good strategy, optimizers would always inline. To reliable devirtualize function pointers in C you need to use non-standard extensions. But the best strategy is not let the optimizer decide and apply this very carefully inly for the few selected cases where it matters.
- SubjectToChange 4y ago
  > Generics can not reliably be optimized. Choose to believe this, it's your loss. The fact is that performance sensitive domains like browsers/HFT/HPC/ML/etc are almost universally written in heavily templated C++. Just look at linear algebra libraries, C can't compete. > They create specialized inline code by monomorphization Neither generics nor monomorphization imply inlining, that's purely a performance optimization. > (except partially in Go which is a bit smarter). Are you joking? Go, already an extremely bloated language, somehow managed to implement generics with runtime overhead. > Generics always create the bloat by default. Generics only generate code you would have manually written/copied otherwise. > But the best strategy is not let the optimizer decide and apply this very carefully inly for the few selected cases where it matters. Two words, heterogeneous programming.