3 ms·

Here is an IRC log of a discussion[1] I had about this topic in the #musl IRC channel. The folks in this channel are the developers behind musl-libc[2]. The con

Here is an IRC log of a discussion[1] I had about this topic in the #musl IRC channel. The folks in this channel are the developers behind musl-libc[2]. The conclusion drawn is that some poor design decisions were made that make the fast types not worth using. [1]: https://gist.github.com/andrewrk/ac66b24a0a202d87cea7 https://gist.github.com/andrewrk/ac66b24a0a202d87cea7 [2]: http://www.musl-libc.org/ http://www.musl-libc.org/

DSMan195276 11y ago
Thanks for that, that's pretty interesting to read about. Admittedly, I'm not sure I've ever actually used a int_fastN_t type in my code - I just kinda assumed they served their purpose. Reading that log I can see the obvious problems with those types which I never realized since I never really looked into them that much. int_least16_t seems like a perfectly fine substitute though, I don't really know why int_leastN_t and int_fastN_t would be different in the first place. That said, there's really no way to correctly pick the "perfect" integer size for every platform - There's just too many variables. IMO I much prefer to just use 'int' when I know the values are going to be small - smaller then a 16-bit value - and I don't care about the actual width. But obviously it's a hot topic for some - As long as you follow the standard in regards to it's size then it doesn't really matter what integer value you choose to use. I prefer saving the fixed-width integer types for situations when I know I need such a size.
ealloc 11y ago
I'm not conviced. Maybe it really is that the wider type is faster, and int_fast16_t should be 64 bits. I just tried it out on a 64 bit system. The program is just a for loop. If the loop variable is a int_fast16_t the loop increment step compiles to addq $1, -16(%rbp) If it is int16_t it compiles to movzwl -4(%rbp), %eax addl $1, %eax movw %ax, -4(%rbp) The 64 bit width version is shorter, and so conceivably faster. Performance seems the same though, but that's probably because this program isn't a proper benchmark.
- Narishma 11y ago
  > The 64 bit width version is shorter, and so conceivably faster. Without profiling there's no way to tell on modern processors.
  - nwmcsween 11y ago
    Seriously, you think movzwl -4(%rbp), %eax addl $1, %eax movw %ax, -4(%rbp) will be on par with addq $1, -16(%rbp)
    - DSMan195276 11y ago
      Modern processors are pretty crazy beasts. He right in saying it's impossible to say for sure without some hard numbers or profiling. Comparatively, while one is three instructions and the other is one, that single instruction is still doing everything the other three are doing. The only reason they aren't both one instruction seems to be that `addw` must not being a thing (Why, I don't know). Since the I/O done by both will be nearly identical, and the addition's should be very comparable in speed, it's not crazy to say they should perform basically the same. If you compiled with -O2 I bet you'd see almost identical code, since it would probably remove the memory access.

DSMan195276 11y ago

Thanks for that, that's pretty interesting to read about. Admittedly, I'm not sure I've ever actually used a int_fastN_t type in my code - I just kinda assumed they served their purpose. Reading that log I can see the obvious problems with those types which I never realized since I never really looked into them that much. int_least16_t seems like a perfectly fine substitute though, I don't really know why int_leastN_t and int_fastN_t would be different in the first place. That said, there's really no way to correctly pick the "perfect" integer size for every platform - There's just too many variables. IMO I much prefer to just use 'int' when I know the values are going to be small - smaller then a 16-bit value - and I don't care about the actual width. But obviously it's a hot topic for some - As long as you follow the standard in regards to it's size then it doesn't really matter what integer value you choose to use. I prefer saving the fixed-width integer types for situations when I know I need such a size.

ealloc 11y ago

I'm not conviced. Maybe it really is that the wider type is faster, and int_fast16_t should be 64 bits. I just tried it out on a 64 bit system. The program is just a for loop. If the loop variable is a int_fast16_t the loop increment step compiles to addq $1, -16(%rbp) If it is int16_t it compiles to movzwl -4(%rbp), %eax addl $1, %eax movw %ax, -4(%rbp) The 64 bit width version is shorter, and so conceivably faster. Performance seems the same though, but that's probably because this program isn't a proper benchmark.

Narishma 11y ago
> The 64 bit width version is shorter, and so conceivably faster. Without profiling there's no way to tell on modern processors.
- nwmcsween 11y ago
  Seriously, you think movzwl -4(%rbp), %eax addl $1, %eax movw %ax, -4(%rbp) will be on par with addq $1, -16(%rbp)
  - DSMan195276 11y ago
    Modern processors are pretty crazy beasts. He right in saying it's impossible to say for sure without some hard numbers or profiling. Comparatively, while one is three instructions and the other is one, that single instruction is still doing everything the other three are doing. The only reason they aren't both one instruction seems to be that `addw` must not being a thing (Why, I don't know). Since the I/O done by both will be nearly identical, and the addition's should be very comparable in speed, it's not crazy to say they should perform basically the same. If you compiled with -O2 I bet you'd see almost identical code, since it would probably remove the memory access.