Messages in this thread | | | From | Rick Hohensee <> | Subject | The Kommunity vs. Dick Johnson | Date | Sun, 15 Nov 1998 21:38:41 -0500 (EST) |
| |
I did some poking at Dick Johnson's asm for a checksum routine vs. what gcc produces. I compared his hand coded routine to the checksum function in his codestream C program. I assume it does essentially the same thing as his hand coded version. I snipped out the checksum function, re-named it main(), and declared size_t as an int so it would compile by itself. I don't know x86 assembly at all.
I didn't even run any of the examples. I don't doubt his attractive performance claims. Linus says do what interests you. I'm curious about how complex a machine is required to have a decent Linux platform, and whether the simplest such machine model is at all portable, so my comparison was done with gcc -S, ed, cut, sort and uniq. On my bogus version of his chksum() gcc produced about the same overall quantity of code as Dick did, but the chunks between branch labels were smaller via gcc. Makes sense. -O6 was different than the defaults, but not hugely so, at a glance anyway. Dick's C looked pretty tight to my amateur eye, and performance is not under question here anyway.
The plain gcc and gcc -O6 both produced code using 21 or so different opcodes. Mnemonics, rather. Dick used 27 different instructions. Hmmm. Here's who_used_what....
gcc Dick Johnson no -O
1 adcl 2 adcw 3 addl addl 4 addw 5 andl andl 6 clc 7 cmpl cmpl 8 decl 9 esl 10 incl 11 jbe jbe 12 je 13 jmp jmp 14 jne 15 jnz 16 jz 17 leal 18 movb 19 movl movl 20 movw 21 movzbl 22 movzwl 23 negl 24 nol 25 notl 26 orl 27 popl popl 28 pushl pushl 29 ret ret 30 sarl 31 sbbl 32 shll 33 shrl shrl 34 subl subl 35 testl 36 xorl xorl
This seems like a notable difference, even if the algorithms compared don't do *exactly* the same things. I think it's evident that Dick has a distinctly different style than gcc. The part that interests me is, For the checksum problem, both styles can be accomodated with 36 instructions, and Dick's, which is no doubt closer to the optimum in this case, can be accommodated with only 27.
The hand-asm had about 5 occurences of identical complete instructions, including what was addressed. The gcc stuff had 2. That surprises me. I thought that might be a good optimizer heuristic, but apparently not.
I recognize a few of these mnemonics. Some are obscure to me. How obscure are they to a SPARC/PPC/Arm etc. ? Or is this question moot in light of address mode differences?
Dick has a pleasant README along with the code in question in
boneserver.analogic.com/pub/downloads/linux/linux-asm.tar.gz .
I found the most interesting parts of the README to be some of his comments on his optimization techniques. He, or others, might consider that these techniques can be added to gcc optimization heuristics, or even to gcc C's "C extensions", and that such an effort will give greatest impact to his expertise.
Rick Hohensee http://cqi.com/~humbubba colorg on EFnet IRC #linux chanop cLIeNUX xart kandinski cycluphonics ratioles Md., USA This is your brain on colorg --> (@#*%@#() <---~~~_()()( Any questions?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |