Re: Inline assembler reference
- From: "David J. Craig" <Dave@xxxxxxxxxxxxx>
- Date: Wed, 31 May 2006 20:44:42 -0700
I would say that normally it takes a 30% improvement for it to be noticeable
to the user unless you are talking about runtimes in tens of minutes.
Anything less is not significant enough to be impressive except for the
"benchmarks are gold" group. True, the cumulative inefficiencies of the OS
and other software keep eating up the gain in processor and disk speed so in
many ways our systems are not any faster than an old 286 system. There are
a lot of more features in most software that we use, but the basic
functionality that most of us use is not any faster. How fast can you type?
Can the screen keep up with what you are typing? It couldn't with an old
CP/M system with WordStar and a 80 words per minute typist. I am only about
60 WPM, so it wasn't too bad.
"Shawn B." <leabre@xxxxxxxx> wrote in message
news:eb1P3EQhGHA.3916@xxxxxxxxxxxxxxxxxxxxxxx
Everything really depends on the reason why people use inline assembly.
When
I hear that the main reason is "speed", normally I just laugh.
Performance
improvement can be the reason for using inline assembly only in case if
you
use it in the code that may run at IRQL >=DISPATCH_LEVEL and/or while
interrupts are disabled - otherwise, performance improvement (if any - as
both you and Skywing have properly pointed out, it may result in
slowdown,
rather than improvement) is just negligible.
You make the assumption that we notice that performance isn't all it can
be and then we use inline and then voila, we just believe that magically
performance has been improved.
In all the times where I've used inline assembly to improve performance it
has been under the microsope of a profiler and other performance related
testing techniques. I have never released something that had less
performance after using inline assembly than it did before I used inline
assembly.
Usually, for a few nano/milliseconds I may not even bother, depending on
where the bottleneck is. If the bottleneck is all IO and user related,
then using assembly really isn't always justified. But if its in a
critical loop of an important calculation, than hand-optimization
SSE*/MMX/Floating point instructions (MMX doesn't count on 64-bit Windows)
I've always been able to do both better than the compiler and the
intrinsics the compiler vendor provides. And even if it made performance
for the rest of the function worse off, the net gains were still better
than before the hand-optimizations. I would have to design the innerloops
differently if the entire function/module had to be coded in assembly and
linked in during compile time. I'd rather not do that if its is
avoidable.
I've never written a device driver so I have no idea what kinds of
performance implications there might be... and yes, I realize this is a
kernel related newsgroup. But at the application level, my hand
optimzations (inlining assembly) on the 32-bit compiler has always net
gained me better performance by 10-150% than not hand optimization and
than than intrinsics, depending on what it is I'm doing.
I suppose it's because when inlining assembly, I can make certain
assumptions that the compiler would never know how to make and it works in
my favor. But for a critical loop, even 10% performance gain is
appreciable, any more than that is just icing on the cake.
I would never release something that has worse performance after
hand-optiming than without.
Thanks,
Shawn
.
- References:
- Re: Inline assembler reference
- From: Shawn B.
- Re: Inline assembler reference
- Prev by Date: Re: Inline assembler reference
- Next by Date: Re: Inline assembler reference
- Previous by thread: Re: Inline assembler reference
- Next by thread: Re: Inline assembler reference
- Index(es):
Relevant Pages
|
