[PD-dev] gcc 4.1 and auto-vectorization

[Hans-Christoph Steiner]

On Nov 17, 2006, at 5:25 PM, Tim Blechmann wrote:

> On Fri, 2006-11-17 at 09:10 -0500, Hans-Christoph Steiner wrote:
>> On Nov 17, 2006, at 7:01 AM, Tim Blechmann wrote:
>>
>>> On Thu, 2006-11-16 at 16:28 -0500, Hans-Christoph Steiner wrote:
>>>> Debian/testing now uses gcc 4.1 as its default compiler.  I just
>>>> noticed when doing the apt-get upgrades.  Has anyone tried the  
>>>> auto-
>>>> vectorization stuff?  Is it worthwhile with Pd?
>>>
>>> you might want to check the archives:
>>> http://lists.puredata.info/pipermail/pd-dev/2006-08/007324.html
>>>
>>> to explain the terms 'alignment' and 'aliasing':
>>>
>>> alignment:
>>> audio blocks are not known to be aligned to 16byte boundaries
>>>
>>> aliasing:
>>> for functions in the form foo(t_sample * a, t_sample * b, int n),  
>>> the
>>> compiler is unable to know if the memory regions of a and b are
>>> overlapping (b may be a+1)
>>
>> Right, I remember that, I was meaning more has anyone tried any
>> benchmarks.
>
> i must admit, but i'm a bit confused ...
> how can an auto-vectorizer, that's known not to have any effect for a
> piece of code improve it's performance?

I really doubt that the gcc devs put a lot of effort into something  
that has no effect. Perhaps not for Pd, that may be true.  But they  
are talking about vectorizing loops, it may not be the best thing to  
vectorize, but there are definitely vectorizable loops in Pd.

I'd say its worth trying.  Compilation optimization is not an  
exercise in pure deduction.  There are too many variables when  
looking at real world performance for humans to know how to program  
for the best performance without testing and profiling.

.hc

------------------------------------------------------------------------

Using ReBirth is like trying to play an 808 with a long stick.    - 
David Zicarelli