Re: gcc 2.95 vs 3.21 performance

[Herman Oosthuysen <Herman@WirelessNetworksInc.com>]

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