std::list in the audio thread - bad idea?
-
- KVRian
- Topic Starter
- 871 posts since 24 Jun, 2002 from Berlin
is using std::list for managing polyphony in the high priority thread a bad idea? i.e. for keeping track of held keys and sustaining notes.
-
- KVRian
- 573 posts since 1 Jan, 2013 from Denmark
If you're not inserting / removing, depending on circumstances, you should be fine.
-
- KVRian
- Topic Starter
- 871 posts since 24 Jun, 2002 from Berlin
i use push_back() , remove(), clear(), and erase() relatively infrequently
-
- KVRist
- 137 posts since 15 Sep, 2008 from Grenoble
Expect allocations then.
(edit: alternative I see, sorted std::vector with reserve(), priority queue over binary heap).
(edit: alternative I see, sorted std::vector with reserve(), priority queue over binary heap).
-
- KVRist
- 231 posts since 15 Apr, 2012 from Toronto, ON
I think in any code where you care about performance, std::list (or any linked list for that matter) is not a good choice. I assume you're constantly traversing the list, which leads to chasing pointers, leading to cache misses every time.
- KVRAF
- 6478 posts since 16 Dec, 2002
Of course it's not a bad idea. Just learn to use STL algorithms and iterators (anything under #include <algorithm>) with lambdas so you aren't stuck with moronic for-loops.
Although based on your description alone I wouldn't immediately choose a container. More information is needed.
For example unordered_map or depending on your sorting needs maybe even plain map (an associative container in general) might work better. With unordered_map you are guaranteed constant-time access. If you aren't constantly adding new keys, or pre-allocate some known set of keys it might better represent a keyboard and its workload. In pseudocode std::unordered_map<keynumber, keyinfo>.
Although based on your description alone I wouldn't immediately choose a container. More information is needed.
For example unordered_map or depending on your sorting needs maybe even plain map (an associative container in general) might work better. With unordered_map you are guaranteed constant-time access. If you aren't constantly adding new keys, or pre-allocate some known set of keys it might better represent a keyboard and its workload. In pseudocode std::unordered_map<keynumber, keyinfo>.
- KVRAF
- 6478 posts since 16 Dec, 2002
Really, we're worried with allocations on a set of 128 (tiny struct consisting several ints) entities? From what year are you posting? Do you guys have Spectrums yet?ponce wrote:Expect allocations then.
-
- KVRAF
- 2393 posts since 28 Mar, 2005
If the allocation is only done once, it's not really a problem
If it allocates those 128 at each render callback then you will have threading issue as allocator on the audio thread may wait on allocation on the UI thread.
We are posting from a year where no OS allocator are lock free. Too bad this year is 2014.
If it allocates those 128 at each render callback then you will have threading issue as allocator on the audio thread may wait on allocation on the UI thread.
We are posting from a year where no OS allocator are lock free. Too bad this year is 2014.
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
Insertion in ln(n), so no need to move data if you have to reorder. Otherwise, you have to move at most 127 elements in the vector.
-
- KVRian
- Topic Starter
- 871 posts since 24 Jun, 2002 from Berlin
thanks for the info everyone. std::list was indeed overkill for this purpose. I've switched to std::vector, calling reserve(128) in my constructor, to avoid unwanted allocations.
- KVRAF
- 15169 posts since 8 Mar, 2005 from Utrecht, Holland
Regarding lamba expressions: those are just syntactic sugar. You have no control over its (in)efficiency. Which is a bad idea in the most inner loop...
We are the KVR collective. Resistance is futile. You will be assimilated.
My MusicCalc is served over https!!
My MusicCalc is served over https!!
-
- KVRist
- 137 posts since 15 Sep, 2008 from Grenoble
Kingston wrote:Really, we're worried with allocations on a set of 128 (tiny struct consisting several ints) entities? From what year are you posting? Do you guys have Spectrums yet?ponce wrote:Expect allocations then.
thanks for the info everyone. std::list was indeed overkill for this purpose. I've switched to std::vector, calling reserve(128) in my constructor, to avoid unwanted allocations.
- KVRAF
- 6478 posts since 16 Dec, 2002
Not true at all, also profiled as easily as any other loops or functors. I recommend Scott Meyers' latest (Efficient Modern C++) and some further brushing up on how lambda closures are expanded to functors. I basically shouted in joy when I realised I would no longer have to write anonymous nested for-loops for menial tasks consisting mostly boiler plate. When I say "anonymous" I mean a month later you will have no clue what the inner loops are doing anymore.BertKoor wrote:Regarding lamba expressions: those are just syntactic sugar. You have no control over its (in)efficiency. Which is a bad idea in the most inner loop...
(before c++11 you could achieve the same with <algorithm> and functors, but good luck writing let alone maintaining those)