Re: which way is faster?
- From: //\\\\o//\\\\annabee <w@xxxxxxxx>
- Date: Fri, 11 Jan 2008 01:07:33 +0100
På Thu, 10 Jan 2008 15:14:59 +0100, skrev Wolfgang Kern <nowhere@xxxxxxxx>:
Wannabee skrev:
...
ADD [mem],... is a good example of a READ-MODIFY-WRITE sequence,
and it is faster than its discrete replacement:
MOV eax,[var1]
MOV ebx,[var2]
ADD eax,ebx
MOV [var1],eax
is much slower than:
MOV eax,[var2]
ADD [var1],eax
I mean, single core amd64.
8 cycles I read, inclusive, Using your previously posted technic.
However, there is a diffrence, when changing
variables such as length of timed code, the weather outside,
if the window is open, or having taken a leak before timing,
eg. doing it twice (code just doubled) and the last variant wins by
the magnificent 1 cycle.
A gigantic win :D
And now try it again with the two variables (let's say 4KB) apart
from each other ...
Ok. But this is either
a) a pagefault,
b) a cachemiss
and doesnt relate to instruction sequence or the CPU?
A pagefault I have messured is in the 2000 cycle range.
A cachemiss, maybe as much as 100 or less cycles?
Lets say the 8 cycles are overhead?
:D
(K7 reads 0F cycles - for both, inclusive)
Sure, but only if the two vars share one cache line.
my K7 shows only 8 cycles for the first and 4 cycles for the shorter,
I haven't compared it on AMD64 yet, but it should be equal here.
Why do you give advice on codeoptimization,
Because of the question in the topic ? :)
when it is appear
to me so utterly useless in the real life? If your strategy is not
100% correct at the start of coding, you will have to repeat you rigorous
coding when you rewrite, and you have to TIME EACH CHANGE.
No, I mainly use the info from the manuals beside experience when
I modify or write my code and compare the speed of a whole
function with what I previously noted for it after finished.
ok. I was more or less convinced you allways wrote 100% optimized code,
that you fitted each instruction to the entire sequence.
btw, what is it with you and the stack? It is sometimes helpful you know
for temporary data. Did you once have a terrible experience with it? :D
Its allmost as you treat the stack as if some sort of evil monster.
Given the errors I see I make each time I do that, and then I need to
re-verify my assumtions at least tree times,
and even then I am not sure I got everything right.....
I think learning ASM instruction together with timing issues
helps a lot on the later work.
Would it not be more fruitful to post more on the strategy of things?
My stategy is 'small/fast/smart', so often just a compromise.
Does anyone really need a fast hexstring to binary routine?
Very fast typers perhaps?
Application code contain many small code parts and 'a few wasted cycles'
here and there may not look 'that' relevant.
But the effect is of multiplying nature ...
Agree. When things gets generalized, as rules. And then forgotten.
But I must say that with so few registers, and two allways occupied,
the stack is rather handy for temporal data. It also sometimes makes the code
less bloated. (eg, more clean looking, i belive, espesially if it is part of a long sequence
of a complicated stateful monster)
Why not post something interessting about AI? You once said that
the main reason that AI was not advanced more, was that ppl wore
"not that bright". Would love to read something you wrote that
conserns AI.....
I just played around with several ideas, but there is no AI-project
on my table yet.
So even some of my OS-features may look like AI, this are all just
automated configuration adjustments on track keeping of users typing
speed or count how often he hit BS,DEL in a text-session and respond
with a funny message if this exceeds his average count per page.
:) Hex version of that Word feature Beth used to talk about?
Codeoptimizations are, as Betov said a hundred times, one of the
ill-arguments that work against the assembly community, because
assembly is mostly viewed to have a purpose for this kind of thing.
(Which must be viewed as a very weak argument I figure)
Whats your thoughts on that?
As above, the multiplying effect ...
An ASM-programmer who is aware of timing and instruction size
will always write fast and short code.
nearly all my cycles are taken by drawing.
even writing a single char to a graphic screen cost more then counting
the entire string.
For the 100th time I like to repeat that all the problems I have comes
from finding solutions to problems, and not with asm itself.
IF problem CAUSE problem ITERATE IF ??
if you can't 'find' a solution then create one ;)
:) I mean finding out / discovering solutions is where _my_ cycles go.
You cannot create a solution until the problem is propperly mapped.
So finding it out, is a needed part of the "creating", imo.
__
wolfgang
.
- Follow-Ups:
- Re: which way is faster?
- From: Wolfgang Kern
- Re: which way is faster?
- References:
- which way is faster?
- From: shikamuk
- Re: which way is faster?
- From: Wolfgang Kern
- Re: which way is faster?
- From: //\\\\o//\\\\annabee
- Re: which way is faster?
- From: Wolfgang Kern
- which way is faster?
- Prev by Date: Re: how do you start learning assembly language
- Next by Date: Re: which way is faster?
- Previous by thread: Re: which way is faster?
- Next by thread: Re: which way is faster?
- Index(es):
Relevant Pages
|
