Комментарии 17
Заметка, конечно, интересная, но если в Матлабе моделируешь хотя бы больше трех дней, это знаешь и так. Ожидал большего (например, про встраивание C- и Fortran- процедур. Заметка, на которую ссылается автор, о «дебрях», несколько информативнее.
Этих два варианта оптимизации очень хорошо рассмотрены в книге Сергиенка А. Б. «Цифровая обработка сигналов»
Смею заметить, в этой статье в листинге программы не хватает сравнения времени выполнения программы, в чем поможет функция tic; %код% toc; или еще лучше profile report;
Смею заметить, в этой статье в листинге программы не хватает сравнения времени выполнения программы, в чем поможет функция tic; %код% toc; или еще лучше profile report;
Матлаб более выразительный — функции тоже могут принимать массивы, превращаясь в поэлементные. Циклы для поэлементного преобразования массивов нужны редко. В частности в этом примере влоб можно написать так, а если подумать, то и однострочником.
is1=1:nx2;
is2=nx2+1:nx;
x1=(is1-1)*dx;
y1=sin(3*x1);
x2=(is2-1)*dx;
y2=sin(5*x2);
x=[x1 x2];
y=[y1 y2];
Обычно критично не это, а встоенные функции типа interp2 тормозят, так как написаны на матлабе. Приходится искать .mеx аналоги или писать самому на плюсах.ности в этом примере влоб можно написать так, а если подумать, то и однострочником.
is1=1:nx2;
is2=nx2+1:nx;
x1=(is1-1)*dx;
y1=sin(3*x1);
x2=(is2-1)*dx;
y2=sin(5*x2);
x=[x1 x2];
y=[y1 y2];
Обычно критично не это, а встоенные функции типа interp2 тормозят, так как написаны на матлабе. Приходится искать .mеx аналоги или писать самому на плюсах.
is1=1:nx2;
is2=nx2+1:nx;
x1=(is1-1)*dx;
y1=sin(3*x1);
x2=(is2-1)*dx;
y2=sin(5*x2);
x=[x1 x2];
y=[y1 y2];
Обычно критично не это, а встоенные функции типа interp2 тормозят, так как написаны на матлабе. Приходится искать .mеx аналоги или писать самому на плюсах.ности в этом примере влоб можно написать так, а если подумать, то и однострочником.
is1=1:nx2;
is2=nx2+1:nx;
x1=(is1-1)*dx;
y1=sin(3*x1);
x2=(is2-1)*dx;
y2=sin(5*x2);
x=[x1 x2];
y=[y1 y2];
Обычно критично не это, а встоенные функции типа interp2 тормозят, так как написаны на матлабе. Приходится искать .mеx аналоги или писать самому на плюсах.
Если почитать всякие рекомендации от самого же Mathworks, то они всюду призывают использовать вектора, матрицы и т.д. Только вот беда — когда создается simulink модель какого-нибудь устройства обработки сигналов, близкая к аппаратному воплощению (чтобы автоматически получить hdl-код), да еще и с обратными связями — все эти советы становятся неприменимы. Только и остается надеяться на акселераторы, которые в последних версиях стали значительно лучше.
Желание, конечно, замечательное, но сколько я не сталкивался с этим генерированным hdl-кодом, качество его всегда было не очень высокое.
*ни сталкивался
Ну что значит «качество»? Трудночитаем? Да, но и то при необходимости можно разобраться (а уж если есть оригинальная модель, то и подавно). Неоптимален? Тут все зависит от того как нарисована модель — сумматоры и умножители, как их не описывай, будут одинаковы. Пожалуй две основных дыры сейчас при генерации кода (я говорю про HDL Coder) — это отсутствие автоматического временного мультиплексирования и работа с многоклоковыми дизайнами.
Вот код, который выдал мне Matlab в моем топике о stm32:
adcpwm.c
Настройки комментирования по умолчанию. Да и все остальные тоже.
Дикость имен пришла из названий блоков в модели, что легко поправимо.
Кто укажет, где здесь слабые места, буду очень признателен. Заранее благодарю!
В Toyota говорят, что код из Matlab/Simulink на 5% больше и на 15% медленнее, чем финальный код.
Полностью согласен.
Как было замечено, модель тоже нужно уметь отобразить правильно. Здесь тоже есть множество путей решения одной задачи, но не все оптимальны.
adcpwm.c
Настройки комментирования по умолчанию. Да и все остальные тоже.
Дикость имен пришла из названий блоков в модели, что легко поправимо.
Кто укажет, где здесь слабые места, буду очень признателен. Заранее благодарю!
В Toyota говорят, что код из Matlab/Simulink на 5% больше и на 15% медленнее, чем финальный код.
Неоптимален? Тут все зависит от того как нарисована модель — сумматоры и умножители, как их не описывай, будут одинаковы.
Полностью согласен.
Как было замечено, модель тоже нужно уметь отобразить правильно. Здесь тоже есть множество путей решения одной задачи, но не все оптимальны.
Все эти советы дельные, но простые в том смысле, что когда начинаешь писать на матлабе, быстро набиваешь шишки на этих вещах.
Я бы добавил ещё одну очень важную деталь: избегайте функций. Люди, привыкшие к ООП (или хотя бы к процедурному программированию) будут выдавать медленный код на матлабе, т.к. будут выделять элементарные действия в мелкие функции. Вызов функции в матлабе — очень дорогая операция. В некоторых случаях суммирование массива с помощью цикла будет работать быстрее, чем вызов sum(), мы это на 2009b проверяли.
А вот MEX функция на C++ может зачастую сильно ускорить вычисления, несмотря на затраты на вызов. Написание MEX функций является не очень сложным занятием и может быть хорошей альтернативой коду на матлабе (особенно, если использовать что-то типа Intel TBB для распараллеливания). Кроме того, MEX функции позволяют произвести интеграцию MATLAB и вашей библиотеки на C++.
Я бы добавил ещё одну очень важную деталь: избегайте функций. Люди, привыкшие к ООП (или хотя бы к процедурному программированию) будут выдавать медленный код на матлабе, т.к. будут выделять элементарные действия в мелкие функции. Вызов функции в матлабе — очень дорогая операция. В некоторых случаях суммирование массива с помощью цикла будет работать быстрее, чем вызов sum(), мы это на 2009b проверяли.
А вот MEX функция на C++ может зачастую сильно ускорить вычисления, несмотря на затраты на вызов. Написание MEX функций является не очень сложным занятием и может быть хорошей альтернативой коду на матлабе (особенно, если использовать что-то типа Intel TBB для распараллеливания). Кроме того, MEX функции позволяют произвести интеграцию MATLAB и вашей библиотеки на C++.
>>В некоторых случаях суммирование массива с помощью цикла будет работать быстрее, чем вызов sum()
вероятно для большИх массивов, т.к. в матлабе переменные всегда передаются в функцию по значению, что в данном случае не имеет никакого смысла?
вероятно для большИх массивов, т.к. в матлабе переменные всегда передаются в функцию по значению, что в данном случае не имеет никакого смысла?
Я бы добавил ещё одну очень важную деталь: избегайте функций
А я бы не добавлял такой детали. Это преждевременная оптимизация. Портить декомпозицию нужно только в тех местах, где профайлер укажет.
Если матлаб используется исключительно для вычислений, то можно использовать только dll из матлаба,
а реализовывать на С с использованием нужных вам матлабовских структур (вектора, матрицы и т.д.) и функций — они есть в хедерах (*.h).
Хедеры, вроде как идут, в комплекте с Матлабом, ну по крайней мере в версии 5.3 точно было.
а реализовывать на С с использованием нужных вам матлабовских структур (вектора, матрицы и т.д.) и функций — они есть в хедерах (*.h).
Хедеры, вроде как идут, в комплекте с Матлабом, ну по крайней мере в версии 5.3 точно было.
Прочитал и понял, что Numpy/Scipy не так уж и плохи.
Например:
Например:
import numpy as np
x = np.linspace(0, 10, 1000)
y = np.r_[np.sin(3*x[x<5]), np.sin(5*x[x>=5])]
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Увеличиваем скорость вычислений в Matlab