lkml.org 
[lkml]   [1998]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux-asm (was A patch for linux 2.1.127)
On Sun, 15 Nov 1998, Rogier Wolff wrote:

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

This is an excellent response and I appreciate it. However, my proposal
is to substitute (as a compile-time option) complete procedures
(new files) written in assembly. The current setup makes for difficult
maintainability where inline asm is mixed with 'C' code. To make
it worthwhile, the speed increase must more than compensate for the
increased call overhead. You find a bug, the asm source is not used
until somebody fixes it.


Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.127 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


-
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    [W:0.094 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site