Alex Perry wrote:
> > 1) Bad idea? Good idea? Why?
>
> * If you use typedefs in a header file that are easy to switch over,
> * so that groups of calculation are consistently done in one mode,
> * and you don't do stuff that would pipeline on a vector machine,
> then it is easy to benchmark the effect. The impact should be small.
This is kind of putting the cart before the horse. You choose the
types to fit the problem, and then deal with performance issues. This
is basically saying "throw doubles at the problem and then see if
moving to floats works". In the case of an FDM, in fact, you're
pretty much stuck with mixed types anyway. Position over the surface
of the earth to ~millimeter precision requires a double. Most other
stuff doesn't.
> > 2) Would this increase execution time?
> >
>
> For most processors, no. The double math pipeline is usually the same
> speed as the single math pipeline. The exception is the altivec unit
> on PPC which only does its magic on singles. However, as I remember,
> GCC does not _currently_ support that unit from generic C source,
> so you wouldn't see the impact of that change.
The same is true of 3DNow! and SSE. They are single precision only.
And I wouldn't hold my breath waiting for compiler support for vector
units. Generating code for these things really requires a human being
that can think of ways to parallelize algorithms -- the C language can
only express procedural concepts. Generating vector code requires the
equivalent of rewriting this:
for(int i=0; i<nFloats; i++) {
array[i] *= 14;
}
with this:
// Just pretend that this is what the syntax would look like, and that
// the array is properly aligned, and that nFloats is a multiple of
// four. The compiler would have to generate stuff to guarnatee that, of
// course.
float four14s[] = { 14, 14, 14, 14 };
for(int i=0; i<nFloats; i+=4) {
VECTOR_MUL_AND_ACCUM(array+i, four14s)
}
This example might look simple, but doing this in the general case is
equivalent to the halting problem. Computer programs have
historically had trouble with that one. :)
Sure, compilers might be able to parallelize an operation or two here
and there and pick up a couple of cycles, but they'll never come close
to really excercising the vector units. The best they can do, IMHO,
is provide a bunch of macros like VECTOR_MUL_AND_ACCUM above in a
portable way. Even that's going to be a pretty herculaen task, given
the differences between CPUs.
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel