>>>>> "Michael" == Michael Rhoades <mrhoades@perceptionfactory.com> writes:

 Michael> Thanks for pointing this out Steven, it was very interesting.
 Michael> It brings to mind a question that occurs to me from time to time... In
 Michael> the interview, Barry talks about having his own version of Csound that
 Michael> he works with. That idea is intriguing because, though I greatly
 Michael> appreciate the fantastic bells and whistles provided by Csound 6, the
 Michael> implementation of arrays comes to mind, the main reason I use it is
 Michael> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
 Michael> of the tools I require as a composer. So the question is... has any
 Michael> thought been put into making a "stripped down" version of Csound that
 Michael> has a focus more upon efficiency than upon additional features? Maybe
 Michael> there would not be a performance gain achieved by reducing the
 Michael> features... I am not qualified to know that but it seems possible. If
 Michael> this stripped down version of Csound were constrained to the features
 Michael> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
 Michael> could there be a performance gain?

There are two aspects to performance, CPU and memory.

Regarding CPU we have tried to optimise Csound in recent versions, and
I suspect Barry's code is less efficient, unless he has rewritten much
of it.  Last time I saw his code it used pointer arithmetic which was a
good idea at the state of compilers in the 1980/90 era, but index
arithmetic is faster, and we largely moved to that.

Memory use is more of an issue for small devices, and each opcode uses
code size even if not used -- unless in a plugin.  The lack of dynamic
loading on some mobile devices as led to a larger footprint that I (me
personally) would like.  There is also a small penalty on startup with
having more opcodes and possibly a very small one in parsing.  In perf
time I doubt there is an effect.

So if you really want a lightweight csound you need to move opcodes
into plugins again and just not load them.  Sounds like a student
project to me, but not a very exciting one (unless.....)

You could gain efficiency (very slight, not consistently) by removing
--sample-accurate; not sure many other features cost; maybe multicore
as a miniscule effect.  What feature do you suspect?

==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

>>>>> "Michael" == Michael Rhoades <mrhoades@perceptionfactory.com> writes:

 Michael> Thanks for pointing this out Steven, it was very interesting.
 Michael> It brings to mind a question that occurs to me from time to time... In
 Michael> the interview, Barry talks about having his own version of Csound that
 Michael> he works with. That idea is intriguing because, though I greatly
 Michael> appreciate the fantastic bells and whistles provided by Csound 6, the
 Michael> implementation of arrays comes to mind, the main reason I use it is
 Michael> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
 Michael> of the tools I require as a composer. So the question is... has any
 Michael> thought been put into making a "stripped down" version of Csound that
 Michael> has a focus more upon efficiency than upon additional features? Maybe
 Michael> there would not be a performance gain achieved by reducing the
 Michael> features... I am not qualified to know that but it seems possible. If
 Michael> this stripped down version of Csound were constrained to the features
 Michael> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
 Michael> could there be a performance gain?

There are two aspects to performance, CPU and memory.

Regarding CPU we have tried to optimise Csound in recent versions, and
I suspect Barry's code is less efficient, unless he has rewritten much
of it.  Last time I saw his code it used pointer arithmetic which was a
good idea at the state of compilers in the 1980/90 era, but index
arithmetic is faster, and we largely moved to that.

Memory use is more of an issue for small devices, and each opcode uses
code size even if not used -- unless in a plugin.  The lack of dynamic
loading on some mobile devices as led to a larger footprint that I (me
personally) would like.  There is also a small penalty on startup with
having more opcodes and possibly a very small one in parsing.  In perf
time I doubt there is an effect.

So if you really want a lightweight csound you need to move opcodes
into plugins again and just not load them.  Sounds like a student
project to me, but not a very exciting one (unless.....)

You could gain efficiency (very slight, not consistently) by removing
--sample-accurate; not sure many other features cost; maybe multicore
as a miniscule effect.  What feature do you suspect?

==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

John is right.

Our version of Csound has in the last few years been subjected to a fair amount of static code analysis and run-time performance profiling. So I think it should be reasonably efficient as it stands.

Understand, almost all of the code that Csound executes during an actual performance is opcode performance routines. After compilation, Csound runs in a pretty tight loop. Once per kperiod, checks for inputs, then iterates over all the active instrument instances. For each active instrument, Csound simply iterates over all of that instrument instance's opcode instances and calls each one's performance routine.

Most of the other code in Csound exists just to set up this tight loop.

To further optimize Csound, what would make sense is to develop test csds that would exercise the most commonly used opcodes. We could then profile each csd and see if there is anything in any of the opcode performance routines that can be significantly speeded up.

The initialization routines are called much less frequently, but could cause blips in performance, so some of these could be profiled also.

Also, in multi-threaded performance, the lists of instruments and opcode instances are divided up into sub-lists that can be executed concurrently, but this does not change the basic picture painted above. The code for dividing up the sub-lists has apparently also been optimized recently.

Regards,

Mike

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

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Wed, May 27, 2015 at 10:21 AM, jpff <jpff@codemist.co.uk> wrote:

>>>>> "Michael" == Michael Rhoades <mrhoades@perceptionfactory.com> writes:

 Michael> Thanks for pointing this out Steven, it was very interesting.
 Michael> It brings to mind a question that occurs to me from time to time... In
 Michael> the interview, Barry talks about having his own version of Csound that
 Michael> he works with. That idea is intriguing because, though I greatly
 Michael> appreciate the fantastic bells and whistles provided by Csound 6, the
 Michael> implementation of arrays comes to mind, the main reason I use it is
 Michael> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
 Michael> of the tools I require as a composer. So the question is... has any
 Michael> thought been put into making a "stripped down" version of Csound that
 Michael> has a focus more upon efficiency than upon additional features? Maybe
 Michael> there would not be a performance gain achieved by reducing the
 Michael> features... I am not qualified to know that but it seems possible. If
 Michael> this stripped down version of Csound were constrained to the features
 Michael> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
 Michael> could there be a performance gain?

There are two aspects to performance, CPU and memory.

Regarding CPU we have tried to optimise Csound in recent versions, and
I suspect Barry's code is less efficient, unless he has rewritten much
of it.  Last time I saw his code it used pointer arithmetic which was a
good idea at the state of compilers in the 1980/90 era, but index
arithmetic is faster, and we largely moved to that.

Memory use is more of an issue for small devices, and each opcode uses
code size even if not used -- unless in a plugin.  The lack of dynamic
loading on some mobile devices as led to a larger footprint that I (me
personally) would like.  There is also a small penalty on startup with
having more opcodes and possibly a very small one in parsing.  In perf
time I doubt there is an effect.

So if you really want a lightweight csound you need to move opcodes
into plugins again and just not load them.  Sounds like a student
project to me, but not a very exciting one (unless.....)

You could gain efficiency (very slight, not consistently) by removing
--sample-accurate; not sure many other features cost; maybe multicore
as a miniscule effect.  What feature do you suspect?

==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

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

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Regarding the usage of multiple cores, which Csound versions does this behavior apply to? When I get my new 8-core Android device, will Csound6.apk be able to use all the cores? What about the Csound version that runs in a browser?

On Wed, May 27, 2015 at 7:59 AM, Michael Gogins <michael.gogins@gmail.com> wrote:

John is right.

Our version of Csound has in the last few years been subjected to a fair amount of static code analysis and run-time performance profiling. So I think it should be reasonably efficient as it stands.

Understand, almost all of the code that Csound executes during an actual performance is opcode performance routines. After compilation, Csound runs in a pretty tight loop. Once per kperiod, checks for inputs, then iterates over all the active instrument instances. For each active instrument, Csound simply iterates over all of that instrument instance's opcode instances and calls each one's performance routine.

Most of the other code in Csound exists just to set up this tight loop.

To further optimize Csound, what would make sense is to develop test csds that would exercise the most commonly used opcodes. We could then profile each csd and see if there is anything in any of the opcode performance routines that can be significantly speeded up.

The initialization routines are called much less frequently, but could cause blips in performance, so some of these could be profiled also.

Also, in multi-threaded performance, the lists of instruments and opcode instances are divided up into sub-lists that can be executed concurrently, but this does not change the basic picture painted above. The code for dividing up the sub-lists has apparently also been optimized recently.

Regards,

Mike

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

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Wed, May 27, 2015 at 10:21 AM, jpff <jpff@codemist.co.uk> wrote:

>>>>> "Michael" == Michael Rhoades <mrhoades@perceptionfactory.com> writes:

 Michael> Thanks for pointing this out Steven, it was very interesting.
 Michael> It brings to mind a question that occurs to me from time to time... In
 Michael> the interview, Barry talks about having his own version of Csound that
 Michael> he works with. That idea is intriguing because, though I greatly
 Michael> appreciate the fantastic bells and whistles provided by Csound 6, the
 Michael> implementation of arrays comes to mind, the main reason I use it is
 Michael> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
 Michael> of the tools I require as a composer. So the question is... has any
 Michael> thought been put into making a "stripped down" version of Csound that
 Michael> has a focus more upon efficiency than upon additional features? Maybe
 Michael> there would not be a performance gain achieved by reducing the
 Michael> features... I am not qualified to know that but it seems possible. If
 Michael> this stripped down version of Csound were constrained to the features
 Michael> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
 Michael> could there be a performance gain?

There are two aspects to performance, CPU and memory.

Regarding CPU we have tried to optimise Csound in recent versions, and
I suspect Barry's code is less efficient, unless he has rewritten much
of it.  Last time I saw his code it used pointer arithmetic which was a
good idea at the state of compilers in the 1980/90 era, but index
arithmetic is faster, and we largely moved to that.

Memory use is more of an issue for small devices, and each opcode uses
code size even if not used -- unless in a plugin.  The lack of dynamic
loading on some mobile devices as led to a larger footprint that I (me
personally) would like.  There is also a small penalty on startup with
having more opcodes and possibly a very small one in parsing.  In perf
time I doubt there is an effect.

So if you really want a lightweight csound you need to move opcodes
into plugins again and just not load them.  Sounds like a student
project to me, but not a very exciting one (unless.....)

You could gain efficiency (very slight, not consistently) by removing
--sample-accurate; not sure many other features cost; maybe multicore
as a miniscule effect.  What feature do you suspect?

==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

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

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

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

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

yes, both should be able to run it (the code is compiled for these two platforms). The only dependency is pthreads
which is available in both platforms.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 27 May 2015, at 16:23, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> I think Csound for Android should be able to run multiple threads. I do not think the Emscripten build of Csound will ever be able to do so without substantial additional work because the JavaScript context in a Web browser is inherently single-threaded, and concurrency appears to be available at this time only through "Web Workers" which communicate by passing messages (which can be serialized value objects). About PNaCl I am not sure.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Wed, May 27, 2015 at 11:10 AM, Justin Smith <noisesmith@gmail.com> wrote:
> Regarding the usage of multiple cores, which Csound versions does this behavior apply to? When I get my new 8-core Android device, will Csound6.apk be able to use all the cores? What about the Csound version that runs in a browser?
>
> On Wed, May 27, 2015 at 7:59 AM, Michael Gogins <michael.gogins@gmail.com> wrote:
> John is right.
>
> Our version of Csound has in the last few years been subjected to a fair amount of static code analysis and run-time performance profiling. So I think it should be reasonably efficient as it stands.
>
> Understand, almost all of the code that Csound executes during an actual performance is opcode performance routines. After compilation, Csound runs in a pretty tight loop. Once per kperiod, checks for inputs, then iterates over all the active instrument instances. For each active instrument, Csound simply iterates over all of that instrument instance's opcode instances and calls each one's performance routine.
>
> Most of the other code in Csound exists just to set up this tight loop.
>
> To further optimize Csound, what would make sense is to develop test csds that would exercise the most commonly used opcodes. We could then profile each csd and see if there is anything in any of the opcode performance routines that can be significantly speeded up.
>
> The initialization routines are called much less frequently, but could cause blips in performance, so some of these could be profiled also.
>
> Also, in multi-threaded performance, the lists of instruments and opcode instances are divided up into sub-lists that can be executed concurrently, but this does not change the basic picture painted above. The code for dividing up the sub-lists has apparently also been optimized recently.
>
> Regards,
> Mike
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Wed, May 27, 2015 at 10:21 AM, jpff <jpff@codemist.co.uk> wrote:
> >>>>> "Michael" == Michael Rhoades <mrhoades@perceptionfactory.com> writes:
>
>  Michael> Thanks for pointing this out Steven, it was very interesting.
>  Michael> It brings to mind a question that occurs to me from time to time... In
>  Michael> the interview, Barry talks about having his own version of Csound that
>  Michael> he works with. That idea is intriguing because, though I greatly
>  Michael> appreciate the fantastic bells and whistles provided by Csound 6, the
>  Michael> implementation of arrays comes to mind, the main reason I use it is
>  Michael> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
>  Michael> of the tools I require as a composer. So the question is... has any
>  Michael> thought been put into making a "stripped down" version of Csound that
>  Michael> has a focus more upon efficiency than upon additional features? Maybe
>  Michael> there would not be a performance gain achieved by reducing the
>  Michael> features... I am not qualified to know that but it seems possible. If
>  Michael> this stripped down version of Csound were constrained to the features
>  Michael> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
>  Michael> could there be a performance gain?
>
> There are two aspects to performance, CPU and memory.
>
> Regarding CPU we have tried to optimise Csound in recent versions, and
> I suspect Barry's code is less efficient, unless he has rewritten much
> of it.  Last time I saw his code it used pointer arithmetic which was a
> good idea at the state of compilers in the 1980/90 era, but index
> arithmetic is faster, and we largely moved to that.
>
> Memory use is more of an issue for small devices, and each opcode uses
> code size even if not used -- unless in a plugin.  The lack of dynamic
> loading on some mobile devices as led to a larger footprint that I (me
> personally) would like.  There is also a small penalty on startup with
> having more opcodes and possibly a very small one in parsing.  In perf
> time I doubt there is an effect.
>
> So if you really want a lightweight csound you need to move opcodes
> into plugins again and just not load them.  Sounds like a student
> project to me, but not a very exciting one (unless.....)
>
> You could gain efficiency (very slight, not consistently) by removing
> --sample-accurate; not sure many other features cost; maybe multicore
> as a miniscule effect.  What feature do you suspect?
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Just to clarify Victor's statement, multicore applies to Android and PNaCl, but not Emscripten.  Also, it applies to iOS. 

On Wed, May 27, 2015 at 11:34 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

yes, both should be able to run it (the code is compiled for these two platforms). The only dependency is pthreads
which is available in both platforms.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 27 May 2015, at 16:23, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> I think Csound for Android should be able to run multiple threads. I do not think the Emscripten build of Csound will ever be able to do so without substantial additional work because the JavaScript context in a Web browser is inherently single-threaded, and concurrency appears to be available at this time only through "Web Workers" which communicate by passing messages (which can be serialized value objects). About PNaCl I am not sure.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Wed, May 27, 2015 at 11:10 AM, Justin Smith <noisesmith@gmail.com> wrote:
> Regarding the usage of multiple cores, which Csound versions does this behavior apply to? When I get my new 8-core Android device, will Csound6.apk be able to use all the cores? What about the Csound version that runs in a browser?
>
> On Wed, May 27, 2015 at 7:59 AM, Michael Gogins <michael.gogins@gmail.com> wrote:
> John is right.
>
> Our version of Csound has in the last few years been subjected to a fair amount of static code analysis and run-time performance profiling. So I think it should be reasonably efficient as it stands.
>
> Understand, almost all of the code that Csound executes during an actual performance is opcode performance routines. After compilation, Csound runs in a pretty tight loop. Once per kperiod, checks for inputs, then iterates over all the active instrument instances. For each active instrument, Csound simply iterates over all of that instrument instance's opcode instances and calls each one's performance routine.
>
> Most of the other code in Csound exists just to set up this tight loop.
>
> To further optimize Csound, what would make sense is to develop test csds that would exercise the most commonly used opcodes. We could then profile each csd and see if there is anything in any of the opcode performance routines that can be significantly speeded up.
>
> The initialization routines are called much less frequently, but could cause blips in performance, so some of these could be profiled also.
>
> Also, in multi-threaded performance, the lists of instruments and opcode instances are divided up into sub-lists that can be executed concurrently, but this does not change the basic picture painted above. The code for dividing up the sub-lists has apparently also been optimized recently.
>
> Regards,
> Mike
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
> On Wed, May 27, 2015 at 10:21 AM, jpff <jpff@codemist.co.uk> wrote:
> >>>>> "Michael" == Michael Rhoades <mrhoades@perceptionfactory.com> writes:
>
>  Michael> Thanks for pointing this out Steven, it was very interesting.
>  Michael> It brings to mind a question that occurs to me from time to time... In
>  Michael> the interview, Barry talks about having his own version of Csound that
>  Michael> he works with. That idea is intriguing because, though I greatly
>  Michael> appreciate the fantastic bells and whistles provided by Csound 6, the
>  Michael> implementation of arrays comes to mind, the main reason I use it is
>  Michael> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
>  Michael> of the tools I require as a composer. So the question is... has any
>  Michael> thought been put into making a "stripped down" version of Csound that
>  Michael> has a focus more upon efficiency than upon additional features? Maybe
>  Michael> there would not be a performance gain achieved by reducing the
>  Michael> features... I am not qualified to know that but it seems possible. If
>  Michael> this stripped down version of Csound were constrained to the features
>  Michael> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
>  Michael> could there be a performance gain?
>
> There are two aspects to performance, CPU and memory.
>
> Regarding CPU we have tried to optimise Csound in recent versions, and
> I suspect Barry's code is less efficient, unless he has rewritten much
> of it.  Last time I saw his code it used pointer arithmetic which was a
> good idea at the state of compilers in the 1980/90 era, but index
> arithmetic is faster, and we largely moved to that.
>
> Memory use is more of an issue for small devices, and each opcode uses
> code size even if not used -- unless in a plugin.  The lack of dynamic
> loading on some mobile devices as led to a larger footprint that I (me
> personally) would like.  There is also a small penalty on startup with
> having more opcodes and possibly a very small one in parsing.  In perf
> time I doubt there is an effect.
>
> So if you really want a lightweight csound you need to move opcodes
> into plugins again and just not load them.  Sounds like a student
> project to me, but not a very exciting one (unless.....)
>
> You could gain efficiency (very slight, not consistently) by removing
> --sample-accurate; not sure many other features cost; maybe multicore
> as a miniscule effect.  What feature do you suspect?
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-users mailing list
> Csound-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-users
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

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

_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

>>>>> "Michael" == Michael Rhoades <mrhoades@perceptionfactory.com> writes:

 Michael> Thanks for pointing this out Steven, it was very interesting.
 Michael> It brings to mind a question that occurs to me from time to time... In
 Michael> the interview, Barry talks about having his own version of Csound that
 Michael> he works with. That idea is intriguing because, though I greatly
 Michael> appreciate the fantastic bells and whistles provided by Csound 6, the
 Michael> implementation of arrays comes to mind, the main reason I use it is
 Michael> because it runs much faster than Csound 5. Otherwise, Csound 5 had all
 Michael> of the tools I require as a composer. So the question is... has any
 Michael> thought been put into making a "stripped down" version of Csound that
 Michael> has a focus more upon efficiency than upon additional features? Maybe
 Michael> there would not be a performance gain achieved by reducing the
 Michael> features... I am not qualified to know that but it seems possible. If
 Michael> this stripped down version of Csound were constrained to the features
 Michael> of, for example, Csound 5, while maintaining the efficiency of Csound 6,
 Michael> could there be a performance gain?

There are two aspects to performance, CPU and memory.

Regarding CPU we have tried to optimise Csound in recent versions, and
I suspect Barry's code is less efficient, unless he has rewritten much
of it.  Last time I saw his code it used pointer arithmetic which was a
good idea at the state of compilers in the 1980/90 era, but index
arithmetic is faster, and we largely moved to that.

Memory use is more of an issue for small devices, and each opcode uses
code size even if not used -- unless in a plugin.  The lack of dynamic
loading on some mobile devices as led to a larger footprint that I (me
personally) would like.  There is also a small penalty on startup with
having more opcodes and possibly a very small one in parsing.  In perf
time I doubt there is an effect.

So if you really want a lightweight csound you need to move opcodes
into plugins again and just not load them.  Sounds like a student
project to me, but not a very exciting one (unless.....)

You could gain efficiency (very slight, not consistently) by removing
--sample-accurate; not sure many other features cost; maybe multicore
as a miniscule effect.  What feature do you suspect?

==John ffitch

------------------------------------------------------------------------------
_______________________________________________
Csound-users mailing list
Csound-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-users
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here