From: Michael Gogins (michael.gogins@gmail.com)
Date: Wed Feb 02 2011 - 11:50:31 EST
I will take your points in order below.
On Wed, Feb 2, 2011 at 11:29 AM, Mathieu Bouchard <matju@artengine.ca> wrote:
> On Tue, 1 Feb 2011, Michael Gogins wrote:
>
>> The only reason to have a computer is that it is faster than you are.
>> Therefore, faster is always better.
>
> It isn't. When you get to something sufficiently faster at execution, you
> need not to go any further, except as a prediction of future needs.
It is, because when you get to something sufficiently faster at
execution, you start using more complex algorithms. E.g. the old FM
piano or sampled piano executed "sufficiently fast" on older machines,
but on newer machines you can run the more demanding Pianoteq or other
physical models, not feasible previously.
>> C and C++ are the fastest languages.
>
> You need to also count the time it takes to write a programme, and how much
> it costs, including debugging, future expansion of features, etc., and you
> need to take into account the ease of focusing on the problem (limiting the
> need to use error-prone constructs).
>
> Thus C/C++ are often slower because the computer is faster than you are when
> is coming the time to figure out memory leaks, buffer overflows, dangling
> pointers, segmentation faults, uninitialised variables, and other things
> that in C/C++ the language leaves that to you instead of doing it faster
> than you do.
I don't have these problems with memory leaks, buffer overflows,
dangling pointers, and what not because I take advantage of the
Standard C++ Library, boost, and so on. But of course it still takes
longer to code C/C++ because you still have to wait for the compiler
and linker.
>> Therefore, performance-critical software must always be written in C, C++,
>
> I found it most efficient to use a language combination. Nowadays I use C++
> together with PureData (formerly, I was using a C++/Ruby/PureData trio).
>
>> Therefore, audio synthesizers must be written in C/C++ to run in their own
>> thread or even their own process, i.e., to be servers in a client-server
>> architecture.
>
> You talk like you don't know at all about the idea that when, in a slow
> interpreter, each operation does a lot of job, you don't need to run as many
> operations, and thus, the speed of the interpreter doesn't matter nearly as
> often. It changes the whole balance of things. Most of what I've done in the
> last ten years relies on that principle.
That's a good point. But it would only apply if each operation that
does a lot of work is actually running native code.
>> That said, it is tempting to think about writing an audio synthesizer that
>> the user programs in Lua, which then runs a signal flow graph of unit
>> generators written in C++.
>
> If you know the principle, then why did you write «must be written in C/C++»
> above ??
I'm thinking out loud. This design I am considering here is a kind of
hybrid. Most software synthesizers using some kind of runtime compiler
to wire together a signal flow graph out of unit generators that go
"all the way down", e.g. in Csound even logical operators, branches,
loops, and arithmetic operations are unit generators. In the Lua
design, inside instrument definitions, the unit generators would be
objects that work together in regular procedural Lua code which is
easier to write, read, and understand.The signal flow graph would go
down to the "instrument" or "effect" level and then stop. Inside the
instruments and effects, Lua callbacks would run Lua code. The Lua
unit generators would actually be wrappers for unit generators written
in C or C++. I have no idea whether this would really be efficient
enough since there obviously is some overhead in pushing signals back
and forth across the Lua/C boundary.
>> It is also reasonably likely that a signal flow graph written in state of
>> the art C++ would be somewhat more efficient than any of the existing ones,
>> especially if it incorporated multi-threading.
>
> What's «state of the art C++» and how is it better than all the C/C++ signal
> flow graph systems already written ? I'd like to know what you're trying to
> say.
Mainly, to take advantage of multiple CPUs (cores) without bringing in
too much complexity. This can be done by using OpenMP to run each
independent layer of the signal flow graph on as many simultaneous
threads as possible. This can lead to significant speedups. As an
example, consider a physical model of a string orchestra. All
instruments in each section are essentially independent of each other,
therefore they can all run at the same time in simultaneous threads.
We have an experimental version of this kind of thing in Csound (using
pthreads, not OpenMP) and we get about 25% more performance for each
doubling of cores.
"State of the art" also refers to using templates, the Standard C++
Library, and boost to implement collections and algorithms and cut out
bugs while still being very efficient. I don't at all mean introducing
esoteric and show-off kinds of programming. For example, the boost
graph library could be used to compile the signal flow graph and to
produce a "tick list" for actual performance. The amount of visible
code can shrink quite a bit without slowing anything down.
-- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com
This archive was generated by hypermail 2.1.5 : Sat Feb 05 2011 - 10:27:41 EST