Author: Ed Schröder
Date: 13:54:41 01/14/02
Go up one level in this thread
On January 14, 2002 at 13:38:06, Eugene Nalimov wrote:
>On January 14, 2002 at 04:16:54, Ed Schröder wrote:
>
>>On January 13, 2002 at 23:36:19, Eugene Nalimov wrote:
>>
>>>Can you please send me the function that was so badly compiled (probably via
>>>e-mail)? I'd like to find where VC screwed up. It's too late to fix it for VC7,
>>>but probably we can do it for VC7.x.
>>>
>>>Eugene
>>
>>
>>Screwed up is a big word, ASM being being just 30% faster than C is a very good
>>performance I would say. By head I remember the following cases:
>>
>>#1. a=b; c=d;
>>
>>The compiler will output something like:
>>
>>mov EAX,b
>>mov a,EAX
>>mov EAX,d
>>mov c,EAX
>>
>>Wheras it should generate:
>>
>>mov EAX,b
>>mov EBX,d
>>mov a,EAX
>>mov c,EBX
>
>---- File c1.c:
>
>int a, b, c, d;
>
>void foo (void)
>{
> a = b; c = d;
>}
>
>---- File c1.asm (compiled with "cl /Ox /Fa c1.c")
>
>[Some assembly stuff deleted]
>
>_foo PROC NEAR
>; File c:\repro\c1.c
>; Line 5
> mov eax, DWORD PTR _b
> mov ecx, DWORD PTR _d
> mov DWORD PTR _a, eax
> mov DWORD PTR _c, ecx
>; Line 6
> ret 0
>_foo ENDP
That's good.
Very well, but can the compiler for instance recognize:
a = b; x=1; c = d;
and do a good pipe-line job too?
The combinations are endless of course.
>>#2. Always these unavoidable MOVSX and MOVZX instructions. No compiler can
>>optimize this because it is impossible, only the ASM programmer knows what it is
>>allowed under the circumstances.
>
>Sometimes you can use C casts to avoid those... But yes, here assembly
>programmer is definitely better.
>
>>#3. Register use, same story as (2). I for instance use EBP and even ESP when I
>>am short on registers.
>
>VC, of course, use EBP when it decides it's beneficial.
>
>>#4. "char" use in MSVC, for instance: char a1,a2,a3,a4,a5,a6,a7,a8;
>>
>>Will NOT produce the 8 characters as a sequential memory block. So in case I
>>want to zero the 8 bytes I will be forced to write 8 instructions. Some other
>>compilers do generate a sequential memory block so you can redefine a1 and a5 as
>>32-bit and with 2 instructions zero them. This is pretty crucial in a chess
>>program, at least in mine, also because I have to "stack" many stuff when going
>>one ply deeper in the tree or when climbing back.
>
>Never, never, do that on PIII and especially on P4. For the detailed explanation
>look, for example, at "Intel Pentium 4 and Intel Xeon Processor Optimization
>Reference Manual", Section 1-22 "Store Forwarding".
Sounds alarming, my program is polluted with these kind of juicy ASM tricks. Do
you think it is a problem in ASM code too? And maybe you have an URL of the
documentation by hand?
Ed
>Eugene
>
>>#5. Special stuff, no compiler is able to recognize as only the ASM programmer
>>knows. I recently posted an example how to use the "indirect jump" the processor
>>is offering you when for instance generating moves.
>>
>>So it is not about bugs, it is more why no compiler will be ever able to beat an
>>experienced ASM programmer. However I do think that there is space for
>>improvement in the (1) and (4) case, maybe even on (3).
>>
>>Ed
>>
>>
>>
>>
>>>On January 13, 2002 at 18:51:02, Ed Schröder wrote:
>>>
>>>>On January 13, 2002 at 16:29:21, Tom Kerrigan wrote:
>>>>
>>>>>On January 13, 2002 at 07:05:02, Ed Schröder wrote:
>>>>>
>>>>>>I have to disagree, I have a MSVC6 version of Rebel and it runs 30% slower than
>>>>>>the ASM version.
>>>>>
>>>>>What do you attribute this difference to? Is it simply not possible to write C
>>>>>that produces the same assembly as your hand-written code? Or do you take
>>>>>certain liberties in the C code (perhaps in the same of readability?) that's
>>>>>slowing things down?
>>>>>
>>>>>-Tom
>>>>
>>>>Just have a look at the ASM code MSVC6 produces, it often is bad stuff. By
>>>>re-writing (optimizing) this "bad ASM stuff" I got my +30%.
>>>>
>>>>One ambiguous remark, don't believe everthing commercials are telling you :)
>>>>
>>>>Ed
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.