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