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.

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

URL doesn't work here.

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. but for some freaks it's fun to tweak their code to smallest possible output

It's more fun size-optimizing something a bit larger - like 64kb (or 4kb, or even those insane 256byte) intros.

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

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 ).

"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 ), 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.


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?

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.

Thanks for your responses.


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.


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.


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.


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 .

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.

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! ) 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.

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


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 So, the compiler can't ever beat the human.

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!

But compiler can improve the generated code, too . 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 .

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

When you optimize an already optimized code - you will most probably end up fixing MOV EAX,0's with XOR EAX,EAX's that will most definately mess up the alignment C very carefully set up for you

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.

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.

http://www.azillionmonkeys.com/qed/optimize.html :


Someone can explain it? I can't see how it really works

if positive or zero:
y = 0
(x^0)-0 = x

if negative:
y = -1
(x^-1)-(-1) = ~x+1 = -x

AAAAAAAHHHH, I forgot that ">>" with type long is SAR instead of SHR

Thank you!!

in assembly:


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: