Re: No Macros, No for loops, Pure C++
From: Chris Theis (Christian.Theis_at_nospam.cern.ch)
Date: 10/20/04
- Next message: August1: "Re: Windows App - C++"
- Previous message: Catalin Pitis: "Re: a[3} slower than a.x; a.z; a.z"
- In reply to: Steven T. Hatton: "Re: No Macros, No for loops, Pure C++"
- Next in thread: Steven T. Hatton: "Re: No Macros, No for loops, Pure C++"
- Reply: Steven T. Hatton: "Re: No Macros, No for loops, Pure C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 20 Oct 2004 10:31:19 +0200
"Steven T. Hatton" <susudata@setidava.kushan.aa> schrieb im Newsbeitrag
news:QvKdnR2Tu7D2POjcRVn-sw@speakeasy.net...
> Chris Theis wrote:
>
> >
> > "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
> > news:16SdndeDY4mWJuncRVn-3Q@speakeasy.net...
> >> Phlip wrote:
> >>
> > [SNIP]
> >
> >> In some cases compilers can unroll loops without the templates. For me,
> > one
> >> of the advantages of using templates and compile-time construction of
the
> >> data structures is that I can use recursion without paying for it at
> >> run-time. Run-time recursion usually means a lot of dereferencing which
> > can
> >> be expensive (in comparison to loops). Oh, I should add that I have no
> >> pointers either. There are very few conditionals as well.
> >>
> >
> > As always with optimization, care is advisable. In some situations this
> > "manual" loop unrolling might pay off and in others it wonīt. This
depends
> > very much on what youīre doing in the loop, if there might be aliasing
> > effects and so on. In general itīs good practice to profile and decide
> > whether the compilerīs built in optimization is better or the template
> > unrolling.
>
> Can you provide an example of where using template recursion was not as
> efficient as the compilers own optimization?
Giving general examples regarding optimization is always tricky because it
depends on so many things. What I want to stress is that template loop
unrolling is certainly worth trying but it might result in code-bloat and
you might take away the compiler's possibility to optimize the code with its
own loop unrolling procedure. This "built-in" feature heavily relies on the
internal CPU registers and might or might not be more efficient. This
depends very much on the code.
> Also, can you explain what you
> mean by "aliasing effects", and how it might impact object code generated
> from a recursive expression template?
>
Let's take a look at the following function which can be used to set the
values of an array:
void Set( float y[], const float* pArray, int n )
{
for( int i = 0; i < n; i++ )
y[i] = 1.0f - *pArray;
}
Under the assumption that pArray is invariant the optimizer could move the
subtraction out of the loop and everybody is happy. But the user could pass
an address of an element of pArray as the second parameter (e.g., y[10] =
1.0; Set( y, &y[10], 20 ); ).
This means that pArray is not invariant anymore and the compiler cannot
safely move the subtraction to the front. However, you might force the
compiler or at least hint to the compiler that there is certainly no
aliasing-effect and then the built-in loop-unrolling can kick in. Naturally
this should be done with care only. If you use the template approach the
compiler will have a hard time to unroll the loop as it's not there anymore.
Don't get me wrong - I'm not against the template solution and I personally
favor it very much, but one has to decide on a case to case basis after
profiling which way to go. There simply is no general rule.
[SNIP]
>
> It may be possible to define tensors in terms nested vectors of vectors
and
> show them to mathematically equivalent to tensors defined in the
> conventional manner. I haven't thought about it for more than the time it
> took to write this paragraph, so I can't say for sure.
You can implement tensors in terms of vectors but mathematically speaking
its wrong. A vector is by definition a tensor of n=1 order with 3^n elements
and a generic tensor of order n is expressed by 3^n elements. So every
vector is a tensor but not every tensor is a vector and consequently such an
implementation would violate the "is-a inheritance" rule.
Cheers
Chris
- Next message: August1: "Re: Windows App - C++"
- Previous message: Catalin Pitis: "Re: a[3} slower than a.x; a.z; a.z"
- In reply to: Steven T. Hatton: "Re: No Macros, No for loops, Pure C++"
- Next in thread: Steven T. Hatton: "Re: No Macros, No for loops, Pure C++"
- Reply: Steven T. Hatton: "Re: No Macros, No for loops, Pure C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
