[yoshimi] Re: (yet another) crazy idea?
- From: Ichthyostega <prg@xxxxxxxxxxxxxxx>
- To: yoshimi@xxxxxxxxxxxxx
- Date: Mon, 14 Nov 2016 00:02:41 +0100
On 09.11.2016 22:02, Will Godfrey wrote:
....and for every note-on there are a bunch of 'new' directives then value
calculations/insertions. For each note-off there is the corresponding bunch
of 'delete'. To me, This seems quite wrong.
in such a situation, what you usually want is a pooling allocator.
The idea seems simple, but what typically makes matters difficult
is when the individual allocation is of varying, non uniform size.
When you build such a thing from scratch, there is the real danger
that what you create is buggy and performs worse than the allocator
provided by the platform (C++ / runtime library).
The only reason why a hand written allocator can be better is when
you're able to exploit additional knowledge, which a generic allocator
can not have. For example, if you, as the application programmer, know
the allocation pattern or allocation trend to come, then you'll be able
to optimise for that. For example, if you know, that you'll be allocating
a huge number of objects the same size, and if you additionally know that
you'll be freeing all those objects in bulk, then you'll be able to
come up with an allocator that performs way better than what the
runtime provides. Because, allocating a huge chunk of memory is fast,
but maintaining the information about what is in use and finding free
slots in an increasingly fragmented space is what eats up the time.
Not to mention the pile of mistakes you can make when this allocation
happens in a multi threaded context.
If you ask me, from a quick glance at the mentioned code, I would
seriously recommend against such attempts of micro optimising.
This code is ok-ish, but it is written in a naive style. Which means,
it lacks any additional structuring which would allow to refactor some
aspects of the code without endangering other functional aspects or
correctness / readability / maintainability. Thus, if you attempt to
add memory allocation optimisation, this will bloat the complexity of
the code, and it will become increasingly hard to keep track of
the primary concern (sound synthesis).
Please add to this the fact that those allocations are by no means
uniform. They highly depend on the characteristics of the individual
note (like e.g.the nvoice). And they come and go in a basically
random pattern (as the notes are played). To make any inroads
in such a situation would be a major programming challenge.
-- Hermann
Yoshimi source code is available from either:
http://sourceforge.net/projects/yoshimi
Or:
https://github.com/Yoshimi/yoshimi
Our list archive is at:
https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx
Other related posts: