why prefix increment is faster than postfix increment?

Discussion in 'C Programming' started by jrefactors@hotmail.com, Oct 22, 2005.

  1. Guest

    I heard people saying prefix increment is faster than postfix
    incerement, but I don't know what's the difference. They both are
    i = i+1.

    i++
    ++i

    Please advise. thanks!!
     
    , Oct 22, 2005
    #1
    1. Advertising

  2. Jonathan Mcdougall, Oct 22, 2005
    #2
    1. Advertising

  3. John Carson Guest

    <> wrote in message
    news:
    > I heard people saying prefix increment is faster than postfix
    > incerement, but I don't know what's the difference. They both are
    > i = i+1.


    They are obviously not both the same. The prefix form returns the value of
    the variable after the incrementation and the postfix form returns the value
    of the variable before the incrementation.

    For the postfix form, the simple way to implement it is for the compiler to
    produce code that creates a temporary that stores the original value and
    then to return this value. For a built-in type, this is a cheap operation.
    For a class object, it may be an expensive operation.

    --
    John Carson
     
    John Carson, Oct 22, 2005
    #3
  4. In article <>,
    wrote:

    > I heard people saying prefix increment is faster than postfix
    > incerement, but I don't know what's the difference. They both are
    > i = i+1.
    >
    > i++
    > ++i
    >
    > Please advise. thanks!!


    The C answer and the C++ answer for the built-in operators are: Whoever
    makes that claim is not only clueless, but is also the type of dangerous
    clueless person who thinks they have a clue. Don't take _any_ advice of
    them. Ever.

    I don't think you are interested in the C++ answer for operator
    overloading yet.
     
    Christian Bau, Oct 22, 2005
    #4
  5. Kaz Kylheku Guest

    wrote:
    > I heard people saying prefix increment is faster than postfix
    > incerement, but I don't know what's the difference. They both are
    > i = i+1.
    >
    > i++
    > ++i


    If you are throwing away the result, there is no semantic difference at
    all, because the only difference between ++i and i++ is whether i or i
    + 1 is returned.

    If you don't throw away the result, then they are different operators;
    you can't substitute one without the other without making compensating
    changes in the surrounding program! You then end up with two different
    programs that you have to compare as such. If there is a performance
    difference between those programs, it's a result of not just changing
    the i++ to ++i, or vice versa, but also a consequence of those other
    compensating changes, and how your particular compiler and machine
    deals with everything as a whole.

    Note that in C++ (this is cross-posted to comp.lang.c++), both forms of
    the operator can be user-defined. If you are dealing with a choice
    between two forms of the user-defined operator, and performance is
    critical, you obviously have to take that into consideration!
     
    Kaz Kylheku, Oct 22, 2005
    #5
  6. >I heard people saying prefix increment is faster than postfix
    >incerement, but I don't know what's the difference. They both are


    Any claim that X is faster than Y that doesn't specify a specific
    compiler and platform is FALSE. Even if Y is "do X 1000000 times".

    Gordon L. Burditt
     
    Gordon Burditt, Oct 22, 2005
    #6
  7. Greg Guest

    wrote:
    > I heard people saying prefix increment is faster than postfix
    > incerement, but I don't know what's the difference. They both are
    > i = i+1.
    >
    > i++
    > ++i
    >
    > Please advise. thanks!!


    Consider this program:

    void PrintElement(const std::vector<int>::iterator& i)
    {
    std::cout << *i << " ";
    }

    int main()
    {
    std::vector<int> v;

    v.push_back(1); v.push_back(2); v.push_back(3);

    std::vector<int>::iterator i = v.begin();

    while (i != v.end())
    PrintElement( i++ );

    while (i != v.begin())
    PrintElement( --i );
    }

    Which PrintElement() call is like the more efficient one: the one with
    the postincremented parameter (i++) or the pre-decremented (--i)
    parameter? Or is there no reason to think that there would be a
    difference?

    In this case, it is likely that first PrintElement call with the
    postfix incremented paramter has more overhead than the second, because
    the compiler must increment the iterator i before it calls
    PrintElement. But when the call to PrintElement is made, the compiler
    must pass the value of i (or a reference to a temporary copy of i) that
    i had before it was incremented. Therefore the compiler has little
    choice but to make a copy of i before incrementing i, so that it has an
    iterator with which it can call PrintElement.

    The second PrintElement call applies a prefix operator to the paramter;
    the compiler can therefore pass i directly to PrintElement, since its
    incremented value is the appropriate value to pass to PrintElement.

    Of course, the difference is not likely to be great, but there is
    nonetheless a basis for expecting postfix operators to be less
    efficient than prefix operators, especially when applied to parameters
    in a function call.

    Greg
     
    Greg, Oct 23, 2005
    #7
  8. Greg wrote:

    > Consider this program:
    >
    > void PrintElement(const std::vector<int>::iterator& i)
    > {
    > std::cout << *i << " ";
    > }

    [etc.]

    When you respond to posts which are crossposted to <news:comp.lang.c>
    and <news:comp.lang.c++>, try to give answers that are acceptable in
    both. You have posted a bunch of compilation errors to
    <news:comp.lang.c>. There is no need to consider your code at all.
     
    Martin Ambuhl, Oct 23, 2005
    #8
  9. Greg Guest

    Gordon Burditt wrote:
    > >I heard people saying prefix increment is faster than postfix
    > >incerement, but I don't know what's the difference. They both are

    >
    > Any claim that X is faster than Y that doesn't specify a specific
    > compiler and platform is FALSE. Even if Y is "do X 1000000 times".


    Not necessarily. If one can show that Y performs every operation that X
    performs, and then has to perform additional operations outside of that
    set and that require a measurable amount of time to complete, then one
    would have successfully proven that X is faster than Y. And in fact
    that is the case here: the postincrement operator may have to perform
    an additional copy operation that the prefix version does not have to
    perform. Otherwise the amount of work required of each is the same.

    Greg
     
    Greg, Oct 23, 2005
    #9
  10. Michael Mair Guest

    Greg wrote:
    > Gordon Burditt wrote:
    >
    >>>I heard people saying prefix increment is faster than postfix
    >>>incerement, but I don't know what's the difference. They both are

    >>
    >>Any claim that X is faster than Y that doesn't specify a specific
    >>compiler and platform is FALSE. Even if Y is "do X 1000000 times".

    >
    > Not necessarily. If one can show that Y performs every operation that X
    > performs, and then has to perform additional operations outside of that
    > set and that require a measurable amount of time to complete, then one
    > would have successfully proven that X is faster than Y. And in fact
    > that is the case here: the postincrement operator may have to perform
    > an additional copy operation that the prefix version does not have to
    > perform. Otherwise the amount of work required of each is the same.


    Nope. Maybe in source code but not necessarily in the generated code.
    The optimisation may have a stage which looks for certain patterns;
    it is very well possible that the seemingly slower code qualifies for
    the optimisation but the "faster" code does not. This may be the
    compiler's fault or yours, depending on the problem at hand.

    So, you are right most of the time but not always. However, C++ coding
    guidelines often bring the ++()/()++ including the caveats as an
    example of "avoiding premature pessimization" and rightly so.


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Oct 23, 2005
    #10
  11. >> >I heard people saying prefix increment is faster than postfix
    >> >incerement, but I don't know what's the difference. They both are

    >>
    >> Any claim that X is faster than Y that doesn't specify a specific
    >> compiler and platform is FALSE. Even if Y is "do X 1000000 times".

    >
    >Not necessarily. If one can show that Y performs every operation that X
    >performs, and then has to perform additional operations outside of that
    >set and that require a measurable amount of time to complete, then one
    >would have successfully proven that X is faster than Y.


    Not unless you can prove that the compiler generates the code that
    way, and in order to do that, you have to choose a specific compiler.
    You cannot test *ALL* compilers, including ones written between
    your test and publishing the results. And you can't prove, for
    example, that the compiler doesn't add a time-wasting loop to X but
    not to Y, without referring to a specific compiler.

    There are some situations where doing more can be faster.
    For example repeating this statement 1000000 times could be
    faster than doing it 10 times:
    unsigned int x;

    x = x << 1;

    since if the width of x is less than 1000000 bits, this results in
    a constant independent of the original value of x, and the compiler
    might realize this, but if the width of x is greater than 10, and it
    must be, it has to shift x.

    >And in fact
    >that is the case here: the postincrement operator may have to perform
    >an additional copy operation that the prefix version does not have to
    >perform. Otherwise the amount of work required of each is the same.


    You're assuming things about the underlying instruction set that
    may not be true, and assuming that the compiler doesn't do a
    poor job of generating code for one and a good job for the other.
    The effect of a cache hit/miss can also do funny things to code
    that looks like it should run in the same time as other code.

    Gordon L. Burditt
     
    Gordon Burditt, Oct 23, 2005
    #11
  12. In article <>,
    "Greg" <> wrote:

    > Gordon Burditt wrote:
    > > >I heard people saying prefix increment is faster than postfix
    > > >incerement, but I don't know what's the difference. They both are

    > >
    > > Any claim that X is faster than Y that doesn't specify a specific
    > > compiler and platform is FALSE. Even if Y is "do X 1000000 times".

    >
    > Not necessarily. If one can show that Y performs every operation that X
    > performs, and then has to perform additional operations outside of that
    > set and that require a measurable amount of time to complete, then one
    > would have successfully proven that X is faster than Y.


    One would have proven no such thing.

    Consider this:

    double x, y;
    memcpy (&x, &y, sizeof (x) - 1);
    memcpy (&x, &y, sizeof (x));

    A good compiler will translate the second memcpy to a simple assignment
    of a double variable, for example:

    Load double y into register
    Store register into double x.

    In fact, if this is the only time the address of x and y is taken, it is
    quite possible that x and y are still kept in floating-point registers,
    in which case this is a very fast register-to-register assignment.

    On the other hand, the first memcpy will have a much more difficult
    implementation, even though it copies one byte less. Not only will it
    produce much more code, on most current processors that code will
    execute considerably slower.
     
    Christian Bau, Oct 23, 2005
    #12
  13. Jack Klein Guest

    On 22 Oct 2005 01:01:37 -0700, wrote in
    comp.lang.c:

    > I heard people saying prefix increment is faster than postfix
    > incerement, but I don't know what's the difference. They both are
    > i = i+1.


    What people are these? What are their credentials so that you, or we,
    should place any confidence in their opinions?

    > i++
    > ++i
    >
    > Please advise. thanks!!


    One possible item of advice would be for you to associate with
    different people.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Oct 23, 2005
    #13
  14. "Christian Bau" <> wrote in message
    news:...
    > In article <>,
    > "Greg" <> wrote:
    >
    >> Gordon Burditt wrote:
    >> > >I heard people saying prefix increment is faster than postfix
    >> > >incerement, but I don't know what's the difference. They both are
    >> >
    >> > Any claim that X is faster than Y that doesn't specify a specific
    >> > compiler and platform is FALSE. Even if Y is "do X 1000000 times".

    >>
    >> Not necessarily. If one can show that Y performs every operation that X
    >> performs, and then has to perform additional operations outside of that
    >> set and that require a measurable amount of time to complete, then one
    >> would have successfully proven that X is faster than Y.

    >
    > One would have proven no such thing.
    >
    > Consider this:
    >
    > double x, y;
    > memcpy (&x, &y, sizeof (x) - 1);
    > memcpy (&x, &y, sizeof (x));
    >
    > A good compiler will translate the second memcpy to a simple assignment
    > of a double variable, for example:
    >
    > Load double y into register
    > Store register into double x.
    >
    > In fact, if this is the only time the address of x and y is taken, it is
    > quite possible that x and y are still kept in floating-point registers,
    > in which case this is a very fast register-to-register assignment.
    >
    > On the other hand, the first memcpy will have a much more difficult
    > implementation, even though it copies one byte less. Not only will it
    > produce much more code, on most current processors that code will
    > execute considerably slower.


    Nonsense. First one will probably generate hardware excpetion, and
    second one will probably work. Then again first one would be much faster
    as it is simple nop where sizeof(x) == 1 but second one would copy contents.

    Greetings, Bane.
     
    Branimir Maksimovic, Oct 24, 2005
    #14
  15. Michael Mair Guest

    Branimir Maksimovic wrote:
    > "Christian Bau" <> wrote in message
    > news:...
    >
    >>In article <>,
    >>"Greg" <> wrote:
    >>
    >>>Gordon Burditt wrote:
    >>>
    >>>>>I heard people saying prefix increment is faster than postfix
    >>>>>incerement, but I don't know what's the difference. They both are
    >>>>
    >>>>Any claim that X is faster than Y that doesn't specify a specific
    >>>>compiler and platform is FALSE. Even if Y is "do X 1000000 times".
    >>>
    >>>Not necessarily. If one can show that Y performs every operation that X
    >>>performs, and then has to perform additional operations outside of that
    >>>set and that require a measurable amount of time to complete, then one
    >>>would have successfully proven that X is faster than Y.

    >>
    >>One would have proven no such thing.
    >>
    >>Consider this:
    >>
    >> double x, y;
    >> memcpy (&x, &y, sizeof (x) - 1);
    >> memcpy (&x, &y, sizeof (x));
    >>
    >>A good compiler will translate the second memcpy to a simple assignment
    >>of a double variable, for example:
    >>
    >> Load double y into register
    >> Store register into double x.
    >>
    >>In fact, if this is the only time the address of x and y is taken, it is
    >>quite possible that x and y are still kept in floating-point registers,
    >>in which case this is a very fast register-to-register assignment.
    >>
    >>On the other hand, the first memcpy will have a much more difficult
    >>implementation, even though it copies one byte less. Not only will it
    >>produce much more code, on most current processors that code will
    >>execute considerably slower.

    >
    > Nonsense. First one will probably generate hardware excpetion, and
    > second one will probably work. Then again first one would be much faster
    > as it is simple nop where sizeof(x) == 1 but second one would copy contents.


    The second one is guaranteed to work and have the same effect
    as x = y, the first may lead to a trap representation of x but
    can also work.
    Are you sure that you are aware of the semantics of memcpy()?


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Oct 24, 2005
    #15
  16. John Carson Guest

    "Jack Klein" <> wrote in message
    news:
    > On 22 Oct 2005 01:01:37 -0700, wrote in
    > comp.lang.c:
    >
    >> I heard people saying prefix increment is faster than postfix
    >> incerement, but I don't know what's the difference. They both are
    >> i = i+1.

    >
    > What people are these? What are their credentials so that you, or we,
    > should place any confidence in their opinions?


    Herb Sutter and Andrei Alexandrescu, C++ Coding Standards, p.50: "The prefix
    form is semantically equivalent, just as much typing, and often slightly
    more efficient by creating one less object. This is not premature
    optimization; it is avoiding premature pessimization."


    --
    John Carson
     
    John Carson, Oct 24, 2005
    #16
  17. Michael Mair Guest

    John Carson wrote:
    > "Jack Klein" <> wrote in message
    > news:
    >
    >> On 22 Oct 2005 01:01:37 -0700, wrote in
    >> comp.lang.c:
    >>
    >>> I heard people saying prefix increment is faster than postfix
    >>> incerement, but I don't know what's the difference. They both are
    >>> i = i+1.

    >>
    >> What people are these? What are their credentials so that you, or we,
    >> should place any confidence in their opinions?

    >
    > Herb Sutter and Andrei Alexandrescu, C++ Coding Standards, p.50: "The
    > prefix form is semantically equivalent, just as much typing, and often
    > slightly more efficient by creating one less object. This is not
    > premature optimization; it is avoiding premature pessimization."


    An excellent _C++_ book by well-renowned authors; however, you neglected
    to quote the context: This applies if we are interested only in the
    side effect and not at all in the value of the expression.

    As this is crossposted to c.l.c and as there are no overloaded operators
    in C, this is wrong in its generality.

    <OT>In fact, on processors with postincrement/predecrement only and if
    stuck with a poorly performing compiler, this may be even completely
    wrong.</OT>


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
     
    Michael Mair, Oct 24, 2005
    #17
  18. Michael Mair wrote:
    > Branimir Maksimovic wrote:
    > > "Christian Bau" <> wrote in message
    > >>Consider this:
    > >>
    > >> double x, y;
    > >> memcpy (&x, &y, sizeof (x) - 1);
    > >> memcpy (&x, &y, sizeof (x));
    > >>

    > >
    > > Nonsense. First one will probably generate hardware excpetion, and
    > > second one will probably work. Then again first one would be much faster
    > > as it is simple nop where sizeof(x) == 1 but second one would copy contents.

    >
    > The second one is guaranteed to work and have the same effect
    > as x = y, the first may lead to a trap representation of x but
    > can also work.


    In case that sizeof(x) == 1 , I agree.

    > Are you sure that you are aware of the semantics of memcpy()?


    Well, I don't need to, cause I don't use memcpy to assign variables.

    Greetings, Bane.
     
    Branimir Maksimovic, Oct 24, 2005
    #18
  19. John Carson Guest

    "Michael Mair" <> wrote in message
    news:
    > John Carson wrote:
    >> "Jack Klein" <> wrote in message
    >> news:
    >>
    >>> On 22 Oct 2005 01:01:37 -0700, wrote in
    >>> comp.lang.c:
    >>>
    >>>> I heard people saying prefix increment is faster than postfix
    >>>> incerement, but I don't know what's the difference. They both are
    >>>> i = i+1.
    >>>
    >>> What people are these? What are their credentials so that you, or
    >>> we, should place any confidence in their opinions?

    >>
    >> Herb Sutter and Andrei Alexandrescu, C++ Coding Standards, p.50: "The
    >> prefix form is semantically equivalent, just as much typing, and
    >> often slightly more efficient by creating one less object. This is
    >> not premature optimization; it is avoiding premature pessimization."

    >
    > An excellent _C++_ book by well-renowned authors; however, you
    > neglected to quote the context: This applies if we are interested
    > only in the side effect and not at all in the value of the expression.


    You mean the original value of the expression. I took that to be understood.

    > As this is crossposted to c.l.c and as there are no overloaded
    > operators in C, this is wrong in its generality.


    It is clear that its main significance is for C++. Whether it is completely
    irrelevant for C I don't know. I would have imagined that i++ could easily
    require an additional temporary even when i is an int. But the exact
    efficiency consequences of this or some alternative with built-in types
    requires a knowledge of compilers/processors that I don't have.

    --
    John Carson
     
    John Carson, Oct 24, 2005
    #19
  20. In article <djh5tb$207$>,
    "Branimir Maksimovic" <> wrote:

    > Nonsense. First one will probably generate hardware excpetion, and
    > second one will probably work. Then again first one would be much faster
    > as it is simple nop where sizeof(x) == 1 but second one would copy contents.


    I wish you a successful career. Maybe you should learn a bit about
    programming, that might help.
     
    Christian Bau, Oct 24, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sergey
    Replies:
    6
    Views:
    2,954
    Victor Bazarov
    Apr 1, 2005
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,271
    Smokey Grindel
    Dec 2, 2006
  3. lovecreatesbeauty
    Replies:
    8
    Views:
    1,743
    Old Wolf
    Sep 12, 2005
  4. Replies:
    99
    Views:
    2,565
    eliza81
    Jun 11, 2010
  5. Alf P. Steinbach /Usenet
    Replies:
    0
    Views:
    941
    Alf P. Steinbach /Usenet
    May 22, 2011
Loading...

Share This Page