Re: [fluid-dev] Questions about Gleam

[jimmy]

On Mon, Apr 21, 2008 at 3:08 PM, Miguel Lobo
<address@hidden> wrote:
> Events can be generated and consumed at quite a high
rate, so event
 memory
> management can be critical for performance and
especially latency.
> Applications might implement different solutions to
deal with this,
 so I
> wanted to keep GleamCore flexible in this area.  In
fact, the
 non-optional
> parts of GleamCore don't do any allocation or
de-allocation of
 events; the
> MIDI converter does, but it's just meant to be a
helper to deal with
 MIDI
> data and its use by the application is completely
optional.  Perhaps
 it
> should be moved out of GleamCore, as nothing in
GleamCore depends on
 it.

Miguel,

That sounds good.



> Another general target is to avoid any calls to
memory allocation
 functions
> (which have potentially unbounded duration) in the
synthesis thread.
  At the
> moment we're still quite far from that target, but
the freeing of
 events is
> the most important place, I think, where this idea
impacts design
 rather
> than just implementation, so I wanted to try to get
it right as early
 as
> possible.

Let me just share some design consideration, or just
call it experiments to try to see if it helps.  For
event objects, you can try to have a collections of
some sort to hold on to pre-allocated events.  The
events are either allocated as needed, or
pre-allocated at start-up (and have command-line
option for the initial size of the collection).  When
you need an event, remove it from the collection, then
use it just as it has just been allocated.  When you
are done with the event, throw it over to a separate
thread to do any cleanup/re-initialize and add it back
to the collection of pre-allocated events.  You can
even have that secondary thread to check occasionally
if the collection is running low on pre-allocated
events, if it is, then create some new events for that
collection.  Don't know what kind of impact that may
cause, but just an idea.  There could be a threshold
that if there are way too many events in that
collection, some of the could be freed and
deallocated, too.

That way, the events are already pre-alocated, just
need to set the states of the internal variables and
not worry about time for memory allocation.

I used these techniques in Java for potential
CPU-spikes and overhead in garbage collection for
excessive allocation/deallocation of objects.



> Virtual functions have a cost both in compile-time
optimization and
 run-time
> performance and should be avoided in time-critical
code whenever
 reasonable.
> Events could have a virtual callback to notify of
their consumption,
 but
> that would be quite expensive.  The intended way to
know when a point
 has
> been reached in the event queue is the condition
sync event, which
 has
> minimal cost for the synthesis thread.  An example
of its usage its
 provided
> in playmidi.cpp:
>
>
>     /* add a condition sync event so we know when
all events have
 been
> played */
>     GleamConditionSyncEvent&
>
endEvent(events.addType<GleamConditionSyncEvent>()());
>     endEvent.freeList = &freedEvents;
>
>      endEvent.time = lastTime;
>
> [...]
>
>     /* wait until the end event is played */
>     endEvent.conditionSync.wait();
>
> Hope these answers some of your questions.
>
> Regards,
> Miguel

I haven't done much with C++ for a while.  But in
Java, there are events, and event listeners.  Where
you could add some object that implements the
event-listener interface (basically a callback
function) intered in some particular event(s).  When
the event is fired, each and every one of the
event-listeners already registered are notified
(called-back).  There might even be a property
(variable accessible via getter/seter functions) for
veto-ing some proposed action like exit the program if
it can't save the current settings...

Of course, we may have to be careful for realtime
events.  But this particular event isn't quite
realtime-sensitive.

Jimmy



      
____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ