Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Правильно, поэтому мы используем класс Socket только для инициализации (бо удобно очень), а потом берем хендл, и по UDP работаем не через класс сокета.
S>И как вы работаете "не через класс"? Даже если напрямю ДллИмпортировать неуправляемые Send и Receive, маршалер один хрен выполнит тот же пиннинг на время вызова. Потому что иначе никак — злой GC переместит буфер и привет.
Опять же правильно, поэтому маршаллируется не массив, а эго запиненный адрес.
Если опускаться все дальше и все глубже, то у нас основной протокол IAX, который хорош тем, что используется всего 1 UDP порт, поэтому всех клиентов по этому протоколу мы слушаем на одном порту. Вызываем
синхронный метод чтения UDP-пакета из одновременных нескольких конкурирующих потоков (самый эффективный вариант получился, крайне рекомендую). Каждый такой поток-близнец при старте системы инициализирует буффер и пинит его, затем мы оперируем лишь IntPtr. Да, GC.Collect дважды с ожиданием финализаций перед этой операцией вызываем.
В общем, unsafe-ом мы не страдаем, тем более, что это все-равно байт-код, т.е. смысл не так уж велик. Я вообще не знаю такую задачу для unsafe, которую не смог бы решить в safe столь же эффективно, кроме случая реинтерпретации памяти (см. например вычисление String.GetHashCode()). Я и в native всячески от реинтерпретации стараюсь уходить, а в managed сам бог велел.
V>>Это должен быть путь не одинокого джедая, а как минимум серьёзного коллектива, т.к. сами оптимизации/развороты и прочее хоть и просты каждый в отдельности, но их охренительное кол-во, т.е. база знаний должна быть приличная.
S>Не, если коллектив — то и падаванов хватит.
Не знаю. Для себя я сложности делю на 2 полюса:
1-й — сложность "в глубину", когда объем реализации/спецификаций/абстракций маленький, но за ним скрывается большой теоретический бэкграунд (как пример — ИИ, либо обработка сигналов, и то и другое выполняется примитивными операциями с векторами, но эта "примитивность" дорогого стоит).
2-й — сложность "в ширину", когда объем реализации и т.д. очень большой, но при этом этот объем легко разложим на множество примитивных подзадач (пример: большинство современных информационных систем).
Так что реализация этого интересного варианта с GPU действительно скорее (2), чем (1), и падаванов хватит. А вот задача поиска новых алгоритмов оптимизации или же повышение эффективности имеющихся — неспоримо (1), как раз для джидая.
S>Угу. То есть развертка — в отказе от C[j] в пользу Cj.
Если Сj константы, то почему бы нет.
V>>Но наложение окна — это общая и довольно частая операция в обработке сигналов, когда инициализируется некий кодек или препроцессор, то ему динамиччески параметры сигнала дают, и он выделяет буфера динамически, и наложение окна — это цикл в цикле получается.
S>А, ну я так и думал — то есть теперь есть два "окна", которые едут мимо друг друга.
В нерекурсивном было тоже два окна, просто одно из них константное (для случая фиксированных в compile-time характеристик фильтра) и очень большое. В рекурсивном же окно обычно маленькое — это порядок фильтра+1, и сдвиг окна неплохо выполняется одновременно с вычислениями.
Продолжая давать советы по эффективной реализации фильтрации: т.к. данные подаются порциями, то все регистры сдвига для рекурсивного фильтра могут располагаться на стеке в процессе обработки порции, с сохранением состояния фильтра м/у обработками. Для .Net достаточно класс фильтра сделать value-type, далее "всё само".
