flat assembler
Message board for the users of flat assembler.

Index > Main > Optimized to death

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
peter



Joined: 09 May 2006
Posts: 63
peter
Recently I made a small experiment: let's take "Hello, world" program and make it as small as possible (using FASM, certainly). Then compare the assembly code with the code from two free C compilers. You can find the results here:

http://smallcode.weblogs.us/2006/07/26/striving-for-small-code-human-vs-compiler-part-1/
http://smallcode.weblogs.us/2006/07/29/human-vs-compiler-part-2/

It's the first two parts; the next parts will be published soon at my blog. Feel free to comment and ask your questions.
Post 29 Jul 2006, 05:59
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Shouldn't be human vs compiler because we humans still tell the compiler what to do (likewise we tell the assembler what to assemble). I think it would be more logical as asm vs C

Wink

_________________
Previously known as The_Grey_Beast
Post 29 Jul 2006, 16:36
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
URL doesn't work here.

Smallest "hello, world" is pretty pointless anyway.
Post 29 Jul 2006, 16:56
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
f0dder wrote:
Smallest "hello, world" is pretty pointless anyway.
Agreed. I know this always makes C inferior (by the way I like C as a HLL, and asm as a LLL) but it's fun to optimize something. Sure I don't really believe that just because a Hello World is smaller in asm makes it powerful -- there are certainly other factors in asm that make it truly powerful like low-level control and design. Hello World doesn't even utilize special design or low-level thinking or even high-level thinking, it's more of compiler capability. Wink but for some freaks it's fun to tweak their code to smallest possible output
Post 29 Jul 2006, 17:22
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
It's more fun size-optimizing something a bit larger - like 64kb (or 4kb, or even those insane 256byte) intros.
Post 29 Jul 2006, 17:25
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
I also agree here, but note that I said some people prefer to optimize Hello World and other of these things. I won't judge them, I'm no creep Very Happy
Post 29 Jul 2006, 17:28
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Ah, I finally read your page (didn't work before), and it seems nice.
My advice is that you never forget that HLLs like C are still written by humans. We just give the other half of the job to the compiler. In asm, we do all the job.

Let's make some analysis: the C compiler sees our text -- and that's it. He doesn't know ANYTHING else like what algorithm we're using, etc.. so letting it do the other half of the job will certainly not be more optimal than doing it manually. An assembler just reads your text and converts it directly, without guessing like a compiler.

In my opinion it states to the thinking of us humans in BOTH situations: in C you think a bit more high-level (especially if you don't know asm at all), and some of your algorithms and ideas will get skipped by the compiler since it only sees your code (I was reffering to low-level ideas).

in asm you think low-level (if you are experienced, of course), and you design a lot better than if you don't know asm at all and use C or other HLL. The best question to ask somebody who bashes assembly: "How much experience with asm do you have?" and you can also: "Are you truly sure there is ABSOLUTELY no benefit? What if I care about 1 byte, eh?" (okay, the second one was a bit funny Smile ).

"Why do program sizes increase proportionally with the memory size? I just don't see this as a rule. So what if we have 400 GB RAM? This does not imply that I should waste memory." Honest, I've seen people who really make EFFORTS to increase their program's size (like adding nonsense images, of course uncompressed, why would they waste their precious time thinking? they don't deserve that brain Razz), but they actually "waste" their time adding these images. If they really care about their time, why would they add them? Just to increase the size and make it bloated? It's silly. Razz


also, it's nice to see that you removed the run-time library. Glad to see that I'm not the only one who wants to achieve control in C (i.e not lazy enough to let someone else do your work), and also not unnecessary functionality.

Want more feedback? Wink

ps: I know you may call be crazy, but wasting 10 bytes for "unnecessary" functionality is, for me, not a pretty sight. But wasting the same number of bytes for alignment, for example, MAY not necessary seem wrong (if it's, of course, worth the alignment and it's generated speed). I know I seem crazy here, please don't criticize.
Post 29 Jul 2006, 19:21
View user's profile Send private message Reply with quote
peter



Joined: 09 May 2006
Posts: 63
peter
Thanks for your responses.

Quote:
Smallest "hello, world" is pretty pointless anyway.

Yes, it is. My program is just food for your thought, not a real-world example. Optimizing 64Kb intro would take too much time, and I don't have enough motivation for it.

Quote:
He doesn't know ANYTHING else like what algorithm we're using, etc.. so letting it do the other half of the job will certainly not be more optimal than doing it manually.

You can win several bytes in size by using your knowledge of the algorithm. But my point was about generic optimizations, which will benefit for all programs. It's a sort of "Why does not my compiler do this?" Although, you can write faster code than your compiler if you use program-specific optimizations.

Quote:
Why do program sizes increase proportionally with the memory size?

I agree, it is terrible. Many programs are bloated because of large images, gorgeous installers, useless DLLs, etc. For example, compare Acrobat Reader (20 Mb unpacked, AFAIR) with FoxIt Reader (one exe file, 2,5 Mb). FoxIt does the same, but it is 8 times smaller or so.

Quote:
wasting 10 bytes for "unnecessary" functionality is, for me, not a pretty sight

And for me, too. Sometimes MSVC++ does horribly ineffictive things with my C code (e.g., causing store-to-load forwarding issues when passing variables to inline assembly). This makes me crazy, even if it does not affect overall performance. It may be some performance reflex shared by assembly programmers, when you are making your app smaller and faster even if you don't have to do this Smile.
Post 30 Jul 2006, 03:19
View user's profile Send private message Visit poster's website Reply with quote
wisepenguin



Joined: 30 Mar 2005
Posts: 129
wisepenguin
FoxIt would be even smaller if they use the Windows look instead of skinning it to look like Acrobat. Acrobat is 20MB packed, and bigger after
installed. I remember downloading a 20MB acrobat installer.

fair does to people that like the skin, but i prefer programs to use
the Windows look because everything fits in and theres no extra code
to handle the drawing.
Post 30 Jul 2006, 10:39
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The_Grey_Beast: just for a little time-frame, I started programming in the early 90'es, and I did assembly before C/C++ - and I did 32bit assembly in the DOS days. My first computer at home (when my family could finally afford one) was a 486/100MHz, and some of my pascal (yes, that was my first language) programs from then had almost as much assembly as they had pascal code; the machines were slow and compilers inefficient, so it was necessary.

These days machines are (a lot! Wink) faster and compilers are a lot better. I've set a minimum reference machine (PII 350MHz 64meg), and as long as my stuff runs well there, I'm happy, and don't care if people call it bloat or whatever - I pity those people. I do care (a lot) about the code that I write, but I've grown too old to care about micro-optimizing everything. I deal with the hotspots, if any.

I think it's a good idea knowing about machine architecture and assembly, as well as algorithms and high-level languages. The combined knowledge gives you the ability to write better code than someone who knows only one thing (assembly programmer trying to write the fastest bubblesort or putpixel, or theoretical programmer always using the best big-O-notation sort routine, even though bubblesort would be more efficient because of a small dataset).

But there's no way I can be bothered about some 10 bytes of "bloat" anymore. People like _Stone (if anybody remember him) think I'm crazy for thinking about size at all, but I can't help it.

Btw, FoxIt Reader is pretty nice, but it's buggy (crashes sometimes), and it is EXTREMELY slow with complex PDFs.
Post 30 Jul 2006, 20:03
View user's profile Send private message Visit poster's website Reply with quote
Quantum



Joined: 24 Jun 2005
Posts: 122
Quantum
peter wrote:
Why don’t current compilers do that? I can’t find an answer to this question.

Because compilers don't generate the IAT. That's a typical linker's job.

peter wrote:

people saying that “the compiler can almost always generate better assembly than a mere mortal”

A "mere mortal" is able to take a look at the assembly listing the great compiler just generated and procede to improve it. The compiler can't cheat in the same way Wink So, the compiler can't ever beat the human.
Post 30 Jul 2006, 21:45
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
First of all, it's hard to call someone crazy for wanting to write better code. Of course, you don't have to target an old 8088 4.77 Mhz necessarily (25 years old, by now), but at least some optimization effort is appreciated by those of us with similar mindsets.

Anyways, I guess the big lesson is: don't get lazy! Sure, machines are much faster nowadays, but there will always be situations which require smaller/faster code. Remember, not everyone uses 3.8 Ghz, dual-core, 64-bit, 2 GB RAM machines with 128 MB VRAM, plus T3 ? connection (for downloading the 4 GB [eek!] Windows Vista beta??).

My brother is trying to get his A+ certification, and they are teaching him a lot of stuff (even undelete from DOS!) because "it's out there, and you'll have to deal with it" even if they consider some of it outdated.

The big problem seems to be that people say:

  • It takes too much time and effort.
  • The usefulness isn't much (if at all).
  • Dunno how to do it.


Then again, try getting those types of people (who rave about current machines' power) to ignore makefiles and recompile their whole projects every time they make a change, and you'll see them start defending the idea of saving time! Smile
Post 31 Jul 2006, 20:35
View user's profile Send private message Visit poster's website Reply with quote
peter



Joined: 09 May 2006
Posts: 63
peter
Quote:
A "mere mortal" is able to take a look at the assembly listing the great compiler just generated and procede to improve it

But compiler can improve the generated code, too Wink. It's called pipehole optimization, when you take the ready code and improve some small parts of it.

And I didn't improved the compiler's code; I had written my program from scratch (insert some proud smile here Smile.
Post 01 Aug 2006, 01:24
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
I usually optimize only NOT optimized code, because when the code is already optimized to some extent - you won't find some of the possibilities you would have found.

Its like you can't pack a packed file and expect better ratio. You will have a better chance when unpacking the current one and then packing with another algorithm.

When you look at a C code you can't make it much better. There are a few possibilities like disallowing ALL optimizations on the compiler part or just writing yourself Razz

When you optimize an already optimized code - you will most probably end up fixing MOV EAX,0's with XOR EAX,EAX's Very Happy that will most definately mess up the alignment C very carefully set up for you Sad
Post 01 Aug 2006, 10:46
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I pretty much agree with what Madis wrote. If you really want to optimize something, looking at compiler output assembly listing is a bad starting point, since you won't be applying the "assembly mindset".

On the other hand, starting with a C routine isn't that bad an idea, since you can see the algorithmic structure of the code.
Post 01 Aug 2006, 10:55
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Sometimes, the best optimizations aren't in the compiled programs themselves but in the runtime environment. So, you can have the fastest, cpu-specific, optimized program, but if the OS setup isn't tweaked, you'll still be wasting lots of time.

P.S. There are people who are skilled enough to be able to hand-optimize C code itself (here or here), but it seems that type of skill is rare.
Post 01 Aug 2006, 18:33
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
http://www.azillionmonkeys.com/qed/optimize.html :
Code:
    static long abs(long x) {
    long y;
        y = x>>31;    /* Not portable */
        return (x^y)-y;
    }
    


Someone can explain it? I can't see how it really works
Post 01 Aug 2006, 20:23
View user's profile Send private message Reply with quote
Quantum



Joined: 24 Jun 2005
Posts: 122
Quantum
if positive or zero:
y = 0
(x^0)-0 = x

if negative:
y = -1
(x^-1)-(-1) = ~x+1 = -x
Post 01 Aug 2006, 22:10
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
AAAAAAAHHHH, I forgot that ">>" with type long is SAR instead of SHR Razz

Thank you!!
Post 01 Aug 2006, 23:45
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
in assembly:
Code:
; eax is any signed 32-bit number
mov ebx,eax
sar ebx,31 ; This is what fills with 1s or 0s - I tend to forget that Smile
xor eax,ebx
sub eax,ebx
    


I used to think that finding ABS(X-Y) is hard but I managed to make
a code myself that uses a carry trick that in C might be difficult. If one
can convert this code to C - I'd like to see it:
Code:
; eax holds any unsigned 32-bit number
; ebx holds any unsigned 32-bit number
sub eax,ebx ; X-Y
sbb ebx,ebx ; ebx=0 if positive or zero, -1 otherwise
xor eax,ebx ; if ebx=0 then nothing happens, otherwise NOT(eax)
sub eax,ebx ; This does the addition if neccessary -(-1) = 1
;After this eax holds ABS(X-Y)
    
Post 02 Aug 2006, 08:47
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.