Q:

What's the proper bitsize for int_fastN_t on different bitness platforms?

As we all know, stdint.h offers both data and code-economic variants for some N-bit type by int_leastN_t and int_fastN_t, respectively. I suppose it does it with word size in mind for different CPU's.
That being said and from what I know, a 64-bit CPU processes 64-bit data faster than less-bit data, whatever "less" is. It logically follows that 64-bit integer is faster than 32-bit and when it comes to 64-bit CPU's, using a 16-bit data as fast as possible, int_fast16_t would have INT_FAST16_MIN defined to INT64_MIN instead of the INT32_MIN specified in stdint.h.
A similar case would be int_fast8_tfor 32-bit CPU's but the catch is char is exactly 8 bits, regardless, so there can't be a least version.
I know current specification has to accommodate both 64-bit and 32-bit processors but theoretically, from 64-bit pov, would my statement be correct?

A:

No, there's no general theoretical basis for determining how [u]int_fastN_t should be defined, apart from the obvious requirement that they must be at least N bits wide.
There's really no firm definition of what a "32-bit" or "64-bit" CPU is. The number might refer to the size of a general-purpose CPU register, or to the size of an address, or to the width of some internal bus, or to the whim of the marketing department. There have been a number of CPUs whose "bitness" has been vague; some CPUs have been 8-bit in some ways and 16-bit on others, or 16-bit and 32-bit. See the evolution of the x86 and 68k CPU families for examples.
It's entirely possible to have a CPU with 64-bit general-purpose registers that also has instructions that can perform 32-bit arithmetic faster than 64-bit arithmetic. For that matter, 64-bit addition might be faster than 32-bit addition, and 32-bit division faster than 64-bit division.
Personally, I'm content to let the compiler and runtime library implementers worry about it, and define the [u]intfastN_t types in the most reasonable way for the targeted architecture. If I need to know the actual size at run time, there's always the sizeof operator. If I need to know the actual size when I'm writing code, I probably shouldn't be using [u]int_fastN_t in the first place.
Here's what the C standard says about the [u]int_leastN_t types (N1570 7.20.1.3:

Each of the following types designates an integer type that is usually
  fastest to operate with among all integer types that have at least the
  specified width.
The typedef name int_fastN_t designates the fastest signed integer
  type with a width of at least N. The typedef name uint_fastN_t
  designates the fastest unsigned integer type with a width of at least
  N.
The following types are required:
int_fast8_t uint_fast8_t
int_fast16_t uint_fast16_t
int_fast32_t uint_fast32_t
int_fast64_t uint_fast64_t
  All other types of this form are optional.

There are the only guarantees offered by the C standard; anything beyond that is non-portable.

