Эффективная пропускная способность памяти использует для потоковой передачи
Предполагая
- , что микрофон означает микрофон
- , что вы все правильно подключили
- , что выходной сигнал микрофона имеет достаточное напряжение -> иначе добавьте усилитель)
Тогда ответ ДА.
4 ответа
Как Вы пишете в 64 выходных мусорных ведра, Вы будете использовать много различных ячеек памяти. Если мусорные ведра заполнены по существу наугад, это означает, что у Вас иногда будет два мусорных ведра, что couls совместно используют ту же строку кэша. Не большая проблема; кэш Core 2 L1 с 8 путями ассоциативный. Это означает, что Вы получили бы проблему только с 9-й строкой кэша. Со всего 65 живыми ссылками памяти в любое время (1 запись чтения/64), с 8 путями ассоциативный в порядке.
Кэш L2 по-видимому с 12 путями ассоциативный (3/6MB общее количество, таким образом, 12 не то, что странный число). Таким образом, даже если у Вас были бы коллизии в L1, возможности довольно хороши, Вы все еще не поражаете оперативную память.
Однако, если Вам не нравится это, перестройте мусорные ведра в памяти. Вместо того, чтобы хранить каждое мусорное ведро последовательно, чередуйте их. Для мусорного ведра 0, хранилище разделяет на блоки 0-15 при смещениях 0-63, но хранилище разделяет на блоки 16-31 при смещении 8192-8255. Для мусорного ведра 1, хранилище разделяет на блоки 0-15 при смещениях 64-127 и так далее. Это берет всего несколько сдвигов разряда и масок, но результат состоит в том, что пара мусорных ведер совместно использует 8 строк кэша.
Другим возможным способом ускорить Ваш код в этом случае является SSE4, особенно в x64 режиме. Вы получили бы 16 регистров x 128 битов, и можно оптимизировать чтение (MOVNTDQA) для ограничения загрязнения кэша. Я не уверен, поможет ли это много со скоростью чтения, хотя - я ожидал бы, что предварительное устройство выбора Core2 поймает это. Чтение последовательных целых чисел является самым простым видом возможного доступа, любое предварительное устройство выбора должно оптимизировать это.
У Вас есть опция записи Ваших потоков вывода как единый поток со встроенными метаданными для идентификации каждого 'блока'? Если бы необходимо было считать 'блок', выполнить функцию threshhold на нем, то вместо того, чтобы писать это в конкретный поток вывода Вы просто записали бы, какой поток это принадлежало (1 байту), сопровождаемому исходными данными, Вы серьезно уменьшите свою перегрузку.
Я не предложил бы это за исключением того, что Вы сказали, что необходимо много раз обрабатывать эти данные. На каждом последовательном выполнении Вы читаете свой входной поток для получения, число мусорного ведра (1 байт) затем делают то, что необходимо сделать для того мусорного ведра на следующих 8 байтах.
До cacheing поведения этого механизма, так как Вы только скользите через два потока данных и, во всех кроме первого случая, пишущий столько данных, сколько Вы читаете, аппаратные средства дадут Вам всю справку, на которую Вы могли возможно надеяться до упреждающей выборки, оптимизации строки кэша, и т.д.
Если необходимо было добавить, что дополнительный байт каждый раз, когда Вы обработали свои данные, Ваше худшее поведение кэша случая, является средним случаем. Если можно предоставить хит устройства хранения данных, он походит на победу мне.
Вы могли бы хотеть исследовать для отображения файлов в память. Таким образом, ядро может заботиться об управлении памятью для Вас. Ядро обычно знает лучше всего, как обработать кэши страницы. Это особенно верно, если Ваше приложение должно работать больше чем на одной платформе, поскольку различные Ose обрабатывают управление памятью по-разному.
Существуют платформы как ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) или Повышение (http://www.boost.org), Который позволяет Вам писать код, который делает размещение в ОЗУ независимым от платформы способом.
Вот некоторые идеи, если Вы действительно становитесь отчаянными...
Вы могли бы рассмотреть аппаратные средства обновления. Для потоковой передачи приложений, несколько подобных Вашему, я нашел, что получил большое повышение скорости путем изменения на i7 процессор. Кроме того, процессоры AMD, предположительно, лучше, чем Core 2 для ограниченной памятью работы (хотя я недавно не использовал их сам).
Другое решение, которое Вы могли бы рассмотреть, делает обработку на видеокарте с помощью языка как CUDA. Видеокарты настраиваются, чтобы иметь пропускную способность очень верхней памяти и сделать быстрые математические операции с плавающей точкой. Ожидайте тратить 5x к 20x, время разработки для кода CUDA относительно простого не оптимизировало реализацию C.