Re: [++] Re: Problems with Hardware, Languages, and Compilers

> > By running two or three of these calculations in parallel, we got rid
> > of nearly all the fp pipeline stalls, resulting in final speedups for
> > his simulations between 30% and 100%.
> >
> > It was quite easy to do this using portable C, so I cannot really see
> > the need to modify either hardware, languages or compilers to realize
> > these kinds of speedups?


Jarkko Hietaniemi wrote:
> You obviously do not live in the same planet as me. Most people do not
> want to change languages, that is, Fortran -> C in most scientific /
> technical codes. Most people do not want even to change their
> code. Most people do not even know there is an -O flag in their
> compiler. They just want to run their code FAST. Ergo, the compilers,
> languages, operating systems, and the hardware must live to server.


Ooops, I forgot to mention one crucial detail:


The original program was written in pure C!


If he had started with Fortran, then my hack would still have been
possible, at least via some misuse of COMMON blocks (or something to
that effect), to be able to cast an IEEE fp value into an array of two
32-bit integers (INTEGER*4, right?)


In that case, it would have been a lot easier (for me) to write it in
assembler instead, but since he started with C, I could make a
portable versions with very close to perfect asm performance.


> BTW: a great speedup.


Thanks, I felt really good about it as well, because I finally managed
to _understand_ Chebychev polynomials, figuring out how to calculate the
optimal polynomial constants.


Terje
--
- <Terje.Mathisen@hda.hydro.com>
[EQUIVALENCE, not COMMON, but close enough. -John]
--

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