On Mon, Apr 3, 2017 at 4:56 PM, Craig Gallek <kraigatg...@gmail.com> wrote: > On Sun, Apr 2, 2017 at 6:18 PM, Alexey Dobriyan <adobri...@gmail.com> wrote: >> Number of sockets is limited by 16-bit, so 64-bit allocation will never >> happen. >> >> 16-bit ops are the worst code density-wise on x86_64 because of >> additional prefix (66). > So this boils down to a compiled code density vs a > readability/maintainability argument? I'm not familiar with the 16 > bit problem you're referring to, but I'd argue that using the > self-documenting u16 as an input parameter to define the range > expectations is more useful that the micro optimization that this > change may buy you in the assembly of one platform. Especially given > that this is a rare-use function.
It's not a problem as in "create trouble". 16-bit operations are the worst on x86_64: they require additional prefix, compiler often has to extend it to 32-bit to do anything useful (MOVZX = 1 cycle, 3 bytes) because of cast-everything-to-int behaviour enabled by the language.
