Optimize code size

[Vitor_Boss®]

First of all I wish to tanks for this greatest compiler.
I got started on assembly language, I'm studying some codes, for a test I've copy a code to compare memory bytes and I saw size difference of compiled code, so I'll show the source and compiled one:


How we can see there is a bigger instruction size on memory manipulations. I think 60-80% of any application use memory R/W, this makes the output code 10-30% bigger.
I asked on flat assembler forum and revolution returned me this:

When you access memory using the ESP register you have to use the SIB format for addressing. This is limitation of the x86 instruction design. Using EBP instead of ESP will make the code smaller.

So how the PB code is translated to ASM and is compiled by flat assembler I decided post my doubt here.
This is the code

Code: Select all

Procedure MemCmp(*Source, *Pattern, Length)
!push    ebp
!mov     ebp, esp
cmp     Length, 0h
mov     ecx, *Pattern
mov     eax, *Source
!jnz     loc_count
!XOr     eax, eax ;ProcedureReturn 1
!inc     eax
!pop     ebp
!retn 0ch
!loc_compare:
!mov     dl, [eax]
!cmp     dl, [ecx]
!jnz     loc_return
!inc     eax
!inc     ecx
!loc_count:
dec     Length
!jnz     loc_compare
!loc_return:
!mov     al, [eax]
!xor     edx, edx
!cmp     al, [ecx]
!setz    dl
!mov     eax, edx
!pop     ebp
!retn 0ch
EndProcedure

Thanks in advance.

[Thorium]

Have you tested for speed?
Code size is pretty much irrelevant these days.

You dont need to disassemble the .exe to see what the PB compiler generates. Just run the compiler with "/COMMENTED" and it will not delete the generated ASM file. In there you see what PB lines translate to what ASM code, because it's all commented.

[wilbert]

does c compiler produce a faster code then hand-written assembly?

That depends on your coding skills.
The output of a c compiler never has to be faster since you can always do things the same way the c compiler does or optimize things more.

[Tenaja]

does c compiler produce a faster code then hand-written assembly?

That is like asking if a civic (c compiler) is faster than a ferrari (asm). It all depends on who is at the wheel...

With a skilled programmer, C will NEVER be faster than asm.
With an unskilled programmer, asm could be faster, but it depends on which skills he is lacking.

[c4s]

@wilbert, @Tenaja

Let's see what we have here:

1. Thread is a little older.
2. His post isn't completely on topic.
3. It's his first post.
4. He registered today.
5. Most important: Strange link in signature!

Conclusion: "jacklance" is a spam bot.

[BorisTheOld]

Have you tested for speed?
Code size is pretty much irrelevant these days.

Actually, most user code is irrelevant these days. There's a good reason why today's desktop computers have the computing power of a 1970's super computer - it takes a huge amount of power to do graphics and all the other stuff that today's users demand.

In the 1960's and 70's I spent a lot of time working with IBM mainframe operating systems, and even back then the operating systems burned up 70% of the CPU cycles. Today it's probably around 90%. So unless one's code spends all its time grinding through a loop without calling system code, there's no point even thinking about optimizing it.

I long ago gave up fretting about CPU cycles, and now focus on program structure, functionality, and ease of coding.

[Thorium]

Have you tested for speed?
Code size is pretty much irrelevant these days.

Actually, most user code is irrelevant these days. There's a good reason why today's desktop computers have the computing power of a 1970's super computer - it takes a huge amount of power to do graphics and all the other stuff that today's users demand.

In the 1960's and 70's I spent a lot of time working with IBM mainframe operating systems, and even back then the operating systems burned up 70% of the CPU cycles. Today it's probably around 90%. So unless one's code spends all its time grinding through a loop without calling system code, there's no point even thinking about optimizing it.

I long ago gave up fretting about CPU cycles, and now focus on program structure, functionality, and ease of coding.

It's not irrelevant at all. You can get very big differences if you optimize for speed. I did a byte filter in PB that processes 500MB/s, did the same using ASM with SSE2 and it does process 11GB/s on the same computer.

[xorc1zt]

@BorisTheOld

the os kernel doesn't consume a lot of cpu cycle and calling the os api or your own funcs is likely the same. maybe you are confused by the
os idle loop ?

http://www.mediafire.com/?at5owy4wj4hut

[BorisTheOld]

the os kernel doesn't consume a lot of cpu cycle and calling the os api or your own funcs is likely the same. maybe you are confused by the
os idle loop ?

I'm confused about a lot of things, but not about what goes on inside an operating system.

An OS is more than a kernel and low level hardware drivers. It's all the support libraries and other stuff that isn't part of your own code. In PB terms, it's all the stuff in the general libraries, media libraries, and the OS libraries that these libraries use.

With few exceptions, the average user program is little more than a series of calls to OS and support libraries. When you write some text to a gadget, your request goes on a voyage of adventure that makes your few lines of ASM code seem as a grain of sand in the universe.

Unless an application is truely compute bound, one's time is better spent optimizing a program at the PB source code level. Poor program logic burns up more cpu cycles than a few extra ASM instructions.

[Fred]

Well said.

[Thorium]

With few exceptions, the average user program is little more than a series of calls to OS and support libraries. When you write some text to a gadget, your request goes on a voyage of adventure that makes your few lines of ASM code seem as a grain of sand in the universe.

Unless an application is truely compute bound, one's time is better spent optimizing a program at the PB source code level. Poor program logic burns up more cpu cycles than a few extra ASM instructions.

Many applications are compute bound. The question is just if it runs fast enough or not. If not you optimize it. If the slow code is in a OS library you would not use the OS library but implement your own faster code. No one forces you to use the slow OS librarys, except for hardware access.

Optimizing by using a optimal logic is just the first step in optimizing, it doesnt end there. After that comes parallelizing and specializing of the code in ways that can only be done using ASM in PB.

Saying ASM optimization is useless is wrong on so many levels.

[IceSoft]

Saying ASM optimization is useless is wrong on so many levels.

Well said.

[Tenaja]

With few exceptions, the average user program is little more than a series of calls to OS and support libraries.

This, too, is wrong on many levels. Well, except for the unimaginative. The last two "major" pb projects I have worked on have had very few calls associated with the OS or library. And those two projects were not similar.

When you write some text to a gadget, your request goes on a voyage of adventure that makes your few lines of ASM code seem as a grain of sand in the universe

While this may be true, only very rudimentary programs contain such a low percentage of "original code" vs OS library calls.

[BorisTheOld]

Saying ASM optimization is useless is wrong on so many levels.

I certainly didn't say ASM optimization is useless. I said that certain kinds of compute-bound programs would benefit from ASM optimization, but that for most programs there are better ways of optimizing code.

Customers want programs that operate bug free and to specifications. They don't care that you've worked endless hours to achieve perfection in your code if they can't see any difference in the way the program functions. And they certainly won't pay you extra for your efforts.

Write professional bug free code and optimize it in a cost effective way.

And remember, the trick with optimization is to "choose one's battles".

[electrochrisso]

This link might be related to this subject.
http://lemire.me/blog/archives/2012/07/ ... -worth-it/