Comments 11
На самом деле, потенциал .NET и близко не раскрыт.
Во-первых, FFTW использует многопоточность, во вторых — SIMD (в .NET его завезли, кстати).
При нормальной реализации .NET будет оставать не более, чем в 2 раза.
Правда, зачем изобретать велосипед, когда можно не мучиться и дёргать вызовы из FFTW.
А можно на КДПВ добавить подпись к оси Y или словами как-то сказать, что чем больше значение - тем хуже. Пришлось досмотреть до конца статьи, чтобы это понять. Или так задумано?
Я конечно не разбираюсь в тестах, но эти xml комментарии к каждому свойству по мне уж лишние
Ни разу не возникало мысли ради простого одномерного БДПФ тянуть в проект новую зависимость. Алгоритм Кули - Тьюки реализуется в 20 строк, элементарным образом параллелится, а время его работы составляет несколько процентов от времени, необходимого для вывода результата работы на экран. Безусловно, самописная реализация на F# окажется несколько менее эффективной, чем библиотеки, написанные профессионалами на C++, но, в моём случае (обработка сейсмических сигналов) на это можно смело наплевать.
Зато нельзя наплевать на то, что число отсчётов в сейсмограмме очень велико (несолько миллионов отсчётов — обычное дело) и почти никогда не оказывается степенью двойки, а шаг по времени для некоторых сценариев записи непостоянный (чем выше амплитуда, тем меньше шаг). Могут ли библиотеки работать с таким сигналом и если могут — то как конкретно они это делают, почти никто не пишет.
Так-то и быструю сортировку можно написать в 10-20 строчек, но так обычно не делают. А все потому, что на самом деле эффективный алгоритм - это далеко не «наколеночное» решение.
В случае с FFT, то тут целый простор для улучшений и реализаций, начиная от поддержки произвольных длин, заканчивая локальными оптимизациями, поддержкой команд SSE, AVX и т.д. Скорее всего в реальном проекте (не лабораторной работе для студентов) вы не захотите тратить время на это все, а подключите тот же FFTW.
Разница сортировки и FFT в том, что сортировка уже встроена в поставляемую стандартную библиотеку, а FFT нет. Но это не повод для написания собственных реализаций. Конечно, все зависит от ситуации.
В том то и прикол, что реализация БПФ с параллельностью, поддержкой произвольных длин и непостоянного шага по времени у меня заняла минут 15-20, что сравнимо со временем на поиск и подключение библиотеки в обычных условиях и в несколько десятков раз меньше, чем в условиях доступности только корпоративной сети. Там, конечно, нет SSE/AVX/ассемблера, и, при желании, скорость работы можно повысить раза в 2, но сейчас, как я уже писал выше, отрисовка итогового графика является гораздо более ресурсозатратной частью программы. Если когда-то в будущем в проект придётся тянуть тот же Math.NET, то станет иметь смысл использовать реализацию оттуда, а пока живём с велосипедом.
Размер указан в MB. А здесь под assemblies не сборки подразумеваются? Тогда что, подскажите?
Why some assemblies/projects are marked as .Noncommercial in their names?
Some assemblies, such as Accord.Math.Noncommercial are marked as Noncommercial because they include algorithms that have been shared under academic-only licenses, or that otherwise contain patented algorithms for which would be necessary to acquire a license to commercialize. If you would are using the framework and plan to commercialize your product, please avoid linking your project against those specific assemblies (note: the assembly shown as an example is different from the standard Accord.Math assembly, which is perfectly OK to use in commercial applications).
Разве не о разных сборках речь?
Сравнение реализаций БПФ для .NET