lkml.org 
[lkml]   [2003]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: gcc 2.95 vs 3.21 performance
    Date
    On 4 February 2003 22:45, Herman Oosthuysen wrote:
    > Hi there,
    >
    > From my experience, the speed issue is caused by misalligned memory
    > accesses, causing inefficient SDRAM to Cache movement of data and
    > instructions.
    >
    > I don't think that you necessarily need a modification to the
    > compiler. What you can do is carefully place the ALLIGN switch in a
    > few critical places in the kernel code, to ensure that the code and
    > data will be properly alligned for whatever processor it is compiled
    > for, be that a Pentium, an ARM, a MIPS or whatever.
    >
    > It would be nice if GCC can be suitably improved to do this correcly
    > for all architectures, but a little bit of human help can do wonders,
    > without having to fork the GCC project.

    NO.

    GCC already went this way, i.e. it aligns functions and loops by
    ridiculous (IMHO) amounts like 16 bytes. That's 7,5 bytes per alignment
    on average. Now count lk functions and loops and mourn for lost icache.
    Or just disassemble any .o module and read the damn code.

    This is the primary reason why people report larger kernels for GCC 3.x

    I am damn sure that if you compile with less sadistic alignment
    you will get smaller *and* faster kernel.
    --
    vda
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:32    [W:3.184 / U:0.288 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site