[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)
    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


    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

    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.


    (*) 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.... |
    | 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.027 / U:5.648 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site