Mario wrote:
Сейчас поговорил с diamond'ом и выяснил неизвестные для себя вещи - они
мельком описаны на форуме. Хотя ради такого глобального шага можно было целую тему создать.
это точно. А еще лучше - статью в Вики. Ковыряясь в исходниках, ни за что не поймешь в чем была суть гениальной задумки...
Quote:
Принцип copy-on-write... При первой записи на страницу внутри библиотеки происходит копирование и возникает специальная страница для этого процесса....
Теперь можно сколько угодно копий библиотеки вызывать - если она реентерабельна, то код не будет дублироваться.
Если честно я очень рад.

А я - не очень.
Получается, что если используется хотя бы одна локальная переменная для временного хранения данных (у меня их 20), то такая библиотека уже не будет считаться реентерабельной, и такой код будет дублироваться ( ! ) персонально для каждого нового вызывающего приложения?
Serge wrote:
Смена контекста FPU обходится не так и дорого. Мьютекс здесь поможет мало потому что FPU используется ядром в отрисовке фона и звуковыми драйверами. Квант задачи 10 миллисекунд. Переключение FPU - несколько микросекунд. Это можно уточнить. Потеря в быстродействии на ожидании мьютекса будет больше.
Иногда и микросекунды приходится считать поштучно.
У меня, например, каждую микросекунду во входном фреймбуфере накапливается около
пятисот новых пикселей. Переполнения буфера приводят к заметным дырам.
Конечно, не у всех такой экстрим, но все-таки хотелось бы для библиотеки
быстрого частотного анализа продумать какую-то оптимизацию по времени.
Serge wrote:
Если массив создаваемый MakeSinCosTable всегда одинаков то его лучше сделать статическим в сегменте кода. diamond давно сделал библиотеки расшаренными. Или использовать общую память.
Размер массивов разный (четверть размера массива данных).
А что есть почитать насчет общей памяти?