Re: [boost] Accelerating algorithms with SIMD - Segmented iterators and alternatives

Subject: Re: [boost] Accelerating algorithms with SIMD - Segmented iterators and alternatives
From: Smith, Jacob N (jacob.n.smith_at_[hidden])
Date: 2010-10-12 13:30:12

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-
> bounces_at_[hidden]] On Behalf Of Simonson, Lucanus J
> Sent: Tuesday, October 12, 2010 10:03 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Accelerating algorithms with SIMD - Segmented
> iterators and alternatives
> 
> joel falcou wrote:
> > On 12/10/10 18:40, Simonson, Lucanus J wrote:
> >> Having done expression templates and meta programming (including
> >> expression templates for vector primitives) I can honestly say that
> >> I wouldn't want to implement an optimizing compiler as a template
> >> meta-program.  It would be a very tedious and painful task with the
> >> end result being something that is thoroughly impractical due to
> >> long compile times and the impossibility of maintaining it.
> >>
> >
> > Really ? try perusing proto to its fullest, it's not that hard to
> > maintain as soon as oyu have a neat generic package around
> > and use it to geenrate a proper intermediate representation of your
> > code fragment.
> >
> >> It could not compete with the quality and speed of compilers
> >> programmed in C.
> >>
> > Compile time is an expendable ressources, runtime is not.
> 
> Both are expendable.  Compile time goes to developer productivity.  If
> the developer is more productive he will be able to either write more
> functionality or better optimize the runtime performance of the same
> functionality with better algorithms/finer tuning.  Before dismissing
> JIT perhaps you should do some benchmark comparisons?
> 
> There is a pretty big difference between parsing syntax to an
> expression template and doing minor operations on the expression and
> implementing constant propigation and dead code elimination.  I know
> proto can help with the former, but I'm not to keen on using it for the
> latter.  I'm pretty sure we can optimize across expressions at runtime,
> while we can only optimize within expressions at compile time with
> template meta-programming.  You're cutting off quite a bit of
> optimization opportunity by limiting the scope of optimizations to the
> expression level.

While a little awkward to program in, the use of "auto" allows multistatement optimizations. However, unless you want *very* awkward coding, the control flow will always be transparent to a C++ DSEL optimizing library. The hard part of vectorization (and what defeats most compilers) are the complexities inherent in handling control flow; I don't mean simple things like loop unrolling, I'm thinking of loop invariants, loop lifting (commutativity of operations across loops), loop pipelining (distributivity of operations between loops), etc. Even "well behaved" codes for shaders in 3d graphics contexts are very branch-y now-a-days and require sophisticated compilers to allow kernels to fully utilize the hardware.

> Regards,
> Luke
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost