Re: First to learn C if learning C++?
On 19/10/14 19:05, Paavo Helde wrote:
David Brown <david.brown@hesbynett.no> wrote in
news:m20nrl$uvs$1@dont-email.me:
On 12/10/14 18:22, JiiPee wrote:
On 12/10/2014 15:56, Emanuel Berg wrote:
JiiPee <no@notvalid.com> writes:
Also: Short code is not always an advantage. Most
often it is because it is fast to read and write. But
sometimes short code gets really cryptical and
difficult to maintain. Short code doesn't imply
execution speed. It can actually be the other way
around as there isn't any optimization of obscure
hacks.
many times there is no difference in assembly code though. For
example c-loop:
int i;
for(i=0; i<size; ++i)
can be done in C++:
for(auto i : vec)
clearly c++ version is shorter and more elegant here. Its also easier
to see what happens in the looop. So its better readable. plus the
assembly code is the same in both, so they are equally fast
Or would you say the C code here is better? In what way?
Actually, the assembly code is likely to be different (I'm guessing
that inside the loop you are accessing a C array or C++ vector) - the
first loop will be faster (whether compiled as C or C++).
Citation needed. Or at least a clarificiation. What makes the second loop
inherently slower than the first? And why do you assume the second loop
accesses a std::vector and not std::array for example?
The variable is called "vec", which means it is a fair guess that inside
the loop we have a vector, not an array. And I explained below why I
think the second loop (with a vector) is inherently slower. I don't
think the use of the range for should make much of a difference - it
will depend on whether "size" is a known compile-time constant or must
be loaded.
As for a citation, I've put a short test program along with the
generated code at the end of the post. This was generated with gcc4.9
on 64-bit Linux, and should be reasonably representative. Of course the
code is just an example, and makes assumptions, extrapolating from the
very incomplete original lines.
Of course, as I said earlier, it is unlikely that the differences will
matter - maximal speed and code density is seldom the most important
factor in choosing how to write your code. And it is only in code with
very tight loops that an instruction or two extra could be noticed at
all - most code will have more complex loops, making the details here
irrelevant. My point was merely that the claim of "the assembly code is
the same in both [cases]" is patently false, and the C-style code is faster.
When you use a std::vector, there is a layer of indirection - the
"vec" object does not contain the data itself. An array in C, or a
std::array in C++11, holds the data rather than a pointer to a
heap-allocated memory block. This means one step fewer in pointers,
and closer cache locations, and therefore slightly faster code.
This does not matter inside a loop. The extra indirection can be done
once only before the loop (at least when the loop body is inline and the
compiler can see that the location of the vector buffer does not change;
and if the loop body is not inline the extra indirection does not
matter).
It matters little - but it is not the same. And if the extra
indirection means a cache miss, that can be hundreds of wasted cycles.
Note that for accessing the stack data there is also an indirection
involved, via the stack pointer (e.g. EBP). The difference is that the
compiler has much better control over when the stack pointer changes.
In C
code, the "size" might be known at compile time, leading to more
speed-ups.
Or it might not, with the variable length arrays in C.
Of course. I can only work from the partial example code.
Does this matter? Probably not, in most code. It is certainly
secondary to the issues of readability and maintainability. But you
can't claim they are equivalent if they are not.
(This is exactly why std::array was added to C++11.)
Nope, the main optimization with std::array is to avoid a dynamic memory
allocation. This is one thing which can really matter in some
circumstances. Cache proximity may also help a bit.
Actually, std::array gives several improvements over std::vector
(assuming you don't need std::vector's flexibilities). Avoiding dynamic
memory allocation skips a large overhead when it is created or
destroyed, but also gives slightly faster code when it is accessed.
Test code:
#include <vector>
#include <array>
const int size = 8;
std::vector<int> vec;
std::array<int, size> arr;
int carr[size];
void testVec(void) {
for (auto i : vec) {
vec[i] = i;
}
}
void testVec2(void) {
for (int i = 0; i < size; i++) {
vec[i] = i;
}
}
void testArr(void) {
for (auto i : arr) {
arr[i] = i;
}
}
void testArr2(void) {
for (int i = 0; i < size; i++) {
arr[i] = i;
}
}
void testCarr(void) {
for (int i = 0; i < size; i++) {
carr[i] = i;
}
}
Command line:
/usr/local/gcc4.9/bin/gcc4.9-gcc -c --std=c++11 a.cpp -Wall -Wextra
-fno-toplevel-reorder -Wa,-ahdsl -O2 > a.lst
Generated code:
GAS LISTING /tmp/cchLoTpE.s page 1
1 .file "a.cpp"
2 .section .rodata
5 _ZStL19piecewise_construct:
6 0000 00 .zero 1
7 .globl vec
8 .bss
9 .align 16
12 vec:
13 0000 00000000 .zero 24
13 00000000
13 00000000
13 00000000
13 00000000
14 .globl arr
15 0018 00000000 .align 32
15 00000000
18 arr:
19 0020 00000000 .zero 32
19 00000000
19 00000000
19 00000000
19 00000000
20 .globl carr
21 .align 32
24 carr:
25 0040 00000000 .zero 32
25 00000000
25 00000000
25 00000000
25 00000000
26 .section .text.unlikely,"ax",@progbits
27 .LCOLDB0:
28 .text
29 .LHOTB0:
30 .p2align 4,,15
31 .globl _Z7testVecv
33 _Z7testVecv:
34 .LFB1253:
35 .cfi_startproc
36 0000 488B3500 movq vec(%rip), %rsi
36 000000
37 0007 488B3D00 movq vec+8(%rip), %rdi
37 000000
38 000e 4839F7 cmpq %rsi, %rdi
39 0011 4889F0 movq %rsi, %rax
40 0014 7419 je .L1
41 0016 662E0F1F .p2align 4,,10
41 84000000
41 0000
42 .p2align 3
43 .L5:
44 0020 486308 movslq (%rax), %rcx
45 0023 4883C004 addq $4, %rax
46 0027 4839C7 cmpq %rax, %rdi
47 002a 890C8E movl %ecx, (%rsi,%rcx,4)
48 002d 75F1 jne .L5
49 .L1:
GAS LISTING /tmp/cchLoTpE.s page 2
50 002f F3C3 rep ret
51 .cfi_endproc
52 .LFE1253:
54 .section .text.unlikely
55 .LCOLDE0:
56 .text
57 .LHOTE0:
58 .section .text.unlikely
59 .LCOLDB1:
60 .text
61 .LHOTB1:
62 0031 66666666 .p2align 4,,15
62 66662E0F
62 1F840000
62 000000
63 .globl _Z8testVec2v
65 _Z8testVec2v:
66 .LFB1254:
67 .cfi_startproc
68 0040 488B1500 movq vec(%rip), %rdx
68 000000
69 0047 31C0 xorl %eax, %eax
70 0049 0F1F8000 .p2align 4,,10
70 000000
71 .p2align 3
72 .L9:
73 0050 890482 movl %eax, (%rdx,%rax,4)
74 0053 4883C001 addq $1, %rax
75 0057 4883F808 cmpq $8, %rax
76 005b 75F3 jne .L9
77 005d F3C3 rep ret
78 .cfi_endproc
79 .LFE1254:
81 .section .text.unlikely
82 .LCOLDE1:
83 .text
84 .LHOTE1:
85 .section .text.unlikely
86 .LCOLDB2:
87 .text
88 .LHOTB2:
89 005f 90 .p2align 4,,15
90 .globl _Z7testArrv
92 _Z7testArrv:
93 .LFB1255:
94 .cfi_startproc
95 0060 B8000000 movl $arr, %eax
95 00
96 .p2align 4,,10
97 0065 0F1F00 .p2align 3
98 .L12:
99 0068 486308 movslq (%rax), %rcx
100 006b 4883C004 addq $4, %rax
101 006f 483D0000 cmpq $arr+32, %rax
101 0000
102 0075 890C8D00 movl %ecx, arr(,%rcx,4)
102 000000
GAS LISTING /tmp/cchLoTpE.s page 3
103 007c 75EA jne .L12
104 007e F3C3 rep ret
105 .cfi_endproc
106 .LFE1255:
108 .section .text.unlikely
109 .LCOLDE2:
110 .text
111 .LHOTE2:
112 .section .text.unlikely
113 .LCOLDB3:
114 .text
115 .LHOTB3:
116 .p2align 4,,15
117 .globl _Z8testArr2v
119 _Z8testArr2v:
120 .LFB1256:
121 .cfi_startproc
122 0080 31C0 xorl %eax, %eax
123 .p2align 4,,10
124 0082 660F1F44 .p2align 3
124 0000
125 .L15:
126 0088 89048500 movl %eax, arr(,%rax,4)
126 000000
127 008f 4883C001 addq $1, %rax
128 0093 4883F808 cmpq $8, %rax
129 0097 75EF jne .L15
130 0099 F3C3 rep ret
131 .cfi_endproc
132 .LFE1256:
134 .section .text.unlikely
135 .LCOLDE3:
136 .text
137 .LHOTE3:
138 .section .text.unlikely
139 .LCOLDB4:
140 .text
141 .LHOTB4:
142 009b 0F1F4400 .p2align 4,,15
142 00
143 .globl _Z8testCarrv
145 _Z8testCarrv:
146 .LFB1257:
147 .cfi_startproc
148 00a0 31C0 xorl %eax, %eax
149 .p2align 4,,10
150 00a2 660F1F44 .p2align 3
150 0000
151 .L18:
152 00a8 89048500 movl %eax, carr(,%rax,4)
152 000000
153 00af 4883C001 addq $1, %rax
154 00b3 4883F808 cmpq $8, %rax
155 00b7 75EF jne .L18
156 00b9 F3C3 rep ret
157 .cfi_endproc
158 .LFE1257:
GAS LISTING /tmp/cchLoTpE.s page 4
160 .section .text.unlikely
161 .LCOLDE4:
162 .text
163 .LHOTE4:
164 .section .rodata
165 0001 000000 .align 4
168 _ZL4size:
169 0004 08000000 .long 8
170 .section
..text.unlikely._ZNSt6vectorIiSaIiEED2Ev,"axG",@progbits,_ZNSt6vectorIiSaIiEED5Ev,comdat
171 .align 2
172 .LCOLDB5:
173 .section
..text._ZNSt6vectorIiSaIiEED2Ev,"axG",@progbits,_ZNSt6vectorIiSaIiEED5Ev,comdat
174 .LHOTB5:
175 .align 2
176 .p2align 4,,15
177 .weak _ZNSt6vectorIiSaIiEED2Ev
179 _ZNSt6vectorIiSaIiEED2Ev:
180 .LFB1456:
181 .cfi_startproc
182 0000 488B3F movq (%rdi), %rdi
183 0003 4885FF testq %rdi, %rdi
184 0006 7408 je .L20
185 0008 E9000000 jmp _ZdlPv
185 00
186 000d 0F1F00 .p2align 4,,10
187 .p2align 3
188 .L20:
189 0010 F3C3 rep ret
190 .cfi_endproc
191 .LFE1456:
193 .section
..text.unlikely._ZNSt6vectorIiSaIiEED2Ev,"axG",@progbits,_ZNSt6vectorIiSaIiEED5Ev,comdat
194 .LCOLDE5:
195 .section
..text._ZNSt6vectorIiSaIiEED2Ev,"axG",@progbits,_ZNSt6vectorIiSaIiEED5Ev,comdat
196 .LHOTE5:
197 .weak _ZNSt6vectorIiSaIiEED1Ev
198 .set _ZNSt6vectorIiSaIiEED1Ev,_ZNSt6vectorIiSaIiEED2Ev
199 .section .text.unlikely
200 .LCOLDB6:
201 .section .text.startup,"ax",@progbits
202 .LHOTB6:
203 .p2align 4,,15
205 _GLOBAL__sub_I_vec:
206 .LFB1462:
207 .cfi_startproc
208 0000 BA000000 movl $__dso_handle, %edx
208 00
209 0005 BE000000 movl $vec, %esi
209 00
210 000a BF000000 movl $_ZNSt6vectorIiSaIiEED1Ev, %edi
210 00
211 000f 48C70500 movq $0, vec(%rip)
211 00000000
211 000000
212 001a 48C70500 movq $0, vec+8(%rip)
212 00000000
212 000000
213 0025 48C70500 movq $0, vec+16(%rip)
GAS LISTING /tmp/cchLoTpE.s page 5
213 00000000
213 000000
214 0030 E9000000 jmp __cxa_atexit
214 00
215 .cfi_endproc
216 .LFE1462:
218 .section .text.unlikely
219 .LCOLDE6:
220 .section .text.startup
221 .LHOTE6:
222 .section .init_array,"aw"
223 .align 8
224 0000 00000000 .quad _GLOBAL__sub_I_vec
224 00000000
225 .hidden __dso_handle
226 .ident "GCC: (GNU) 4.9.1"
227 .section .note.GNU-stack,"",@progbits
GAS LISTING /tmp/cchLoTpE.s page 6
DEFINED SYMBOLS
*ABS*:0000000000000000 a.cpp
/tmp/cchLoTpE.s:5 .rodata:0000000000000000
_ZStL19piecewise_construct
/tmp/cchLoTpE.s:12 .bss:0000000000000000 vec
/tmp/cchLoTpE.s:18 .bss:0000000000000020 arr
/tmp/cchLoTpE.s:24 .bss:0000000000000040 carr
/tmp/cchLoTpE.s:33 .text:0000000000000000 _Z7testVecv
/tmp/cchLoTpE.s:65 .text:0000000000000040 _Z8testVec2v
/tmp/cchLoTpE.s:92 .text:0000000000000060 _Z7testArrv
/tmp/cchLoTpE.s:119 .text:0000000000000080 _Z8testArr2v
/tmp/cchLoTpE.s:145 .text:00000000000000a0 _Z8testCarrv
/tmp/cchLoTpE.s:168 .rodata:0000000000000004 _ZL4size
/tmp/cchLoTpE.s:179
..text._ZNSt6vectorIiSaIiEED2Ev:0000000000000000 _ZNSt6vectorIiSaIiEED2Ev
/tmp/cchLoTpE.s:179
..text._ZNSt6vectorIiSaIiEED2Ev:0000000000000000 _ZNSt6vectorIiSaIiEED1Ev
/tmp/cchLoTpE.s:205 .text.startup:0000000000000000
_GLOBAL__sub_I_vec
.group:0000000000000000 _ZNSt6vectorIiSaIiEED5Ev
UNDEFINED SYMBOLS
_ZdlPv
__dso_handle
__cxa_atexit