Re: how do a RISC compiler translate an array initialization ?

Sid Ahmed Ali TOUATI <Sid-Ahmed-Ali.TOUATI@inria.fr>
4 Aug 1999 01:17:13 -0400

          From comp.compilers

Related articles
how do a RISC compiler translate an array initialization ? Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (1999-08-02)
Re: how do a RISC compiler translate an array initialization ? zalman@netcom15.netcom.com (Zalman Stern) (1999-08-02)
Re: how do a RISC compiler translate an array initialization ? toon@moene.indiv.nluug.nl (Toon Moene) (1999-08-04)
Re: how do a RISC compiler translate an array initialization ? pmichaud@irisa.fr (1999-08-04)
Re: how do a RISC compiler translate an array initialization ? Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (1999-08-04)
Re: how do a RISC compiler translate an array initialization ? Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (1999-08-07)
| List of all articles for this month |

From: Sid Ahmed Ali TOUATI <Sid-Ahmed-Ali.TOUATI@inria.fr>
Newsgroups: comp.compilers,comp.arch
Date: 4 Aug 1999 01:17:13 -0400
Organization: INRIA
References: 99-08-015 99-08-018
Keywords: architecture, performance

Zalman Stern wrote:


> In comp.arch Sid Ahmed Ali TOUATI <Sid-Ahmed-Ali.TOUATI@inria.fr> wrote:
> : [Sounds like the cache lines are bigger than individual words, and these
> : chips may have a write-behind cache. -John]
>
> He took the cache line behavior into account. (REAL is 8 bytes, 200 of
> them is 50 cache lines for a 32 byte line.)


A real size in an ultra sparc is 4 byte (32 bits). 8 bytes is the real
size in a Dec Alpha.


> More likely the issue has
> to do with how the performance counters work with respect to write
> misses. A quick test is to measure the run time of the loop posted


Using gcc, my original loop has a run time between 5200 cycles and
5300 cycles. The variation is due to the sampling (a sigalarm
interrupt each 1000 msec). When adding the optimisation option -O, the
run time decrease to 2300 cycles.


> and a loop which stores the constant to the same variable over and
> over again. Checking the compiler output of course to make sure the
> stores is not optimized away.


Using gcc, a modified loop that store the constant value to the same
variable (replacing the loop body with "y =12") has a run time between
4062 cycles and 4853 cycles. When I use the option -O of gcc, the run
time is about 700-800 cycles.


So, stores to the array elements are generated because runtime of the
original loop is greater.


> In C/C++ you can declare the variable volatile
> to defeat compiler optimization. I do not know if there is a similar
> mechanism in FORTRAN.


Yes, I saw that when I use gcc, the comment ! volatile appear in the assembly
code after the st without specifying it in the source code and when turning
on the compiler optimization. With fortran, such mechanism doe not appear.
volatile or not, the result was the same ie. no all miss are counted.
Perhaps, write misses are not counted by PCL.


SAAT
====================================================================
e-mail : Sid-Ahmed-Ali.Touati@inria.fr
URL : http://www-rocq.inria.fr/~touati
adresse : Projet A3. Inria-Roquencourt. Domaine de Voluceau, BP 105
                    78153 Le Chesnay cedex France
tel : 01 39 63 58 02
fax : 01 39 63 59 95


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.