Функция MATLAB Mex не быстрее обычной

Question

Функция MATLAB Mex не быстрее обычной

0

Я знаю, что это не всегда так, но не функции MEX должны повысить эффективность кода, особенно при расчетах?

Я использовал набор инструментов кодера для MEX-функции expm в MATLAB. Я ожидал хорошего повышения эффективности, поскольку эта функция выполняет множество матричных вычислений.

Тем не менее, я не вижу большого улучшения во времени, как показано на рисунке ниже:

X-Axis: Еще одна итерация функции expm

Y-ось: время выполнения для этой функции

Синяя линия: вызов expm функции expm

Красная линия: expm функции EXEX expm

Есть ли причина, по которой версия MEX настолько похожа на обычную версию? Есть ли способ увеличить скорость? Я использовал tic и toc для сбора данных о времени выполнения.

G Boggs 30 окт. 2014, в 19:04

Источник

1

1) Не могли бы вы сообщить средние / средние значения или построить гистограмму их различий? 2) Насколько велики матрицы, которые вы использовали для проверки скорости? Что, если вы увеличите размер матриц?
George 30 окт. 2014, в 18:07
0

Вы обнаружите, что в большинстве случаев алгоритм является наиболее важным фактором. Вполне вероятно, что в ваших тестах накладные расходы на загрузку / использование mex эквивалентны накладным расходам на функцию в Matlab, но я не могу сказать без а) рабочей копии matlab и б) дополнительной информации о том, какими были ваши тесты. Мой опыт показывает, что функции Matlab в целом довольно хорошо оптимизированы, и что некоторые функции Matlab не переводятся в эффективный C / Cpp без некоторой ручной оптимизации.
Baldrickk 30 окт. 2014, в 18:48
0

@George В среднем размер матриц варьируется от 12x12 до 18x18, но это в среднем. Также есть выбросы.
G Boggs 30 окт. 2014, в 20:06
0

Даже если скомпилированная версия более эффективна, чем некомпилированная (хотя я сомневаюсь в этом, см. Ответ Микаэля), я не ожидаю, что она будет работать лучше в таких небольших случаях из-за накладных расходов на вызов функций MEX. Вы пробовали это с большими матрицами, скажем, с сотнями или тысячами строк / столбцов?
George 30 окт. 2014, в 20:09
0

@GBoggs: это также зависит от настроек, которые вы использовали для генерации кода C в MATLAB Coder (вы использовали матрицы фиксированного размера? В настройках проекта есть также вкладка «скорость», где вы можете включить определенные оптимизации). Вы должны опубликовать более подробную информацию о том, как вы скомпилировали функцию, а также код, который вы использовали для тестирования ...
Amro 31 окт. 2014, в 12:33

Показать ещё 3 комментария

Теги:

c++

performance

matlab

mex

2 ответа

Ещё вопросы

1) Не могли бы вы сообщить средние / средние значения или построить гистограмму их различий? 2) Насколько велики матрицы, которые вы использовали для проверки скорости? Что, если вы увеличите размер матриц?
Вы обнаружите, что в большинстве случаев алгоритм является наиболее важным фактором. Вполне вероятно, что в ваших тестах накладные расходы на загрузку / использование mex эквивалентны накладным расходам на функцию в Matlab, но я не могу сказать без а) рабочей копии matlab и б) дополнительной информации о том, какими были ваши тесты. Мой опыт показывает, что функции Matlab в целом довольно хорошо оптимизированы, и что некоторые функции Matlab не переводятся в эффективный C / Cpp без некоторой ручной оптимизации.
@George В среднем размер матриц варьируется от 12x12 до 18x18, но это в среднем. Также есть выбросы.
Даже если скомпилированная версия более эффективна, чем некомпилированная (хотя я сомневаюсь в этом, см. Ответ Микаэля), я не ожидаю, что она будет работать лучше в таких небольших случаях из-за накладных расходов на вызов функций MEX. Вы пробовали это с большими матрицами, скажем, с сотнями или тысячами строк / столбцов?
@GBoggs: это также зависит от настроек, которые вы использовали для генерации кода C в MATLAB Coder (вы использовали матрицы фиксированного размера? В настройках проекта есть также вкладка «скорость», где вы можете включить определенные оптимизации). Вы должны опубликовать более подробную информацию о том, как вы скомпилировали функцию, а также код, который вы использовали для тестирования ...

chappjc · Answer 1 · 2014-10-30T19-39-00.000Z

Здесь, как вызов expm(A) ломается, где A = rand(500,500); ,

Время равномерно распределяется между матричным умножением (F = F*F;) и вызовом дочерней функции PadeApproximantOfDegree. Матричное умножение встроено с использованием очень быстрых функций LAPACK в mkl.dll (функции линейной алгебры MATLAB с использованием Intel MKL).

Здесь, где все время проводится в PadeApproximantOfDegree:

Это не в цикле. Все вызовы встроенных математических математических функций. Если бы были итерации, я бы ожидал, что MATLAB будет немного медленнее, но это всего лишь несколько строк с 1 вызовом, каждый из которых занимает все время. Только матричное умножение в родительском (F*F) называется более одного раза.

На самом деле, я не удивлюсь, если версия MEX будет медленнее, если Coder не сможет использовать оптимизированные многопоточные библиотеки, к которым имеет доступ MATLAB. По-видимому, Кодер управляет.

в последнем вопросе OP было подтверждено , что и MATLAB, и MATLAB Coder реализуют один и тот же алгоритм (приближение Паде с масштабированием и возведением в квадрат) для вычисления экспоненциальной матрицы (хотя небольшое изменение в последних версиях, по-видимому, еще не было перенесено в MATLAB Coder). Фактически, когда я попробовал это в прошлый раз, MATLAB Coder сгенерировал код C, который вызывает функции BLAS / LAPACK ( dgemm , dtstrm и т. Д.), dtstrm конечном итоге должны быть скомпилированы с библиотекой Intel MKL, которая поставляется с MATLAB.
.. Так что я ожидаю, что они будут иметь одинаковую производительность, так как они в конечном итоге будут вызывать те же вычислительные подпрограммы из MKL (также с JIT-компиляцией в MATLAB это должно ускорить базовые циклы в M-коде, чтобы приблизиться к собственной производительности). Если бы MEX был немного медленнее в тестах OP, я бы отнес это просто к накладным расходам, связанным с вызовом MEX-функций.
Чтобы добавить к тому, что сказали chappjc и Amro, в документации упоминается еще несколько стратегий и лучших методов ускорения кода. Первая ссылка описывает, что генерация MEX, когда во время выполнения преобладают оптимизированные встроенные функции MATLAB, обычно не добавляет существенного улучшения производительности.

Mikael Persson · Answer 2 · 2014-10-30T16-22-00.000Z

Большинство функций Matlab являются простыми оболочками, которые вызывают код библиотеки FORTRAN, большинство из которых поступают из LAPACK/EISPACK/LINPACK. Другими словами, встроенный вызов функции matlab уже вызывает скомпилированный код, а не интерпретируемый код matlab (.m sources). Таким образом, MX не может сделать, чтобы улучшить производительность этих вызовов функций.

Компиляция вашего кода в Matlab обеспечит только преимущества, когда вы выполняете большую работу в исходном коде Matlab напрямую. Если ваш код в основном вызывает кучу встроенных функций matlab, особенно матричных функций (которые являются всеми функциями LAPACK), то вы не увидите большого улучшения, только когда у вас есть "ручной" код, т.е. Если вы внедряли что-то вроде "expm" полностью в matlab-коде (в.m файле), тогда это было бы намного быстрее при компиляции с MEX. Вы будете видеть только преимущества компиляции кода matlab, если у вас есть значительное количество собственного кода Matlab, а не если вы просто выполняете несколько вызовов встроенных функций.

Подумайте об этом, почему Mathworks отправит Matlab со встроенными функциями, реализованными как интерпретируемый код matlab? Даже если они реализуют некоторые из своих встроенных функций в коде matlab (который является лишь небольшой долей, поскольку большинство из них - FORTRAN/C/C++), они будут компилировать эти функции перед отправкой, так что вы, как пользователь, получить лучшую производительность из них.

edit expm ? Функция не является нативной функцией. Тем не менее, это не особенно сложная функция - большая часть тяжелой работы выполняется с помощью вызова mldivide .