Related articles |
---|
Effect of pointers etc. sharma@math.tu-berlin.de (1993-03-26) |
Re: Effect of pointers etc. preston@dawn.cs.rice.edu (1993-03-27) |
Re: Effect of pointers etc. paco@legia.cs.rice.edu (1993-03-28) |
Effect of pointers etc. ssimmons@convex.com (1993-03-29) |
Re: Effect of pointers etc. firth@sei.cmu.edu (1993-03-30) |
Newsgroups: | comp.compilers,comp.parallel |
From: | paco@legia.cs.rice.edu (Paul Havlak) |
Keywords: | parallel, analysis |
Organization: | Rice University |
References: | 93-03-105 |
Date: | Sun, 28 Mar 1993 20:01:38 GMT |
sharma@math.tu-berlin.de (Sharma) writes:
>...
>The algorithms contain lots of 2 dimensional arrays (naturally). Now what
>is the cost in terms of hardware of macros such as these
>
>#define DISP1(i,j) *(dispar.disp0 + i*MAX_X0 + j)
>#define DISP(i,j) *(dispar.displr + i*MAX_X0 + j)
>#define DISPold(i,j) *(dispar.disp_old + i*MAX_X0 + j)
If you're using an optimizing compiler, it will be close to impossible
to determine the cost of anything by looking at the source alone. The
cost of each source expression depends on its context in a way too
complicated to account for by hand. For example, even if the use of
pointers limits strength reduction and common subexpression elimination of
the macros, a compiler should be able to do something with the "+ i*MAX_X0
+ j" part, which involves hidden multiplies unless the pointer type is
(char *).
You're better off finding an object-level profiler like qp by Jim
Larus (described in his paper with Thomas Ball in POPL '92). But the best
you can do is to get an exact instruction profile for a program optimized
by one compiler for one machine. Your mileage *will* vary for different
compilers or different hardware.
--paco
--
Paul Havlak Dept. of Computer Science
Graduate Student Rice University, Houston TX 77251-1892
PFC/ParaScope projects (713) 527-8101 x2738 paco@cs.rice.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.