'Int' is faster than 'Char'

Discussion in 'C Programming' started by karthikbalaguru, Aug 13, 2007.

  1. Hi,

    How is 'Int' Faster than 'Char' ?
    I think , 'Char' is small and so it should be easily & efficiently .

    Can someone here provide some info regarding this.

    Thanks and Regards,
    Karthik Balaguru
     
    karthikbalaguru, Aug 13, 2007
    #1
    1. Advertisements

  2. karthikbalaguru

    Ian Collins Guest

    In which context?
     
    Ian Collins, Aug 13, 2007
    #2
    1. Advertisements

  3. Is 'Int' really faster than 'Char' ?

    Thx in advans,
    Karthik Balaguru
     
    karthikbalaguru, Aug 13, 2007
    #3
  4. karthikbalaguru

    Ian Collins Guest

    *Please don't quote signatures*
    In which context? It is significant.
     
    Ian Collins, Aug 13, 2007
    #4
  5. Ok, i will tell u the story.... :(
    I came accross a document that states that 'int' is faster than
    'char'.
    So, I would like to know the following because this is the first time,
    i am hearing such a stuff -
    1) Is 'int' really faster than 'char' ?
    2) If so, then how is it ?

    I have provided Info found in that doc.
    Since 'int' is the fastest data type in C, "Method 1" is better than
    any other implementations.

    Method 1)
    typedef int BOOLEAN
    #define TRUE(1)
    #define FALSE(0)

    Method 2)
    typedef char BOOLEAN
    #define TRUE(1)
    #define FALSE(0)

    So, It has been stated 'int' is faster than 'char' .
    Of the above two type of methods, Method 2 is found to be slow because
    it uses 'char'.
    Is it so ? How ?

    Thx in advans,
    Karthik Balaguru
     
    karthikbalaguru, Aug 13, 2007
    #5
  6. C is a case-sensitive language. 'Int' and 'int' are two different
    identifiers (actually an identifier and a keyword), as are 'Char' and
    'char'. So your question is:

    How is 'int' faster than 'char'.

    int and char are types. Types do not have speed in any meaningful
    sense. Specific operations on types might be faster or slower than
    specific operations on other types.

    So your real question is something like:

    How are operations on operands of type 'int' faster than the same
    operations on operands of type 'char'.

    As far as the C language is concerned, the question is *still*
    meaningless. The language doesn't say anything about that the
    relative speeds of different operations, and such things can and often
    do vary from one implementation to another.

    On *some* systems, operations on 'int' can indeed be faster than
    operations on 'char', because the hardware is designed to operate
    efficiently on 'word'-sized chunks of data. For example, suppose int
    is 32 bits, and char is 8 bits (other sizes are possible). The CPU
    might have instructions to load, store, and operate on 32-bit chunks
    of data. It might not have such instructions for 8-bit data; instead,
    to load an 8-bit value, it might have to load a 32-bit value and
    extract the desired 8 bits. To store an 8-bit value, it might have to
    load 32 bits, use bitwise operations to set the desired 8-bit subset,
    and then store 32 bits.

    On other systems, operations on 8-bit values might be faster than
    operations on 32-bit values. Or they might be exactly the same speed.

    The standard (C99 6.2.5p5) says:

    A "plain" int object has the natural size suggested by the
    architecture of the execution environment ...

    This suggests, but does not require, that an int is typically one
    "word", and that operations on it are likely to be efficient.

    If you want to have a single object, or a few individual objects,
    intended to hold only small values, it's likely (but by no means
    guaranteed) that using 'int' will give you the fastest code. Using
    'char' instead might increase the size of your code more than it
    reduces the size of your objects.

    On the other hand, if you want large arrays of such objects, the space
    saved by using 'char' could be more important.
     
    Keith Thompson, Aug 13, 2007
    #6
  7. karthikbalaguru

    Ian Collins Guest

    The question is still meaningless. There is nothing in the standard
    concerning the speed (how would you define speed?) of a type.

    On some systems, operations on a char might be faster than on an int
    (say an 8 bit micro with a 16 bit int) on others, they might be
    significantly slower if the hardware can't address (or has to go through
    hoops to address, or has to mask bits or...) individual bytes of memory.
     
    Ian Collins, Aug 13, 2007
    #7
  8. karthikbalaguru

    Army1987 Guest

    Is it the first answer in www.c-faq.com?
    Operators such as &&, ||, <, == etc. all return an int.
    Functions such as isspace(), isupper() etc. all return an int.
    So in the second case there will be lots of conversions from int
    to char which are likely to slow down the code. Also, on some
    machines fetching a char is slower than fetching an int.
     
    Army1987, Aug 13, 2007
    #8
  9. karthikbalaguru

    Army1987 Guest

    If you have C99, use int_fast8_t in <stdint.h> (or _Bool if it is
    what you need) if this bothers you.
     
    Army1987, Aug 13, 2007
    #9
  10. karthikbalaguru

    SM Ryan Guest

    # Hi,
    #
    # How is 'Int' Faster than 'Char' ?
    # I think , 'Char' is small and so it should be easily & efficiently .

    Depends on the hardware. Memory might be optimised for word
    access, with bytes requiring extra hardware or software fiddling.
    CPU operations might only accept int sized values, with extra
    steps of widenning and thinning chars. Or the hardware could be
    optimised for char over int. It really depends on the machine
    and the intended customer.
     
    SM Ryan, Aug 13, 2007
    #10
  11. karthikbalaguru

    SM Ryan Guest

    # I have provided Info found in that doc.
    # Since 'int' is the fastest data type in C, "Method 1" is better than
    # any other implementations.
    #
    # Method 1)
    # typedef int BOOLEAN
    # #define TRUE(1)
    # #define FALSE(0)

    If <stdbool.h> is available on your machine, the best guess,
    without benchmarking, is to use that and hope your compiler
    vendor has done the hard work of finding what is really superior
    performance.
     
    SM Ryan, Aug 13, 2007
    #11
  12. karthikbalaguru

    Chris Dollin Guest

    Whatever the relative speeds might have been, both of these
    methods are syntactically incorrect -- for two different
    reasons.
    It depends on how they are used. (Sometimes, when `char` is rather
    smaller than `int`, that allows code to run faster, or even run
    rather than not, because big boolean arrays won't be as big.)

    In any case, such speed variation is a property of /a particular
    implementation/, used in /a particular way/, so you can't appeal
    to the standard for an answer, and if you want to appeal to
    other programmers, you'd better be specific about how you're
    using the Methods and what platform you're using and what you're
    performance goals are.
     
    Chris Dollin, Aug 13, 2007
    #12
  13. These definitions are syntax errors. You need a ';' on the typedefs,
    and a space after 'TRUE' and 'FALSE', and the parentheses are
    unnecessary.

    Personally, my favorite way to define a boolean type in C (if _Bool
    and <stdbool.h aren't available) is:

    typedef enum { false, true } bool;

    If you choose to define 'TRUE' and 'FALSE', it's important to remember
    *not* to compare a value for equality with TRUE. For example:

    BOOLEAN b = some_condition;
    if (b == TRUE) /* ... */ WRONG!

    Any non-zero value is considered true; the comparison will fail if b
    has any value other than 0 or 1. Instead, since b is already a boolean,
    just test it directly:

    if (b) /* ... */ OK

    This is *much* more important than any concerns about performance.

    In addition to fact that the relative performance is system-specific,
    it's entirely possible that some operations will be faster for char
    than for int, and other operations will be faster for int than for
    char.

    It's not very likely that the difference either way is going to be
    significant. Write clear and correct code. If it works, and it's
    fast enough, you're done. If it works, but it's not fast enough, you
    can start looking for ways to speed it up. It's easier to make good
    code fast than to make fast code good.
     
    Keith Thompson, Aug 13, 2007
    #13
  14. int is meant to be the "natural integer size" for the machine.
    So you should assume that if you need to hold a boolean, int will be the
    most efficient representation, speed wise.
    However ints also have to be at least 16 bits. The C standard cannot
    legislate that hardware will access 16-bit or 32-bit quantities faster than
    chars (almost always 8 bits). So the assumption will not always hold true.
    Additionally there are issues such as cache usage, register allocation,
    pipeling and similar which make it very difficult to predict how a
    particular piece of code will behave.
    More often than not, however, char will be slower, maybe because the
    unaligned read is, under the hood, an aligned 32-bit read followed by some
    buit shifting, or maybe because there are no 8-bit registers and so char
    variables have to take modulus 256 operations to force them into range.
     
    Malcolm McLean, Aug 13, 2007
    #14

  15. In this context it will not matter much since its boolean (usually used as
    return type). So not much runtime wasted. But it saves memory (if used for
    static or global vars). In one case int is definitely faster than char : On
    most RISC processors use of int rather than char for a loop index.
     
    Ravishankar S, Aug 14, 2007
    #15
  16. karthikbalaguru

    Army1987 Guest

    On Tue, 14 Aug 2007 09:49:09 +0200, Ravishankar S wrote:

    [about using int or char]
    If you don't care about time and want to save space, use char.
     
    Army1987, Aug 14, 2007
    #16
  17. karthikbalaguru

    pete Guest

    An array of char will save space over an array of int,
    but for single or a few objects,
    it is possible that all byte size objects may be aligned on an int
    boundary and so, not really saving any usable space.

    On my machine, the output of new.c is:

    The address of ca is 0012FF7C
    The address of cb is 0012FF78
    The address of cc is 0012FF74

    /* BEGIN new.c */

    #include <stdio.h>

    int main(void)
    {
    char ca = 0;
    char cb = 0;
    char cc = 0;

    printf("The address of ca is %p\n", (void *)&ca);
    printf("The address of cb is %p\n", (void *)&cb);
    printf("The address of cc is %p\n", (void *)&cc);
    return 0;
    }

    /* END new.c */
     
    pete, Aug 14, 2007
    #17
  18. Sounds interesting . So, it is not necessarily only that of
    Structure's that behave like that .
    So, Even, single object behave like that. That sounds
    interesting :):).

    Karthik Balaguru
     
    karthikbalaguru, Aug 14, 2007
    #18
  19. karthikbalaguru

    Army1987 Guest

    [snip signatures unless you're commenting on them]
    ca only occupies 0012FF7C. A char occupies one byte. An array
    of three chars occupies three bytes. Simply, the placement of
    automatic variable is unspecified. In that example, not only there
    are gaps, but the order is 'wrong', too.
     
    Army1987, Aug 14, 2007
    #19
  20. karthikbalaguru

    pete Guest

    But my point is, that the space saved that way,
    may or may not be *usable* space.

    It's only extremely very rarely that I declare a single object
    of a type which is subject to integer promotions.
     
    pete, Aug 17, 2007
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.