Csound Csound-dev Csound-tekno Search About

Re: Proposal for a new version of Csound

Date1999-06-26 19:34
FromPaul Barton-Davis
SubjectRe: Proposal for a new version of Csound
>> Indeed. Although actually, no, because of the speed penalty. This is
>> one area where you don't want to mess around with too many object
>> abstractions - its in the inner loop of Csound's execution.
>
>You mean calling an object's method is actually longer than calling an
>otherwise identical C function ? Why ? (sorry if that's obvious) Or is there
>some silly redirection from the object to the class and from the class to the
>corresponding function (I would have thought that would be solved at compile
>time as a pointer to a function) ?

Function calls are just as fast, assuming that you were going to pass
in a ptr to a struct/object anyway. In rare cases, where the function
makes no reference to any of the object's members, pushing an extra
argument onto the stack before the call and popping it on the way out
is an unnecessary (very small) extra cost, but thats about it.

No, the increased overhead is more subtle, and has to do with
constructors and destructors. C++ does a lot more to enforce scope
restrictions than C, and this often/sometimes creates extra cost at
entry to and on departure from a function. In addition, if you're
using exceptions, that can cost extra as well since the compiler has
to set things up so that the stack can be unwound correctly.

In addition, if you're really going to use C++ effectively, as opposed
to just write C code and compile it with a C++ compiler, there are
typically costs associated with that as far as run time speed goes
i.e. there isn't an identical function.

If there *is* an identical function, and there are no constructors or
destructors, then its typically just as quick, and this is the
compromise I made in Quasimodo: I don't really do any C++ stuff with
the opcode arguments once they get inside the opcode function, so the
opcodes still look like regular C (with three exceptions, below). But
when we set up the voice, we use C++ extensively to set up the opcode
arguments.

The exceptions are (1) error reporting and (2) dynamic memory
allocation aka "auxalloc() (both of these use methods of the opcode
argument and AUXCH respectively) and lastly (3) pointers to reference
counted objects like function tables, which do require a
compiler-generated constructor call.

Date1999-06-26 20:45
FromMichel Jullian
SubjectRe: Proposal for a new version of Csound
Paul Barton-Davis wrote:
> 
> >Why not C++ ? Aren't UGs best modeled as objects (state + behavior) ?
> 
> Indeed. Although actually, no, because of the speed penalty. This is
> one area where you don't want to mess around with too many object
> abstractions - its in the inner loop of Csound's execution.

You mean calling an object's method is actually longer than calling an
otherwise identical C function ? Why ? (sorry if that's obvious) Or is there
some silly redirection from the object to the class and from the class to the
corresponding function (I would have thought that would be solved at compile
time as a pointer to a function) ?

BTW, I agree it might be better for Michael's project to start from Quasimodo,
or for both of you to unite your efforts to make Quasimodo the next improved
version of Csound.
-- 
Greetings,
Michel
.........................................................................
  Michel Jullian   Directeur General             email mj@exbang.com
  Exbang Industries S.A.
  Mas Chauvain   route de Villeneuve             tel +33(0) 499 529 878
  Maurin     34970 Lattes     France             fax +33(0) 499 529 879
.........................................................................