3 ms·

> Almost all function calls are made to private functions, which exist within a binary, and are under the control of the compiler Do you understand that those

> Almost all function calls are made to private functions, which exist within a binary, and are under the control of the compiler Do you understand that those private functions are often called from multiple places in your private binary? Do you expect the compiler to emit different prologues at each call site? And even if it did, one side (callee) is fixed right? Do you expect the compiler to find the globally optimal layout across all calls? okay sure maybe that's possible if the compiler were an oracle. There's already a compiler technique for what you're describing: function inlining. The reality is that neither compilers nor compiler engineers are dumb and if you (one) has a bright idea that hasn't been implemented widely then it's highly likely someone has already considered it and there are flaws.

josephg 2y ago
> Do you understand that those private functions are often called from multiple places in your private binary? Do you expect the compiler to emit different prologues at each call site? And even if it did, one side (callee) is fixed right? Yes, I understand all that. But this optimisation is clearly possible to write. On the face of it, it sounds similar to the register allocation problem within a function, but it needs to make decisions globally. Rewriting each caller's code would be easy. The hard part would be deciding which registers to use for each emitted function's parameters. You'd have to look at all of the callers to figure out the best choices. And each choice affects all the other choices. So yes, it would be a very, very difficult optimisation to implement. Especially given how modern compilers are architected, using code units and a linker. The compiler needs to look at the functions "all at once". Inlining isn't the same. But I agree that you'd get the most benefit from this optimisation in small, hot functions. If those functions are already being inlined, all of the benefit of this optimisation would disappear. > The reality is that neither compilers nor compiler engineers are dumb and if you (one) has a bright idea that hasn't been implemented widely then it's highly likely someone has already considered it and there are flaws. Compiler engineers are smart. But they were also smart 20 years ago, and its clear in hindsight that the compilers of the time left a lot of performance on the table. I bet we're still leaving a lot of performance on the table. The question in my mind is simply, would the juice be worth the squeeze? It sounds like we agree that it would be a very difficult optimisation to implement. I think the commenter above is right that it would make programs smaller. The remaining question is, would it make them significantly faster? Would it make programs faster enough to justify the implementation complexity? I personally doubt it. Look at Rust. Rust binaries are often much bigger than their C equivalents because of bounds checks and various other runtime checks. But in my experience, the bloated binary sizes don't seem to make much of a performance difference. If anything, rust code is often (somehow) slightly faster than the equivalent C when I've measured it. (And this was true even before noalias was enabled.) But it would be a cool thing to try out. Godspeed to anyone interested in giving it a go.

josephg 2y ago

> Do you understand that those private functions are often called from multiple places in your private binary? Do you expect the compiler to emit different prologues at each call site? And even if it did, one side (callee) is fixed right? Yes, I understand all that. But this optimisation is clearly possible to write. On the face of it, it sounds similar to the register allocation problem within a function, but it needs to make decisions globally. Rewriting each caller's code would be easy. The hard part would be deciding which registers to use for each emitted function's parameters. You'd have to look at all of the callers to figure out the best choices. And each choice affects all the other choices. So yes, it would be a very, very difficult optimisation to implement. Especially given how modern compilers are architected, using code units and a linker. The compiler needs to look at the functions "all at once". Inlining isn't the same. But I agree that you'd get the most benefit from this optimisation in small, hot functions. If those functions are already being inlined, all of the benefit of this optimisation would disappear. > The reality is that neither compilers nor compiler engineers are dumb and if you (one) has a bright idea that hasn't been implemented widely then it's highly likely someone has already considered it and there are flaws. Compiler engineers are smart. But they were also smart 20 years ago, and its clear in hindsight that the compilers of the time left a lot of performance on the table. I bet we're still leaving a lot of performance on the table. The question in my mind is simply, would the juice be worth the squeeze? It sounds like we agree that it would be a very difficult optimisation to implement. I think the commenter above is right that it would make programs smaller. The remaining question is, would it make them significantly faster? Would it make programs faster enough to justify the implementation complexity? I personally doubt it. Look at Rust. Rust binaries are often much bigger than their C equivalents because of bounds checks and various other runtime checks. But in my experience, the bloated binary sizes don't seem to make much of a performance difference. If anything, rust code is often (somehow) slightly faster than the equivalent C when I've measured it. (And this was true even before noalias was enabled.) But it would be a cool thing to try out. Godspeed to anyone interested in giving it a go.