> perhaps conditional compilation, with each binary incorporating
> only the routines it needs for that length, could reduce the code
> footprint and help performance
It can help if it makes it possible for the compiler to eliminate jumps
and branches that way.
> Or perhaps the compiler and OS already do a good job at keeping only
> needed program segments in cache, in which case the problem lies yet
> elsewhere.
Usualy.
> One other possibility is that the SPARC f90 compiler, being *much*
> younger than the (apparently very good) C compiler, has better
> support for the v8 and v9 instruction sets, i.e. they didn't put
> as much work into including optimizations for older CPUs - I don't
> know.
A compiler is normaly built of several separate parts:
The frontend:
o Lexical analyzer, syntax analyzer and semantic analyzer
- Usualy tightly coupled and allways language specific. This is
the frontend, or the parser.
o Intermediate code generator
- Takes a syntax tree from the parser and makes intermediate code
on a simple format -- simple to produce and simple to make
machine code from. Some optimiziations are practical to do here
(some things are easier to detect from the syntax tree than from
the intermediate code) but most of it is left for the next step.
The backend:
o Code optimizer
- Optimizes the intermediate code in several passes.
o Code generator
- Outputs the actual code for the specific platform.
As you can see it is by design very easy to use the same backend for
different languages and opposite, so I doubt that Sun is developing
separate backends for different languages. They only need to adjust
the frontend to create working intermediate code from a Fortran
program, and leave the rest to their already working backend. To
support another CPU they only need to change the backend to optimize
and create code for that CPU. A lot of the optimizing is also CPU
independant.
A quick but closer look at how a compiler works and optimizations are
done is chapter 14 of "Using and Porting GNUS CC" by Richard Stallman.
> We also could use help from any SPARC employees familiar with the
> compiler technology to tell us why the f90 -xprefetch option is
> so unpredictable - it speeds some runlengths by up to 10%, but more
> often causes a 10-20% slowdown (or no change).
I'm not a SPARC employee, but I have some credits in graduate level
compiler technology. 8-)
Prediction is often very hard to do in a compiler. Perfect register
allocation is practicaly impossible. You can try and in most cases
get a very good result, but not perfect. If you try too hard and guess
wrong a few places, you may as well end up doing the oposite of
optimization.
For the compiler it might look like you need a chunk from the memory in
only a short time, and it is "smart" and prefetches everyting well ahead.
It might even allocate registers for the data, while the CPU gets time to
predict the next branch. Very smart when it works. In reality, however,
oposite to what the compiler predicted, you might loop around 1000 more
times before you take the other branch. Because the compiler was wrong,
you have lost some registers and some data you needed were lost from the
cache and filled with data you don't need until you've looped 1000 times
more.
The only secure way to get this right is to use good profiling feedback
which can record information of how often each variable and constant is
needed, find patterns in how the program accesses what memory, where
branches tend to go, etc, and then use this information to optimize
register allocations, prefetching, etc in a second pass trough the
compiler.
To people specialy interested in performance on Sun, I can recommend
chapter 2 of the whitepaper "Delivering Performance on Sun: Optimizing
Applications for Solaris", which is availiable here:
PostScript: http://www.sun.com/workshop/whitepapers/sol-app-perf.ps
Acrobat: http://www.sun.com/workshop/whitepapers/sol-app-perf.pdf
You shold also install the latest patches from Sun. There are alot for
f90: <URL: http://access1.sun.com/workshop/current-patches.html>
--
Sturle URL: http://www.stud.ifi.uio.no/~sturles/
~~~~~~ This will end your Windows session.
Do you want to play another game?
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
