On: Why is this C++ code faster than my hand-written a...

[vardump]

> I try to use ++x instead of x++, even though 99% of the time it makes no difference.

I think 100% of time is closer to truth, unless you're using ancient or embedded 8/16-bit compilers.

[Animats → vardump]

That hasn't really been a thing since the PDP-11, which had an auto-increment option on the register used for pointer offsets. That's why that feature is in C. It really mattered in 1978.

[vram22 → Animats]

Interesting, so the C creators used a feature in their language, that was hardware-specific. I thought (from having read K&R) that one goal of C was to be hardware-independent. Maybe this was an exception, or maybe that auto-increment was common to many computer designs at that time.

[mark-r → vram22]

Wikipedia states that its inclusion in B (the ancestor to C) was independent of the PDP-11 instruction set, which hadn't been invented yet [1].

[1] https://en.wikipedia.org/wiki/Increment_and_decrement_operat...

[vram22 → mark-r]

Cool.

Wow, B. A blast from the past, sort of. I had read a good book about BCPL (the ancestor to B) many years ago. IIRC, it was by Martin Richards, inventor of BCPL. Pretty interesting book and language. BCPL and B were both typeless languages, or languages with just one type, the machine word (16 or 32 bits, don't remember). Still I found that many algorithms and programs were expressed rather compactly in BCPL - or so it seemed to me at the time. Was quite junior then, and without exposure to more advanced programming languages - only knew BASIC and Pascal, probably; even C, I only learned a bit later.

https://en.wikipedia.org/wiki/B_(programming_language)

https://en.wikipedia.org/wiki/BCPL

https://en.wikipedia.org/wiki/Martin_Richards_(computer_scie...

Also just saw some other interesting stuff from the BCPL article above:

[ BCPL is the language in which the original hello world program was written.[3] The first MUD was also written in BCPL (MUD1).

Several operating systems were written partially or wholly in BCPL (for example, TRIPOS and the earliest versions of AmigaDOS).

BCPL was also the initial language used in the seminal Xerox PARC Alto project, the first modern personal computer; among other projects, the Bravo document preparation system was written in BCPL. ]

[jcelerier → vardump]

naye.

Even for the following trivial function:

  #include <vector>
  #include <string>
  std::size_t foo(const std::vector<std::string>& vec)
  {
    std::size_t n = 0;
    for(auto it = vec.begin(), end = vec.end(); it != end; ++it)
    {
        n += vec.size();
    }
    return n;
  }

MSVC 2017 generates different assembly for ++it vs it++, at the highest optimization level.

[moefh → jcelerier]

That's sad. Both gcc and clang at -O3 can optimize it++ to ++it (see [1]).

Hopefully MSVC will improve soon.

[1] https://godbolt.org/g/pxzVdP

[vardump → jcelerier]

That's very surprising, perhaps a compiler bug? Does it perform any differently?

Just tried gcc 7.1, both post and pre-increment compile identically.

[Arnavion → jcelerier]

Looks identical to me.

https://godbolt.org/g/mELzSE

https://godbolt.org/g/nGcdqT

[apta → Arnavion]

For the it++ case:

    std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >::operator++, COMDAT PROC
            mov      rax, QWORD PTR [rcx]
            mov      QWORD PTR [rdx], rax
            add      rax, 32              ; 00000020H
            mov      QWORD PTR [rcx], rax
            mov      rax, rdx
            ret      0

For the ++it case:

    std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >::operator++, COMDAT PROC
            add      QWORD PTR [rcx], 32      ; 00000020H
            mov      rax, rcx
            ret

[vardump → apta]

Interestingly the code you quoted is not called at all. I guess eventually linking phase removes it as dead code.

That considered, both pre- and post-increment generate identical code, even with VS2017.

This matches my previous experience about pretty much any compiler in last 15 years or so -- there's no difference between ++i and i++, unless, of course, it's in a statement and changes the actual meaning of code.

"it++" case. Note that iterator function is not called.

  foo PROC
        mov      rdx, QWORD PTR [rcx]
        xor      eax, eax
        mov      rcx, QWORD PTR [rcx+8]
        cmp      rdx, rcx
        je       SHORT $LN70@foo
        mov      r8, rcx
        sub      r8, rdx
        sar      r8, 5
        npad     8
  $LL4@foo:
        add      rax, r8
        add      rdx, 32              ; 00000020H
        cmp      rdx, rcx
        jne      SHORT $LL4@foo
  $LN70@foo:
        ret      0
  foo ENDP

Here's the code generated for "++it" case. Iterator function is not called here either.

  foo PROC
        mov      rdx, QWORD PTR [rcx]
        xor      eax, eax
        mov      rcx, QWORD PTR [rcx+8]
        cmp      rdx, rcx
        je       SHORT $LN68@foo
        mov      r8, rcx
        sub      r8, rdx
        sar      r8, 5
        npad     8
  $LL4@foo:
        add      rax, r8
        add      rdx, 32              ; 00000020H
        cmp      rdx, rcx
        jne      SHORT $LL4@foo
  $LN68@foo:
        ret      0
  foo ENDP

[apta → vardump]

Good catch! Thanks for the correction.

[Arnavion → vardump]

Exactly.