3 ms·

>But given that relatively few super-hot loops of this kind are in typical programs, it is worth it. In C programs these kind of super-hot loops are quite comm

>But given that relatively few super-hot loops of this kind are in typical programs, it is worth it. In C programs these kind of super-hot loops are quite common, because if someone didn't have many such loops they probably wouldn't need to write in C/C++. And if C had the same overhead as Java in these cases, then people who needed to squeeze out every drop of performance would use a different language.

titzer 3y ago
> these kind of super-hot loops are quite common People say this, then they write microbenchmarks. Then compilers optimize the heck out of these microbenchmarks (and numerical kernels). Rinse and repeat for several decades, and every dirty trick that you can think of gets blessed under the guise of UB. When in reality, real programs do not spend all their time in one (or even a handful) of super-hot loops. C was designed to let compilers have a field day so that 1980s supercomputers could get 5% more FP performance, by hook or by crook. This kind of dangerous optimizations do not make much different for the vast majority of application code, the majority of which spends its time chasing pointers and chugging through lots of abstraction layers.
- haberman 3y ago
  > When in reality, real programs do not spend all their time in one (or even a handful) of super-hot loops. This paper from 2015 finds that a large amount of CPU in Google data centers is spent in a relatively small number of core components, known as the "datacenter tax": https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44271.pdf https://static.googleusercontent.com/media/research.google.c... > [We] identify common building blocks in the lower levels of the software stack. > This “datacenter tax” can comprise nearly 30% of cycles > across jobs running in the fleet, which makes its constituents > prime candidates for hardware specialization in future server > systems-on-chips. Some of the components they identify are memmove() (definitely a loop), protocol buffers (proto parsing is a loop), and compression/decompression (a loop).
- TapamN 3y ago
  >C was designed to let compilers have a field day so that 1980s supercomputers could get 5% more FP performance, by hook or by crook. C was designed to help create Unix. It just happened to turn out to be something that could be compiled into more efficient code than most other languages at the time, without being overly difficult to work with. From what I understand, 80s supercomputers were more likely to run Fortran. Fortran has fewer problems with pointer aliasing than C, so a Fortran compiler could generate better code than a C compiler for the type of code they would be running.

titzer 3y ago

> these kind of super-hot loops are quite common People say this, then they write microbenchmarks. Then compilers optimize the heck out of these microbenchmarks (and numerical kernels). Rinse and repeat for several decades, and every dirty trick that you can think of gets blessed under the guise of UB. When in reality, real programs do not spend all their time in one (or even a handful) of super-hot loops. C was designed to let compilers have a field day so that 1980s supercomputers could get 5% more FP performance, by hook or by crook. This kind of dangerous optimizations do not make much different for the vast majority of application code, the majority of which spends its time chasing pointers and chugging through lots of abstraction layers.

haberman 3y ago
> When in reality, real programs do not spend all their time in one (or even a handful) of super-hot loops. This paper from 2015 finds that a large amount of CPU in Google data centers is spent in a relatively small number of core components, known as the "datacenter tax": https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44271.pdf https://static.googleusercontent.com/media/research.google.c... > [We] identify common building blocks in the lower levels of the software stack. > This “datacenter tax” can comprise nearly 30% of cycles > across jobs running in the fleet, which makes its constituents > prime candidates for hardware specialization in future server > systems-on-chips. Some of the components they identify are memmove() (definitely a loop), protocol buffers (proto parsing is a loop), and compression/decompression (a loop).
TapamN 3y ago
>C was designed to let compilers have a field day so that 1980s supercomputers could get 5% more FP performance, by hook or by crook. C was designed to help create Unix. It just happened to turn out to be something that could be compiled into more efficient code than most other languages at the time, without being overly difficult to work with. From what I understand, 80s supercomputers were more likely to run Fortran. Fortran has fewer problems with pointer aliasing than C, so a Fortran compiler could generate better code than a C compiler for the type of code they would be running.