Does buffer[index] take the same amount of cycles as *buffer?

Question

char buffer[424242] = {0};

Is buffer[index] as fast as *buffer?

for (int i = 0; i < SIZE; ++i) {
  buffer[i] = 42;
}

char* end = buffer + SIZE;
for (char* pos = buffer; pos != end; ++pos) {
  *pos = 42;
}

I guess my question is, is there any assembly instruction that can set a position in memory plus and offset to a given value in a single cycle?

LEA seems to load the address plus multiply it in this way.

The two do different things. What's the point in asking to compare them? You could ask if `printf` is as fast as `exit`, by that logic. — Kerrek SB, Sep 19 '12 at 12:01
@Fanael: Depends on whether you use wide characters or inline assembly. — Kerrek SB, Sep 19 '12 at 12:07
a bit more info on LEA http://stackoverflow.com/questions/1658294/whats-the-purpose-of-the-lea-instruction — rui, Sep 19 '12 at 12:20
Nowadays such performance depends more on cache hits/misses than on cycles taken. — Tadeusz Kopec for Ukraine, Sep 19 '12 at 12:30
_Sigh._ I really wish we had a close reason "Pointless optimization question." — sbi, Sep 19 '12 at 12:32

Luchian Grigore · Accepted Answer · 2012-09-19T12:14:53.720

1

*buffer is at least as fast as buffer[index]. Depends on index. If index == 0, they'll be equally fast.

As per your edit:

char& end = buffer + SIZE;
for (char* pos; pos != end; ++pos) {
  *pos = 42;
}

invokes undefined behavior because you don't initialize pos.

As per your second edit:

Write your code for readability first, profile & possibly change only after you have some concrete results.

for (int i = 0; i < SIZE; ++i) {
  buffer[i] = 42;
}

is way more readable, stick to it.

edited Sep 19 '12 at 12:14

answered Sep 19 '12 at 11:58

Luchian Grigore

253,575
64
457
625

Thanks for your replies @Luchian! I'm just interested in learning whether it makes any difference down in assembly code. I suspect it doesn't but just curious. I am well aware that I can profile code and that rarely such optimizations are the actual bottleneck! – rui Sep 19 '12 at 12:28
3

@ruibm ah, if you're only interested in the assembly generated, why don't you directly look at it? – Luchian Grigore Sep 19 '12 at 12:29
Just imagined someone in this forum had already come across this before... – rui Sep 19 '12 at 12:41
@ruibm see http://stackoverflow.com/questions/how-to-ask - before asking here, try figuring stuff out yourself. Profile. If you see a difference and can't figure out why it's there, ask. Check the dissasembly yourself. If you can't understand it, ask here. But put some effort into it... – Luchian Grigore Sep 19 '12 at 12:43
Agreed! I guess by just disassembling this myself I'll get my answer straight away. Only point of having this here could be if someone in the future had the same question but I guess they can also try it out themselves. Thanks! – rui Sep 19 '12 at 12:50
1

@ruibm It's totally fine to ask & answer a question yourself. If you find anything meaningful, do it. If performance does vary (doubtful), post the question & answer it. But you have to judge for yourself whether it's really helpful or not. If you'll just post this question again, and answer that they're equally efficient, you'll probably get some downvotes for it. – Luchian Grigore Sep 19 '12 at 12:53
I agree that the initial question was really abstract therefore making it very poor and thus being rightfully downvoted. I believe that as it is currently, it's not as useless to be closed. I also agree/suspect that the performance of these two is basically the same due to specific assembly instruction to do the offset calculations! – rui Sep 19 '12 at 13:06
I would *not* "stick to" the `for` loop. I'd use `std::fill_n(buffer, SIZE, 42);` – Jerry Coffin Sep 19 '12 at 15:57
@JerryCoffin well... among the two options. I bet you wouldn't use a C-array... – Luchian Grigore Sep 19 '12 at 15:59
@LuchianGrigore: Now what would make you think a thing like that? :-) – Jerry Coffin Sep 19 '12 at 16:02

ereOn · Answer 2 · 2012-09-19T12:27:49.637

1

Not sure this is the answer you expect, but do you even have any performance issue to solve ?

Your question tags list contains "optimization" : I would be very very surprised if the only available optimization in your code was a choice between writing *buffer or buffer[].

If you really have a performance issue, you should profile your code first to figure out what the bottleneck is.

edited Sep 19 '12 at 12:27

answered Sep 19 '12 at 12:19

ereOn

53,676
39
161
238

Dude, this is totally out of scope. Soon enough trolls will be asking whether Java or C# would not do the job... I'm just curious to know how this works in different architectures, not whether such optimization would make a program faster enough to beat another... – rui Sep 19 '12 at 12:23
@ruibm: Then perhaps you should state that in your question, because as it stands, it seems at least 4 people find your question worthless enough to downvote it. – ereOn Sep 19 '12 at 12:26
1

@ruibm: Factually if you don't state your question correctly, you can't expect people to answer what you didn't ask. ereOn does make a valid point about the optimization. – Tony The Lion Sep 19 '12 at 12:30
The first draft of the question was definitely incomplete and this is when the -4 were done. Once I made it more complete I only started really getting out of scope answers - I'm taking by this that not many people have ever looked into this in the Assembly level so they just start drifting towards a different topic that they know about. – rui Sep 19 '12 at 12:32
@ruibm: I take it not many people love to waste their time trying to solve problems that don't exist in real code. – ereOn Sep 19 '12 at 12:35
@ereOn: You still haven't got it... not trying to solve any problem here. Just trying to understand/learn how the C/C++ compiled code ends up in Assembly... – rui Sep 19 '12 at 12:39
@ruibm it seems to me the question should rather be "How do I see the assembler code generated by a C++ compiler?"... that's a long way from what you asked. – Luchian Grigore Sep 19 '12 at 12:45
@ruibm: Then first look at the generated assembly code ? And if you don't understand what you see, then ask a question including what you have issues to understand. Also, your question got downvoted, then **closed** so perhaps I'm not the only one "not getting it": you might want to think about that. And no, the reason is **not** that "people are too dumb to answer your question" which you seem to imply. – ereOn Sep 19 '12 at 12:50
@LuchianGrigore - I actually knew that one (for the sake of informing other users http://www.delorie.com/djgpp/v2faq/faq8_20.html). I guess I was just being lazy in case someone had already looked into to this! – rui Sep 19 '12 at 13:11
@ereOn: Not really implying anyone's stupid here dude, chill out. I just assume that nobody answered because nobody's ever tried it. This questions got downvoted because it was awfully abstract in the first draft and that makes sense! (quick remark: don't take this stackoverflow ranking thing to seriously please, you seem to be awfully offended that you answer got a -1) Either way I need to get back to work so thanks for the advice guys! – rui Sep 19 '12 at 13:17
@ruibm: Usually, answers deserve downvotes because they are factually wrong, not because the person that asks takes it too personally and gets hurt in his ego. I really don't care at all about my reputation: I however care about other people seeing what is actually a good advice being downvoted and wrongfully concluding that they should care first about silly optimizations instead of just writing maintainable code. – ereOn Sep 19 '12 at 13:28

Does buffer[index] take the same amount of cycles as *buffer?

2 Answers2