5 Replies - 789 Views - Last Post: 21 April 2013 - 01:35 PM

#1 pokiaka  Icon User is offline

  • D.I.C Head
  • member icon

Reputation: 10
  • View blog
  • Posts: 76
  • Joined: 05-August 11

Native optimization by hand - Legit?

Posted 20 April 2013 - 07:48 PM

Hey everyone, here's my question:

I notice that whenever I'm writing applications in C and C++ and look at the disassembly it looks like a mess but not like the mess you see for optimizations (such as interleaving), but a mess that would just take the processor more time to do it's job.

Note: I'm also talking about the disassembly for release builds.

So when I see such detours in my application, naturally I want to fix it, and thank you VC++ developers for the inline-assembler (__asm) that's giving me the opportunity.

But on the other hand there are issues that make me uncertain whether optimizing my application by hand is a good thing.
I'll mention 2 here for the sake of this discussion:

Future releases of the compiler:
Future releases of the compiler could not only fix those detours, but also make the code faster than what I could come up with. If I replace the C/C++ code with my inline-assembly, I wouldn't even know it and just have a slower application than what it could be.

Instructions:
There are those instructions that are so rare that people don't even recognize them, and also future releases of processors could introduce instructions that I wouldn't even know, but the compiler will know and will use.
Although I'm not so sure about that.. for example, why the hell doesn't VC++ use ENTER, LEAVE, RET X?

So the question is:
Should you use inline-assemblers in order to speed up your program?

Note that I'm not talking about writing the assembly for the application or replacing chunks of code. I'm aware that I'm just a human.

Is This A Good Question/Topic? 0
  • +

Replies To: Native optimization by hand - Legit?

#2 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 8379
  • View blog
  • Posts: 31,144
  • Joined: 12-June 08

Re: Native optimization by hand - Legit?

Posted 20 April 2013 - 08:40 PM

Come again - you want to rewrite a compiler then?


Quote

but a mess that would just take the processor more time to do it's job.

The question should be - *IS* it taking longer time in the processor, and if so by how much?
Was This Post Helpful? 0
  • +
  • -

#3 pokiaka  Icon User is offline

  • D.I.C Head
  • member icon

Reputation: 10
  • View blog
  • Posts: 76
  • Joined: 05-August 11

Re: Native optimization by hand - Legit?

Posted 20 April 2013 - 08:48 PM

No, I don't want to rewrite a compiler.
I'm talking about when sometimes the compiler generates instructions in a way that you can rewrite them so much better.
The time can vary but all in all, if that function is being called frequently I wouldn't want even one extra instruction.

The solution would be of course to write the assembly yourself (i.e. if it's a messy call, remove the C/C++ call and write it yourself in the inline-assembler).

Hope I'm clearer now.

This post has been edited by pokiaka: 20 April 2013 - 08:50 PM

Was This Post Helpful? 0
  • +
  • -

#4 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 8379
  • View blog
  • Posts: 31,144
  • Joined: 12-June 08

Re: Native optimization by hand - Legit?

Posted 20 April 2013 - 08:55 PM

Ahuh.. I believe then the problem breaks down to a cost/benefit analysis. As I said - how much time is being lost to the processor by compiler generated instructions that you may think are off? With today's chips I would imagine the time is pretty negligible, and most folks should just opt to roll with what the compiler does. Granted the specific job is 'compiling' and 'optimizing' takes a back seat - it would almost be worth the time to optimize your code up front before you compile.

Of course there's the option of using a different compiler. They all don't shake down the same way, right?

Though getting back to it - does spending thirty extra man hours to rewrite what the compiler spat out worth shaving two clock cycles from processing? Most times I would say - no. Then again my time is pretty valuable to me so I would save the 'write the assembly by hand' as a super duper special case and not part of the normal project work flow. Then gain, that's just me.
Was This Post Helpful? 1
  • +
  • -

#5 GunnerInc  Icon User is online

  • "Hurry up and wait"
  • member icon




Reputation: 856
  • View blog
  • Posts: 2,246
  • Joined: 28-March 11

Re: Native optimization by hand - Legit?

Posted 20 April 2013 - 09:02 PM

*
POPULAR

you need to understand the cpu architecture. just because the compiler outputs more instructions, does not mean it's slower. many cpus can execute more than one instuction at a time, the compilers know this and how to rearrange the instructions. it knows about read/write dependencies on registers and memory and rearrange instructions or add instructions to break these dependencies.

enter is an old slow instruction.
leave is fine, you need to ask the compiler designers why they don't use it.
ret x, well we are talking about c so the standard is for the caller to adjust the stack not the callee. so instead of ret x, you will see add esp, x after the call.

too much more to type on a cell phone.
Was This Post Helpful? 6
  • +
  • -

#6 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 3169
  • View blog
  • Posts: 9,607
  • Joined: 05-May 12

Re: Native optimization by hand - Legit?

Posted 21 April 2013 - 01:35 PM

Unless you are disciple of Steve Gibson (of SpinRite fame), I only see the value of hand optimizing assembly code if it has been proven by a profiler that particular bit of code is a hotspot, and that there is no better algorithm.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1