lkml.org 
[lkml]   [2003]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: gcc 2.95 vs 3.21 performance
    Hi there,

    More than anything else, the execution speed on modern processors seem
    to be a factor of code and data allignment. Some processors are OK with
    16 bit word allignment, other require 32 bit word allignment and the new
    crop of processors will probably require 64 bit word allignment.

    If the data accesses are not alligned for your type of processor, then
    SDRAM accesses go to hell as the bursting gets upset.

    Unfortunately, this is a factor of processor architecture and the MS and
    Intel compilers support a small number of processors and can therefore
    be more easily optimized than GCC, which supports every processor in the
    whole world.

    If some application of yours is very speed sensitive, then you'll have
    to insert specific allignment control switches/pragmas to force GCC to
    do things the right way for speed, but that will typically increase the
    code and data size a little.

    Cheers,
    --

    ------------------------------------------------------------------------
    Herman Oosthuysen
    B.Eng.(E), Member of IEEE
    Wireless Networks Inc.
    http://www.WirelessNetworksInc.com
    E-mail: Herman@WirelessNetworksInc.com
    Phone: 1.403.569-5687, Fax: 1.403.235-3965
    ------------------------------------------------------------------------


    P@draigBrady.com wrote:
    > Helge Hafting wrote:
    >
    >>Padraig@Linux.ie wrote:
    >>[...]
    >>
    >>
    >>>Interesting. I just noticed that I get 50% decrease in
    >>>the speed of my program if I just insert a printf(). I.E.
    >>>my program is like:
    >>>
    >>>printf()
    >>>for(;;) {
    >>> do_sorting_loop_test();
    >>>}
    >>>
    >>>If I remove the initial printf it doubles in speed?
    >>>I assume this is some weird caching thing?
    >>
    >>
    >>Looks like a cacheline alignment issue to me.
    >>This loop of yours occupy x cachelines on your cpu,
    >>moving it in memory by adding the printf
    >>might cause it to ocupy x+1 cachelines.
    >>That might be noticeable if x is a really small number,
    >>such as 1.
    >
    >
    > OK it is (as I suspected and as you explained nicely)
    > related to the cachelines on my CPU (866 celery).
    >
    > ===============================
    > GCC options loops/s
    > ===============================
    > gcc 2283
    > gcc -O3 -falign-loops=2 3451
    > gcc -O3 -falign-loops=4 3443
    > gcc -O3 -falign-loops=8 7045
    > gcc -march=i686 -O3 9101
    > ===============================
    >
    > cheers,
    > Pádraig.
    >
    > -
    > 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/
    >



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