Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

The C modest god

Compiler optimizations question

This topic is 5884 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Would visualC++6 optimze the two different(doing the same) codes differently?(second code faster) (compiled as C) LPBYTE a, b, c; first code: *a = *c; *b = *c; second code: *a = *b = *c; Waiting for reply. Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
Hmm, let me compile...
THis is the asm for it:

//first code:
12: *a = *c;
0040103D mov eax,dword ptr [ebp-4]
00401040 mov ecx,dword ptr [ebp-0Ch]
00401043 mov dl,byte ptr [ecx]
00401045 mov byte ptr [eax],dl
13: *b = *c;
00401047 mov eax,dword ptr [ebp-8]
0040104A mov ecx,dword ptr [ebp-0Ch]
0040104D mov dl,byte ptr [ecx]
0040104F mov byte ptr [eax],dl
14:
15: //second code:
16: *a = *b = *c;
00401051 mov eax,dword ptr [ebp-8]
00401054 mov ecx,dword ptr [ebp-0Ch]
00401057 mov dl,byte ptr [ecx]
00401059 mov byte ptr [eax],dl
0040105B mov eax,dword ptr [ebp-4]
0040105E mov ecx,dword ptr [ebp-8]
00401061 mov dl,byte ptr [ecx]
00401063 mov byte ptr [eax],dl

Hmm, eaven though the app crashes,...
Nope, nothing is changed, exept
mov eax,dword ptr [ebp-4]
and
mov eax,dword ptr [ebp-8]

But when taking out the LP and the *s''
this is what it does in ASM:

//first code:
12: a = c;
00401028 mov al,byte ptr [ebp-0Ch]
0040102B mov byte ptr [ebp-4],al
13: b = c;
0040102E mov cl,byte ptr [ebp-0Ch]
00401031 mov byte ptr [ebp-8],cl
14:
15: //second code:
16: a = b = c;
00401034 mov dl,byte ptr [ebp-0Ch]
00401037 mov byte ptr [ebp-8],dl
0040103A mov al,byte ptr [ebp-8]
0040103D mov byte ptr [ebp-4],al


... same changes
so the big answer is

NO!



[ my engine ][ my game ][ my email ]
SPAM

Share this post


Link to post
Share on other sites
It should do. Why not just try it and see? All you need to do is put that code into a console app, compile an optimised EXE and then step to that code in the debugger (stick a break-point on it) and switched to the disassembly view. If the code''s the same for both versions then you have your answer.


Iain Hutchison
Programmer, Silicon Dreams
The views expressed here are my own, not those of my employer.

Share this post


Link to post
Share on other sites
quote:
Original post by pieman
It should do. Why not just try it and see? All you need to do is put that code into a console app, compile an optimised EXE and then step to that code in the debugger (stick a break-point on it) and switched to the disassembly view. If the code''s the same for both versions then you have your answer.


Iain Hutchison
Programmer, Silicon Dreams
The views expressed here are my own, not those of my employer.


Duhh! You think I didnt Just duew that?


sorry...

I have enterprise, so I eaven opt., no, it is EXACTLY the same.
the answer is no. plain and simple.

[ my engine ][ my game ][ my email ]
SPAM

Share this post


Link to post
Share on other sites
//second code:
a = b = c;
00401034 mov dl,byte ptr [ebp-0Ch]
00401037 mov byte ptr [ebp-8],dl
0040103A mov al,byte ptr [ebp-8]
0040103D mov byte ptr [ebp-4],al

THATS AN OPTIMZED CODE!!!!?????
I am not an assembly expert, but I think the following will do the same:

mov dl,byte ptr [ebp-0Ch]
mov byte ptr [ebp-8],dl
mov byte ptr [ebp-4],dl

Even if there is an IRQ, the dl would be saved in a stack, right?
Assembly experts, please tell me if that code is equivalent and more efficient.

Share this post


Link to post
Share on other sites
quote:
Original post by The C modest god
Assembly experts, please tell me if that code is equivalent and more efficient.



Yes they''re the same, but you can''t expect a compiler to optimize every single little nuance of code you can possibly write. Why would you even care, though? I highly doubt that''ll ever be your bottleneck.


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
quote:
Original post by AfTeRmAtH

Duhh! You think I didnt Just duew that?




Your post wasn''t there when I started my reply (look at the time-stamps - they''re 1 minute 11 seconds apart). You submitted your reply while I was typing mine.

Sorry for any offence caused.

Iain

Share this post


Link to post
Share on other sites
I''d tend to agree with Mr. Harding...

If you are really worried about this level of performance - eg 1 less memory reference you need to ask some other questions as well.

eg where is this data in memory? how is it aligned? if it is part of a struct, how is that struct packed? which data types come first in the struct declaration?

what''s the temporal and spatial characteristics of the data that is being processed? what else is done to the data?

How does that affect the L2 and L1 cache?

moving bytes is going to be less efficient then moving 32bit data or aligned 64-bit data



If you''ve already thought about these other issues then you''re all set.
I''d guess that aligning your data and manipulating the caches ( if necessary ) would more overall performance gain.

Although I do agree that reducing memory references is a good thing, but still, its not likely to be a major issue. The source value is in the L1 cache.
The real problem I think is the data hazard - where it writes to a memory address and then re-reads that same memory address.

You are correct, the assembly you wrote would be faster.

I also think, based on the data hazard issue, that the first code *a = *c; *b = *c; might be marginally faster.
I think it actually generates code close to what you would want.

Although it does re-read the value at c, that value is in a L1 cache by its second reference.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!