Параллельный решатель уравнения Лоренца на FPGA

Обсуждение научных открытий, алгоритмов и инженерных новинок
Ответить
Аватара пользователя
Pavel Krivozubov

Activity Bronze
professor
professor
Сообщения: 4421
Зарегистрирован: 07 фев 2008, 16:39
Награды: 3
Версия LabVIEW: 7.0 - 2013
Откуда: г. Электросталь
Благодарил (а): 24 раза
Поблагодарили: 9 раз
Контактная информация:

Параллельный решатель уравнения Лоренца на FPGA

Сообщение Pavel Krivozubov »

Уважаемые коллеги!
В разделе "Уроки" опубликован интересный аналитический материал, посвященный разработке Параллельного решателя уравнения Лоренца на FPGA.
Автор этого материала - Константин Георгиевич Жуков, профессор ЛЭТИ, автор книги Модельное проектирование встраиваемых систем в LabVIEW.
Просьба специалистов, работающих в этой области прокомментировать данное решение.
Спасибо!
Аватара пользователя
Andrew Lunev

Activity Professionalism
VIP
VIP
Сообщения: 957
Зарегистрирован: 11 дек 2010, 12:31
Награды: 2
Версия LabVIEW: 2014-2021
Откуда: Москва
Благодарил (а): 4 раза
Поблагодарили: 10 раз

Re: Параллельный решатель уравнения Лоренца на FPGA

Сообщение Andrew Lunev »

Попробую высказаться о статье и ее выводах.
К сожалению к статье не приложен исходный код всех программ и не представлен вывод разностных уравнений для этого решения. Поэтому приходится всю информацию собирать по картинкам.

1. Как я вижу, сравниваются универсальный решатель со специализированным, который спроектирован под конкретную систему уравнений и имеет жесткую структуру. О том, что универсальный решатель ВСЕГДА проигрывает по скорости выполнения специализированному знают все инженеры курса с третьего ВУЗА. Но на универсальном можно решить любую систему ОДУ, а на специализированном только одну конкретную с разными параметрами. Чудес не бывает и приходится чем-то жертвовать. В статье же это представлено, как нечто новое.
2. Предложенный решатель назван параллельным. Однако, его реализация для Windows и RT совсем не гарантирует, что вычисления действительно распараллеливаются. То, что вместо одного сложения в цикле их нарисовали десяток совсем не гарантирует, что все эти 10 сложений выполнятся одновременно. Код совершенно не оптимизирован под многопоточность и многоядерность, хотя возможности для этого в LabView есть. Поэтому говорить о параллельной реализации в данном случае просто не корректно. Тут опять же сравниваются универсальный вариант решателя со специализированным.
3. Сравнивается выполнение кода на двух совершенно разных платформах. При этом всем известно, что они отличаются по скорости на порядки. Получили вполне предсказуемый результат. Не совсем понимаю в чем его смысл. Доказать, что PowerPC медленней Core 5? Опять же код не оптимизирован под платформы поэтому сравнение не корректное. То есть понятно, что на PowerPC скорость будет ниже, но на сколько конкретно ниже стоит говорить только если на из обеих платформ выжали максимум. Тут же скорее всего Core 5 работал раз в 6 медленней, чем мог бы после оптимизации кода и полученные цифры отличались бы еще сильней.
4. Код на FPGA действительно выполняется параллельно. Однако, судя по картинке с кодом, он совершенно не оптимизирован по скорости выполнения. Большую часть кода можно внести под однотактовые циклы, что даст прирост в производительности в 5-10 раз. К тому же, скорее всего в FPGA была установлена частота по умолчанию 40 МГц, в данной задаче вполне можно поднять ее до 200 МГц и тем самым гарантированно увеличить скорость работы кода в 5 раз. Общую скорость выполнения кода можно поднять раз в 50.

В итоге показано, что на FPGA можно решить систему ОДУ с жестко заданной структурой. Я думал это и так всем понятно, раз можно производить четыре арифметических действия и сохранять данные в ячейку памяти, то реализовать разностные уравнения можно без проблем. Их количество и сложность определяется только объемом FPGA. Я сам реализовывал решения систем из более чем десятка нелинейных уравнений на FPGA. Правда решение было методом трапеций с постоянным шагом, но при меньшем шаге точность получается не хуже, чем у Рунге-Кутта. А скорости FPGA вполне хватало, чтобы решать их на частоте 10 кГц в реальном времени.

В статье совершенно не освещен вариант решения на FPGA с использованием типов данных FXP и SGL. C ними реализация получится намного проще, SGL скорее всего будет проигрывать по скорости целочисленному варианту, а вариант с FXP может быть быстрей за счет использования палитры High Throughput Math Functions.

Если бы автор смог реализовать универсальный параллельный решатель на FPGA типа ODE Solver Runge-Kutta 2, то это был бы настоящий прорыв. А так это стандартное решение стандартной задачи. Притом, большая часть реализаций и выводов не корректна.
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1327
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Параллельный решатель уравнения Лоренца на FPGA

Сообщение AndreyDmitriev »

Andrew Lunev писал(а): К сожалению к статье не приложен исходный код всех программ
...
Если бы автор смог реализовать универсальный параллельный решатель на FPGA типа ODE Solver Runge-Kutta 2, то это был бы настоящий прорыв. А так это стандартное решение стандартной задачи. Притом, большая часть реализаций и выводов не корректна.
Чё-то вы, коллега, как-то очень уж критично... Вообще можно попробовать универсальный решатель на GPU замутить. Тогда может быть можно будет и с FPGA потягаться (скорее всего до частного случая по скорости не дотянемся, но приблизимся). Я, правда, навскидку не уверен насколько хорошо оно там параллелится, чтобы все конвейеры по полной нагрузить.

И да, исходный код не помешал бы.
Аватара пользователя
Andrew Lunev

Activity Professionalism
VIP
VIP
Сообщения: 957
Зарегистрирован: 11 дек 2010, 12:31
Награды: 2
Версия LabVIEW: 2014-2021
Откуда: Москва
Благодарил (а): 4 раза
Поблагодарили: 10 раз

Re: Параллельный решатель уравнения Лоренца на FPGA

Сообщение Andrew Lunev »

AndreyDmitriev писал(а):Чё-то вы, коллега, как-то очень уж критично...
Может быть слишком критично. Просто работа проделана большая, я ее смысл я так и не понял. Не понятно, что хотел исследовать автор и зачем поделился этими результатами. Для меня это что-то вроде того, что провели огромное исследование и доказали, что 2*2=4. Я так и не смог найти в статье ни научной ни практической ценности.
Конечно, если бы это была статья студента или аспиранта, то я бы так сильно не критиковал. Однако, автор статьи имеет многие регалии и, как говорится, должен соответствовать. Понятно, что и статья оценивалась, как если бы ее написал профессор, коим автор и является.

Если кто-то сможет указать мне на ценности этой статьи, буду благодарен. Возможно я не разобрался в нюансах и там на самом деле куча новых и прорывных идей.

По поводу GPU скорее всего идея здравая. Но мне в задачах вполне хватает FPGA. А вот надо ли это автору я так и не понял. Не понятно для чего проводилось ускорение решения. Похоже просто ради самой идеи этого ускорения. Если нужна была модель, которая решается в реальном времени, то проще было чуть понизить точность решения. Тут же обеспечивается точность до 13 десятичного знака! Зачем такая точность совершенно не понятно. Видимо данные с датчиков, которые подаются в модель имеют так же точность 13 десятичных знаков, но я про такие не слышал. Смысл моделировать точней, чем могут быть представлены данные на входе и на выходе модели? Получим решение в 13 знаков, а потом выдадим его на 16 битный ЦАП? Понизили бы точность до пяти знаков, получили бы ускорение раз в 100.
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1327
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 37 раз
Контактная информация:

Re: Параллельный решатель уравнения Лоренца на FPGA

Сообщение AndreyDmitriev »

Andrew Lunev писал(а):
AndreyDmitriev писал(а):Чё-то вы, коллега, как-то очень уж критично...
Может быть слишком критично. Просто работа проделана большая, я ее смысл я так и не понял. Не понятно, что хотел исследовать автор и зачем поделился этими результатами. Для меня это что-то вроде того, что провели огромное исследование и доказали, что 2*2=4. Я так и не смог найти в статье ни научной ни практической ценности.
Ну мне так видится, что показа пример того, что можно сделать на FPGA. Конечно, практическая ценность была бы куда как выше, если бы присутствовали исходники и было бы видно, как алгоритм адаптируется к переносу в FPGA.

Лет десять назад была у нашего отдела задачка сделать кодирование в JPEG2000 видеопотока в реальном времени. Причём картинки были шестнадцатибитные. Ни один из существующих в то время кодеков на имеющихся компьютерах и близко не подходил к требуемой производительности. Решено было делать это аппаратно. Мы убили несколько недель, прежде чем первая картинка, отправленная в плату, вылезла назад в правильном сжатом виде. В смысле математики там новизны особо никакой не было - алгоритмы были хорошо известны, мы просто засунули их в Альтеровский чип. Но это было похоже на магию - вы отправляете в некий "чёрный ящик" картинки, он там шуршит своими транзисторами, и вы тут же получаете картинку назад в сжатом виде. Возможно тут примерно тот же случай.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Наука»