Hey everyone,

I'm getting back into C. I have questions about the the preferred
method for looping through an audio vector in a Csound opcode that my
or may not have an impact on the efficiency of of an opcode. Through
the Csound code base, I see basically the two forms:

for (n = 0; n < ksamps; n++) {}

and

do {} while (--n)


At first glance, I would guess the second would more likely be more
efficient, as it would save a comparison. Checking the generated the
asm, it seems the second method does saves a jmp. At the current
moment, I'm not compiling with an optimization flags, so this may save
the jmp with the right setting. Compiling for different processors, as
as using different compilers I'm guessing  could make significant
differences. I myself am using gcc.

Which leads to my n00b questions. How does one balance all these
different variables in compilers, systems and optimization settings to
decide on a set of preferred programming techniques for writing
efficient c dsp?

Best,
Jake
-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Hey everyone,
>
> I'm getting back into C. I have questions about the the preferred
> method for looping through an audio vector in a Csound opcode that my
> or may not have an impact on the efficiency of of an opcode. Through
> the Csound code base, I see basically the two forms:
>
> for (n = 0; n < ksamps; n++) {}
>
> and
>
> do {} while (--n)
>
>
> At first glance, I would guess the second would more likely be more
> efficient, as it would save a comparison. ]

not so.  We measured and the for loop wins significantl;y
Pointer arithmetic is problematic





------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Use the array indexing form:

for (int i = 0; i < size; ++i)
{
    MYFLT x = array[i];
}

There are other forms of coding this loop, but there are none that are faster.

This form is best not only because it is as fast as any other, but
also because it is the easiest to read and understand. It is also the
easiest for static analysis tools to analyze.

All coding standards for critical and high performance software that I
have read, say exactly what I am saying here.

The compiler will take what you write, and optimize it. It is hard to
predict what the machine code compiled from different forms will be.
But the compiler engineers assume that the coder will use the array
indexing form, and therefore they have given the most thought to
compiling and optimizing that form.

I did not take what I read about this for granted. I coded different
forms and timed them, and my measured results agreed with what the
coding standards said.

The other forms of coding array access loops in Csound either are
relics of the old days of less optimization when the other forms
actually were faster, or they were written by people who do not know
what I am saying, or who have a deeply ingrained habit of coding in
other ways.

Regards,
Mike

On Sun, May 6, 2012 at 3:44 PM, Jacob Joaquin  wrote:
> Hey everyone,
>
> I'm getting back into C. I have questions about the the preferred
> method for looping through an audio vector in a Csound opcode that my
> or may not have an impact on the efficiency of of an opcode. Through
> the Csound code base, I see basically the two forms:
>
> for (n = 0; n < ksamps; n++) {}
>
> and
>
> do {} while (--n)
>
>
> At first glance, I would guess the second would more likely be more
> efficient, as it would save a comparison. Checking the generated the
> asm, it seems the second method does saves a jmp. At the current
> moment, I'm not compiling with an optimization flags, so this may save
> the jmp with the right setting. Compiling for different processors, as
> as using different compilers I'm guessing  could make significant
> differences. I myself am using gcc.
>
> Which leads to my n00b questions. How does one balance all these
> different variables in compilers, systems and optimization settings to
> decide on a set of preferred programming techniques for writing
> efficient c dsp?
>
> Best,
> Jake
> --
> codehop.com | #code #art #music
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Exactly. C compilers these days are wondrous programs.

Victor
On 6 May 2012, at 21:48, Michael Gogins wrote:

> Use the array indexing form:
> 
> for (int i = 0; i < size; ++i)
> {
>    MYFLT x = array[i];
> }
> 
> There are other forms of coding this loop, but there are none that are faster.
> 
> This form is best not only because it is as fast as any other, but
> also because it is the easiest to read and understand. It is also the
> easiest for static analysis tools to analyze.
> 
> All coding standards for critical and high performance software that I
> have read, say exactly what I am saying here.
> 
> The compiler will take what you write, and optimize it. It is hard to
> predict what the machine code compiled from different forms will be.
> But the compiler engineers assume that the coder will use the array
> indexing form, and therefore they have given the most thought to
> compiling and optimizing that form.
> 
> I did not take what I read about this for granted. I coded different
> forms and timed them, and my measured results agreed with what the
> coding standards said.
> 
> The other forms of coding array access loops in Csound either are
> relics of the old days of less optimization when the other forms
> actually were faster, or they were written by people who do not know
> what I am saying, or who have a deeply ingrained habit of coding in
> other ways.
> 
> Regards,
> Mike
> 
> On Sun, May 6, 2012 at 3:44 PM, Jacob Joaquin  wrote:
>> Hey everyone,
>> 
>> I'm getting back into C. I have questions about the the preferred
>> method for looping through an audio vector in a Csound opcode that my
>> or may not have an impact on the efficiency of of an opcode. Through
>> the Csound code base, I see basically the two forms:
>> 
>> for (n = 0; n < ksamps; n++) {}
>> 
>> and
>> 
>> do {} while (--n)
>> 
>> 
>> At first glance, I would guess the second would more likely be more
>> efficient, as it would save a comparison. Checking the generated the
>> asm, it seems the second method does saves a jmp. At the current
>> moment, I'm not compiling with an optimization flags, so this may save
>> the jmp with the right setting. Compiling for different processors, as
>> as using different compilers I'm guessing  could make significant
>> differences. I myself am using gcc.
>> 
>> Which leads to my n00b questions. How does one balance all these
>> different variables in compilers, systems and optimization settings to
>> decide on a set of preferred programming techniques for writing
>> efficient c dsp?
>> 
>> Best,
>> Jake
>> --
>> codehop.com | #code #art #music
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Whenever you're looking at performance issues, you should always
compile with the same flags and optimization settings you would use in
production.  Otherwise you're likely to get misleading data, leading
to incorrect conclusions.

What I've read relating to this issue is that using pointers forces
the compiler to make pessimistic assumptions about aliasing, whereas
array indexing allows it to see through that and order the memory ops
more efficiently.  See the "pointers" section of
http://www.futurechips.org/tips-for-power-coders/how-to-trick-cc-compilers-into-generating-terrible-code.html

John L.

On Sun, May 6, 2012 at 9:48 PM, Michael Gogins  wrote:
> Use the array indexing form:
>
> for (int i = 0; i < size; ++i)
> {
>    MYFLT x = array[i];
> }
>
> There are other forms of coding this loop, but there are none that are faster.
>
> This form is best not only because it is as fast as any other, but
> also because it is the easiest to read and understand. It is also the
> easiest for static analysis tools to analyze.
>
> All coding standards for critical and high performance software that I
> have read, say exactly what I am saying here.
>
> The compiler will take what you write, and optimize it. It is hard to
> predict what the machine code compiled from different forms will be.
> But the compiler engineers assume that the coder will use the array
> indexing form, and therefore they have given the most thought to
> compiling and optimizing that form.
>
> I did not take what I read about this for granted. I coded different
> forms and timed them, and my measured results agreed with what the
> coding standards said.
>
> The other forms of coding array access loops in Csound either are
> relics of the old days of less optimization when the other forms
> actually were faster, or they were written by people who do not know
> what I am saying, or who have a deeply ingrained habit of coding in
> other ways.
>
> Regards,
> Mike
>
> On Sun, May 6, 2012 at 3:44 PM, Jacob Joaquin  wrote:
>> Hey everyone,
>>
>> I'm getting back into C. I have questions about the the preferred
>> method for looping through an audio vector in a Csound opcode that my
>> or may not have an impact on the efficiency of of an opcode. Through
>> the Csound code base, I see basically the two forms:
>>
>> for (n = 0; n < ksamps; n++) {}
>>
>> and
>>
>> do {} while (--n)
>>
>>
>> At first glance, I would guess the second would more likely be more
>> efficient, as it would save a comparison. Checking the generated the
>> asm, it seems the second method does saves a jmp. At the current
>> moment, I'm not compiling with an optimization flags, so this may save
>> the jmp with the right setting. Compiling for different processors, as
>> as using different compilers I'm guessing  could make significant
>> differences. I myself am using gcc.
>>
>> Which leads to my n00b questions. How does one balance all these
>> different variables in compilers, systems and optimization settings to
>> decide on a set of preferred programming techniques for writing
>> efficient c dsp?
>>
>> Best,
>> Jake
>> --
>> codehop.com | #code #art #music
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks everyone. Makes much sense. Since we're on the topic of
optimization, does anyone else have any other recommendations for
articles along this line?

Best,
Jake


On Sun, May 6, 2012 at 2:01 PM, John Lato  wrote:
> Whenever you're looking at performance issues, you should always
> compile with the same flags and optimization settings you would use in
> production.  Otherwise you're likely to get misleading data, leading
> to incorrect conclusions.
>
> What I've read relating to this issue is that using pointers forces
> the compiler to make pessimistic assumptions about aliasing, whereas
> array indexing allows it to see through that and order the memory ops
> more efficiently.  See the "pointers" section of
> http://www.futurechips.org/tips-for-power-coders/how-to-trick-cc-compilers-into-generating-terrible-code.html
>
> John L.
>
> On Sun, May 6, 2012 at 9:48 PM, Michael Gogins  wrote:
>> Use the array indexing form:
>>
>> for (int i = 0; i < size; ++i)
>> {
>>    MYFLT x = array[i];
>> }
>>
>> There are other forms of coding this loop, but there are none that are faster.
>>
>> This form is best not only because it is as fast as any other, but
>> also because it is the easiest to read and understand. It is also the
>> easiest for static analysis tools to analyze.
>>
>> All coding standards for critical and high performance software that I
>> have read, say exactly what I am saying here.
>>
>> The compiler will take what you write, and optimize it. It is hard to
>> predict what the machine code compiled from different forms will be.
>> But the compiler engineers assume that the coder will use the array
>> indexing form, and therefore they have given the most thought to
>> compiling and optimizing that form.
>>
>> I did not take what I read about this for granted. I coded different
>> forms and timed them, and my measured results agreed with what the
>> coding standards said.
>>
>> The other forms of coding array access loops in Csound either are
>> relics of the old days of less optimization when the other forms
>> actually were faster, or they were written by people who do not know
>> what I am saying, or who have a deeply ingrained habit of coding in
>> other ways.
>>
>> Regards,
>> Mike
>>
>> On Sun, May 6, 2012 at 3:44 PM, Jacob Joaquin  wrote:
>>> Hey everyone,
>>>
>>> I'm getting back into C. I have questions about the the preferred
>>> method for looping through an audio vector in a Csound opcode that my
>>> or may not have an impact on the efficiency of of an opcode. Through
>>> the Csound code base, I see basically the two forms:
>>>
>>> for (n = 0; n < ksamps; n++) {}
>>>
>>> and
>>>
>>> do {} while (--n)
>>>
>>>
>>> At first glance, I would guess the second would more likely be more
>>> efficient, as it would save a comparison. Checking the generated the
>>> asm, it seems the second method does saves a jmp. At the current
>>> moment, I'm not compiling with an optimization flags, so this may save
>>> the jmp with the right setting. Compiling for different processors, as
>>> as using different compilers I'm guessing  could make significant
>>> differences. I myself am using gcc.
>>>
>>> Which leads to my n00b questions. How does one balance all these
>>> different variables in compilers, systems and optimization settings to
>>> decide on a set of preferred programming techniques for writing
>>> efficient c dsp?
>>>
>>> Best,
>>> Jake
>>> --
>>> codehop.com | #code #art #music
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
h

On my personal Web site I have a post on How to Program:
http://michael-gogins.com/?p=299.

I've found much the same advice in other sources that I have found
helpful or that I respect, including textbooks and good code.

I am trying to distill some of the more detailed aspects of good
programming into a Coding Standard for Csound 6.

Regards,
Mike

On Sun, May 6, 2012 at 5:24 PM, Jacob Joaquin  wrote:
> Thanks everyone. Makes much sense. Since we're on the topic of
> optimization, does anyone else have any other recommendations for
> articles along this line?
>
> Best,
> Jake
>
>
> On Sun, May 6, 2012 at 2:01 PM, John Lato  wrote:
>> Whenever you're looking at performance issues, you should always
>> compile with the same flags and optimization settings you would use in
>> production.  Otherwise you're likely to get misleading data, leading
>> to incorrect conclusions.
>>
>> What I've read relating to this issue is that using pointers forces
>> the compiler to make pessimistic assumptions about aliasing, whereas
>> array indexing allows it to see through that and order the memory ops
>> more efficiently.  See the "pointers" section of
>> http://www.futurechips.org/tips-for-power-coders/how-to-trick-cc-compilers-into-generating-terrible-code.html
>>
>> John L.
>>
>> On Sun, May 6, 2012 at 9:48 PM, Michael Gogins  wrote:
>>> Use the array indexing form:
>>>
>>> for (int i = 0; i < size; ++i)
>>> {
>>>    MYFLT x = array[i];
>>> }
>>>
>>> There are other forms of coding this loop, but there are none that are faster.
>>>
>>> This form is best not only because it is as fast as any other, but
>>> also because it is the easiest to read and understand. It is also the
>>> easiest for static analysis tools to analyze.
>>>
>>> All coding standards for critical and high performance software that I
>>> have read, say exactly what I am saying here.
>>>
>>> The compiler will take what you write, and optimize it. It is hard to
>>> predict what the machine code compiled from different forms will be.
>>> But the compiler engineers assume that the coder will use the array
>>> indexing form, and therefore they have given the most thought to
>>> compiling and optimizing that form.
>>>
>>> I did not take what I read about this for granted. I coded different
>>> forms and timed them, and my measured results agreed with what the
>>> coding standards said.
>>>
>>> The other forms of coding array access loops in Csound either are
>>> relics of the old days of less optimization when the other forms
>>> actually were faster, or they were written by people who do not know
>>> what I am saying, or who have a deeply ingrained habit of coding in
>>> other ways.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Sun, May 6, 2012 at 3:44 PM, Jacob Joaquin  wrote:
>>>> Hey everyone,
>>>>
>>>> I'm getting back into C. I have questions about the the preferred
>>>> method for looping through an audio vector in a Csound opcode that my
>>>> or may not have an impact on the efficiency of of an opcode. Through
>>>> the Csound code base, I see basically the two forms:
>>>>
>>>> for (n = 0; n < ksamps; n++) {}
>>>>
>>>> and
>>>>
>>>> do {} while (--n)
>>>>
>>>>
>>>> At first glance, I would guess the second would more likely be more
>>>> efficient, as it would save a comparison. Checking the generated the
>>>> asm, it seems the second method does saves a jmp. At the current
>>>> moment, I'm not compiling with an optimization flags, so this may save
>>>> the jmp with the right setting. Compiling for different processors, as
>>>> as using different compilers I'm guessing  could make significant
>>>> differences. I myself am using gcc.
>>>>
>>>> Which leads to my n00b questions. How does one balance all these
>>>> different variables in compilers, systems and optimization settings to
>>>> decide on a set of preferred programming techniques for writing
>>>> efficient c dsp?
>>>>
>>>> Best,
>>>> Jake
>>>> --
>>>> codehop.com | #code #art #music
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> codehop.com | #code #art #music
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Interesting link. Maybe we should be looking at placing the restrict keyword in strategic places to coerce the compiler into vectorizing code.
On 6 May 2012, at 22:01, John Lato wrote:

> Whenever you're looking at performance issues, you should always
> compile with the same flags and optimization settings you would use in
> production.  Otherwise you're likely to get misleading data, leading
> to incorrect conclusions.
> 
> What I've read relating to this issue is that using pointers forces
> the compiler to make pessimistic assumptions about aliasing, whereas
> array indexing allows it to see through that and order the memory ops
> more efficiently.  See the "pointers" section of
> http://www.futurechips.org/tips-for-power-coders/how-to-trick-cc-compilers-into-generating-terrible-code.html
> 
> John L.
> 
> On Sun, May 6, 2012 at 9:48 PM, Michael Gogins  wrote:
>> Use the array indexing form:
>> 
>> for (int i = 0; i < size; ++i)
>> {
>>    MYFLT x = array[i];
>> }
>> 
>> There are other forms of coding this loop, but there are none that are faster.
>> 
>> This form is best not only because it is as fast as any other, but
>> also because it is the easiest to read and understand. It is also the
>> easiest for static analysis tools to analyze.
>> 
>> All coding standards for critical and high performance software that I
>> have read, say exactly what I am saying here.
>> 
>> The compiler will take what you write, and optimize it. It is hard to
>> predict what the machine code compiled from different forms will be.
>> But the compiler engineers assume that the coder will use the array
>> indexing form, and therefore they have given the most thought to
>> compiling and optimizing that form.
>> 
>> I did not take what I read about this for granted. I coded different
>> forms and timed them, and my measured results agreed with what the
>> coding standards said.
>> 
>> The other forms of coding array access loops in Csound either are
>> relics of the old days of less optimization when the other forms
>> actually were faster, or they were written by people who do not know
>> what I am saying, or who have a deeply ingrained habit of coding in
>> other ways.
>> 
>> Regards,
>> Mike
>> 
>> On Sun, May 6, 2012 at 3:44 PM, Jacob Joaquin  wrote:
>>> Hey everyone,
>>> 
>>> I'm getting back into C. I have questions about the the preferred
>>> method for looping through an audio vector in a Csound opcode that my
>>> or may not have an impact on the efficiency of of an opcode. Through
>>> the Csound code base, I see basically the two forms:
>>> 
>>> for (n = 0; n < ksamps; n++) {}
>>> 
>>> and
>>> 
>>> do {} while (--n)
>>> 
>>> 
>>> At first glance, I would guess the second would more likely be more
>>> efficient, as it would save a comparison. Checking the generated the
>>> asm, it seems the second method does saves a jmp. At the current
>>> moment, I'm not compiling with an optimization flags, so this may save
>>> the jmp with the right setting. Compiling for different processors, as
>>> as using different compilers I'm guessing  could make significant
>>> differences. I myself am using gcc.
>>> 
>>> Which leads to my n00b questions. How does one balance all these
>>> different variables in compilers, systems and optimization settings to
>>> decide on a set of preferred programming techniques for writing
>>> efficient c dsp?
>>> 
>>> Best,
>>> Jake
>>> --
>>> codehop.com | #code #art #music
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> 
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net