1

I'm optimizing a large C project whose integer arithmetic presently uses int. I'm considering switching to int_fast16_t (or even int_fast8_t) wherever a small integer is sufficient. This'll be a reasonably big job, so before I set out, I want to be confident that this has the potential to decrease run-time noticeably (> 5–10%) for users running the software on modern PCs.

As this will depend on the compiler and hardware (edited to clarify: this will differ from end-user to end-user -- so it's hard to know how representative benchmarking on my own PC would be), I appreciate that this is something of a "how long's a piece of string" question – but is there a rule of thumb for what sort of order of magnitude of speed-up I might hope to gain? Are particular categories of operation particularly likely to yield a benefit?

Related:

Martin Smith
  • 3,687
  • 1
  • 24
  • 51
  • 1
    *"As this will depend on the compiler and hardware"* Note that you haven't mentioned any of them. Also, more than the types, the algorithms and the possible dedicated hardware (are you taking advantage of SIMD instructions?) are more likely to have much an impact. – Bob__ Apr 29 '22 at 16:07
  • You might be stuck converting a small part of your program and benchmarking before/after. – Stephen Newell Apr 29 '22 at 16:09
  • 2
    The answer is: "impossible to say unless you do it and then do some profiling and measurements". – Marco Bonelli Apr 29 '22 at 16:09
  • 1
    I would not expect it to yield any noticeable difference TBH. – Eugene Sh. Apr 29 '22 at 16:17
  • 1
    I suspect going from `int` to `int_fast8_t` will reduce performance. It'll save you memory though. They're nothing but aliases to signed/unsigned char or word-size of the hardware. – जलजनक Apr 29 '22 at 16:27
  • If you accessing a large array, using a smaller type may cause fewer cache misses. – Weather Vane Apr 29 '22 at 16:33
  • @जलजनक Hm, I would expect that `int_fast8_t` will be as fast as `int` in most cases, as `int` uses the "natural" word size of the processor. It is allowed to be larger, isn't it? -- However, benchmarks need to be run. – the busybee Apr 29 '22 at 16:49
  • 1
    If you need to gain just few percents, this might work. But if you need more, I think there is no way around faster algorithms. It all depends on the application. – the busybee Apr 29 '22 at 16:52
  • 3
    If your code is SIMD-friendly, then using smaller type can drastically speed up the operation since more 8-bit integers fit in a SIMD register than 16-bit or even 32-bit (respectively 2 and 4 times). For non-SIMD code, this is hard to say, it may be slower in some cases with smaller type on x86-64 platforms. `int_fast8_t` is implementation-defined so nobody can say if this type will be faster in practice with the provided informations. If your computation is SIMD-friendly, please consider using fixed-size types like `int8_t`. Otherwise, `int_fast8_t` is fine. – Jérôme Richard Apr 29 '22 at 17:16
  • interesting presentation that discusses this very topic https://www.youtube.com/watch?v=ieERUEhs910&t=6s – pm100 Apr 30 '22 at 17:43
  • Busybee, it should _never_ be slower than int, since int is at least 8 bit, and int8_fast_t should be the fastest 8 bit type. That would mean the compiler is substandard or broken. – gnasher729 Apr 30 '22 at 18:26

1 Answers1

0

int_fast8_t is the fastest type with at least 8 bits. Assuming a reasonable compiler, it’s never slower than int (if it was then the compiler should have used int). int should be the most common type so it should be fast, it’s quite likely that int8_fast_t is int. especially since this means there are no conversion between int8_fast_t an int needed. That will be by far the most common case.

On an 8 bit or 16 bit system int8_fast_t may be smaller and faster than int, but likely not much. The opposite on a 64 bit system, where int may be 32 bits and slower (but smaller) than a 64 bit int.

And there’s Jeromes comment: If you need a vector of 8 bit ints, and int8_fast_t is 32 bit, then an SIMD vector of int8_fast_t is not what you want. Would be likely as fast as a vector of int, but possibly four times slower than a vector of int8_t.

gnasher729
  • 51,477
  • 5
  • 75
  • 98