On Thursday 08 November 2007, Krzysztof Foltman wrote:
[...]
> It would also facilitate sharing memory pools between plugins. On
> the other hand, it might sometimes make sense to have separate pools
> per plugin, to improve cache locality.
Unless you're running the plugins on different cores or CPUs, wouldn't
separate pools just hurt, no matter what...? Cache locality is the
very reason why you *don't* want statically allocated per-plugin
buffers for audio transfer and stuff like that.
Do you have a specific example where per-plugin pools would improve
things?
> But if my opinion counts, please provide a LGPL-ed reference
> implementation (based on TLSF or anything else that works :) ) and
> test suite as well :) So that host authors can simply use them to
> avoid bugs and duplicated effort.
Yeah, that's why I suggested TLSF. :-)
Now, there are two issues with the TLSF implementations I know of:
1) They don't support resizing the pool on the fly.
2) They don't support 64 bit environments.
The latter should be easy to fix, I think (use sizeof(void *) for
alignment, basically), but resizing the pool might require some
redesign of the algorithm.
I'll need a hard RT memory manager that deals with both of these
issues for my EEL scripting engine, so I'm rather interested in this
particular issue, whether or not it goes into an LV2 extension.
[...]
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 8 16:15:04 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 08 2007 - 16:15:04 EET