Re: Efficiency
- From: "Wolfgang Kern" <nowhere@xxxxxxxx>
- Date: Sat, 27 Oct 2007 16:13:57 +0200
"KJH" wrote:
Let's say I want to write compact and fast code.
I'm thinking about something like this:
; proc returns ZF set if char is 'a' or 'z'
myproc proc
cmp al,'a'
je @@1
cmp al,'z'
@@1: ret
myproc endp
compared to C version:
int myfunc(int c)
{
if (c == 'a' || c == 'z')
return 1;
return 0;
}
The main speed penalty here (in both variants) is the call/ret pair anyway.
I don't know how C will compile this, but I think it uses 32-bit for 'int'.
If the C version is measurable faster, then it probably avoids the 'je'.
What is the penalty? Okay, these are very basic and small routines,
but I guess that modern C compilers are more aware about optimal
alignment and also it seems that modern Pentiums and above really like
their instructions more RISC-like (aka boring instr set).
Look at Intel and AMD optimisation guides (they are a bit different).
I am used to instructions like lodsb, stosb, inc, dec etc... I'm
adapted to that kind of mental image, lodsb for example in my mind is
a very convenient instruction to load a byte from memory pointed by
DS:ESI. I can visualize it. Also loop instruction is nice, it's
compact (in a conceptual way), but I don't know...
Why is it so that nowadays:
mov eax,[esi]
mov [edi],eax
is more efficient than
lodsd
stosd
? I just don't get it.
This old short-cut instructions may work fine within large REP loops,
but they are awful slow compared to its discrete replacement on single
actions. It's just a matter of (the 'new' simplified) CPU-design.
So all this convenient but complex instructions may disappear in next
CPU-generations and are just merged in for downward compatibility yet.
But to my actual question, is it likely that I'm going to take a speed
hit or cache misses by using these old asm constructs vs. more modern
C-like constructs? Code compactness doesn't necessarily translate to
speed, no?
Right, NO.
Short code doesn't always mean speed gain, especially if instructions
are used which the designers think that they become obsolete soon.
Hopefully somebody can make some sense what I'm talking about, I'm not
sure if I express myself clearly :)
I think to understand your question :)
__
wolfgang
.
- References:
- Efficiency
- From: KJH
- Efficiency
- Prev by Date: Re: Slow nasm
- Next by Date: Re: Skybuck's Wolfram (Turing-Like) Machine implementation
- Previous by thread: Re: Efficiency
- Next by thread: Slow nasm
- Index(es):
Relevant Pages
|
