|Auto vectorization firstname.lastname@example.org (2008-05-15)|
|Re: Auto vectorization email@example.com (2008-05-20)|
|Re: Auto vectorization firstname.lastname@example.org (=?ISO-8859-1?Q?Roland_Lei=DFa?=) (2008-05-21)|
|Re: Auto vectorization email@example.com (Anton Lokhmotov) (2008-05-23)|
|From:||Anton Lokhmotov <firstname.lastname@example.org>|
|Date:||Fri, 23 May 2008 15:58:06 +0100|
|Posted-Date:||24 May 2008 16:50:34 EDT|
> 1-- How you define the profitability of auto-vectorization phase? Is
> it just the speed up? If we do not get any speed up over scalar code
> then there is no need to do auto-parallelization.
Seems to be right. Since vector instructions typically do more work
than scalar ones, vector code is usually more *power* hungry. However,
if you achieve a considerable speed-up, the overall *energy*
consumption (power * time) can be less than that of scalar
code. (That's why vector instructions are so popular in embedded DSP
> 2--What are the phases or features in a compiler ( especially in the
> GCC) that control the quality of auto-vectorization?
Vectorization is (profitably) applicable to fairly specific code. Loop
restructuring transformations can massage code to a form more amenable
If you are interested, I can send you a pdf of my PhD thesis on
programming and compiling for embedded SIMD architectures, which has a
survey chapter on automatic vectorization techniques.
Return to the
Search the comp.compilers archives again.