will it cause slower if

Index > Main > will it cause slower if

Author

Thread

l4m2

Joined: 15 Jan 2015
Posts: 674

l4m2 30 Jul 2016, 04:27

Code:

mov eax, edx
xor edx, edx

was written into

Code:

xchg eax, edx
xor edx, edx

30 Jul 2016, 04:27

comrade

Joined: 16 Jun 2003
Posts: 1150
Location: Russian Federation

comrade 30 Jul 2016, 04:46

First seems better: it does not create a write dependency on edx that conflicts with xor edx,edx.

30 Jul 2016, 04:46

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 30 Jul 2016, 09:19

Well in that case I personally would prefer:

Code:

xor eax,eax
xchg eax,edx

30 Jul 2016, 09:19

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20333
Location: In your JS exploiting you and your system

revolution 31 Jul 2016, 02:37

comrade wrote:

First seems better: it does not create a write dependency on edx that conflicts with xor edx,edx.

For modern Intel CPUs it won't matter because "xor reg,same_reg" is internally optimised to know that there is no dependency on any previous register value.

So once again we have, as usual, a case where the question "is X better than Y?" has no answer. It depends upon what system is in use and what it is actually doing.

31 Jul 2016, 02:37

JohnFound

Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria

JohnFound 31 Jul 2016, 06:40

For me the first is also, more clear as code and this way is still "better".

31 Jul 2016, 06:40

sinsi

Joined: 10 Aug 2007
Posts: 789
Location: Adelaide

sinsi 31 Jul 2016, 07:09

Small optimisation: XCHG is a one byte opcode, MOV is two.

31 Jul 2016, 07:09

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20333
Location: In your JS exploiting you and your system

revolution 31 Jul 2016, 08:38

sinsi wrote:

Small optimisation: XCHG is a one byte opcode, MOV is two.

But might cause a following jump destination to be unaligned, so maybe not an optimisation in all cases.

Code:

  xchg eax, edx
  xor edx, edx
some_label:   ;<--- this might be at 0x1f mod 0x20 and/or cross a page boundary
  ;code
  jnz some_label

Compared to:

Code:

  mov eax, edx
  xor edx, edx
some_label:   ;<--- now aligned at 0x00 mod 0x20 bcause "mov" is one byte longer
  ;code
  jnz some_label

Last edited by revolution on 31 Jul 2016, 12:00; edited 1 time in total

31 Jul 2016, 08:38

l4m2

Joined: 15 Jan 2015
Posts: 674

l4m2 31 Jul 2016, 09:44

When I say "which is better", I usually mean "In what case is the first better, the second better, etc.
XCHG saves a byte. If the code rarely executed, it won't make too much bad on speed but a little save on memory Smile

31 Jul 2016, 09:44

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20333
Location: In your JS exploiting you and your system

revolution 31 Jul 2016, 10:14

l4m2 wrote:

If the code rarely executed, it won't make too much bad on speed ...

If the code rarely executed then don't worry about it. Find the hot-spots first and "optimise" those. 10% effort will get you 99.9% of the way there if you "optimise" the most used parts.

Note: "optimise" is of course ambiguous. It will mean different things to different people, and also different things to the same person in different places.

31 Jul 2016, 10:14

l4m2

Joined: 15 Jan 2015
Posts: 674

l4m2 31 Jul 2016, 12:12

revolution wrote:

If the code rarely executed then don't worry about it.

If you only care about speed, no worry for rarely-executed code. If size cared about, you should shorten it.

31 Jul 2016, 12:12

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20333
Location: In your JS exploiting you and your system

revolution 31 Jul 2016, 12:18

l4m2 wrote:

If size cared about, you should shorten it.

Using fewer bytes in code is perhaps the only unambiguous measurement of "optimised" code. If this is always what you mean when you ask for "optimised" or "better" code then perhaps you would get answers that help you if you were to state that you actually want code with fewer bytes. Smile

But your title in this thread asks clearly "will it cause slower if", which is a reference to speed. So now we are not sure what you really want. Question

Last edited by revolution on 31 Jul 2016, 12:56; edited 1 time in total

31 Jul 2016, 12:18

l4m2

Joined: 15 Jan 2015
Posts: 674

l4m2 31 Jul 2016, 12:45

Obviously XCHG is 1 byte shorter. If we only care about size that's an optimize. However, if it makes slower, shouldn't use it as optimize when more attention to speed.

31 Jul 2016, 12:45

El Tangas

Joined: 11 Oct 2003
Posts: 120
Location: Sunset Empire

El Tangas 31 Jul 2016, 16:14

Obviously, the best way is:

Code:

mov eax,1
mul edx

31 Jul 2016, 16:14

shutdownall

Joined: 02 Apr 2010
Posts: 517
Location: Munich

shutdownall 01 Aug 2016, 15:23

revolution wrote:

sinsi wrote:
Small optimisation: XCHG is a one byte opcode, MOV is two.
But might cause a following jump destination to be unaligned, so maybe not an optimisation in all cases.

And how are you sure that the code has been aligned before reaching this instruction part ? Maybe the single byte opcode creates that desired alignment. Razz

01 Aug 2016, 15:23

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20333
Location: In your JS exploiting you and your system

revolution 01 Aug 2016, 15:25

shutdownall wrote:

revolution wrote:

sinsi wrote:
Small optimisation: XCHG is a one byte opcode, MOV is two.
But might cause a following jump destination to be unaligned, so maybe not an optimisation in all cases.

And how are you sure that the code has been aligned before reaching this instruction part ? Maybe the single byte opcode creates that desired alignment.

I'm not sure at all. Which is why I said "might". Of course any alignment can be either good or bad depending upon the circumstances. And this is why these questions have no definitive answer, there are too many unstated and unknowable variables.

01 Aug 2016, 15:25

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum