lkml.org 
[lkml]   [1998]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux-asm (was A patch for linux 2.1.127)
Date
From
Richard B. Johnson wrote:
>
>
> Verifying ASM code
> Counting C loops for 2 seconds
> Counting ASM loops for 2 seconds
> C routine : 44263
> AS routine : 539274
> Change : 12.18 times faster
> AS clocks : 573 clocks/byte : 0.28
> C clocks : 16017 clocks/byte : 7.82
>

Dick,

In specific cases, you can achieve huge speedups of C code in
assembly. What you do have to take into account however is that
Assembly is much harder to maintain (*), leading to less efficient
algorithms in the long run. That's a benefit that shouldn't be
overlooked.

If you have an application that is really time-critical, you really
should implement everything in C before you start coding in assembly.
Just to make sure that the algorithms are correct before you jump into
the deep assembly "pool".

I once worked on a hard-real-time application. My predecessors had
started writing everything in assembly. I ended up re-coding
everything in C because their implementation was buggy. All those
routines became twice as slow in C than their Assembly counterparts.

There was one exeption: One routine was 35 times slower in C than in
assembly. Moreover, the optimized assembly took about 50% of the
time-budget. Another thing about this routine: My predecessors had
generated 1020 bytes of code, with just a few instructions missing.
Guess what? That pushed the code size beyond the size of the cache....
Anyway, Linux/i386 now has 8000 lines of assembly. That's 4000 in the
math emulation, so that doesn't really count (#). Next there is 2000
in "video.S", which is also special.

That leaves about 2000 lines of assembly among about 1.2M lines of
code in the Linux kernel. The important thing is that Linux will be
somewhere a few years from now. If you start rewriting stuff in
assembly, that will be nice for a year or so (you get the added
performance), but after that someone will need to fix some obscure
bug (and can't find it in the assembly mess).


When IS it "allowed" to do assembly recoding for performance reasons?
I'd say that if you can shave off about 30% of a real-life application
(Not just a benchmark that does the one thing you can optimize over
and over again) then it is worth considering.... If you have a
real-time application that doesn't meet its timing requirements, you
can start optimizing if you can shave off 10% of the total time.

In short, please, don't advocate rewriting (parts of) the linux kernel
in assembly for performance reasons.

Roger.


(*) Well, maybe not for you, but for most of the rest of us it is.
(#) It is VERY performance critical, and it was written 7 years ago.


--
| Most people would die sooner than think.... | R.E.Wolff@BitWizard.nl
| in fact, most do. -- Bertrand Russsell | phone: +31-15-2137555
We write Linux device drivers for any device you may have! fax: ..-2138217

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans