Слишком медленно работает код C++ на Android. Это нормально?

Question

[Александр Алексеев]

Всем привет! Начитаю изучать программирование под Android с применением библиотеки OpenCV. Скорость работы Native кода меня разочаровала. Ручной перебор пикселей работает примерно в 10 раз медленнее, чем на процессоре х86. Оптимизацию в CMakeLists.txt включал, но не знаю правильно ли это было сделано. Далее я замерил скорость работы функции:
cv::cvtColor(mat, gray, cv::COLOR_RGBA2GRAY);
Она тоже примерно в 10 раз отстаёт.
А размытие по гауссу с радиусом 15 отстаёт по скорости аж в 50 раз:

cv::GaussianBlur(gray, gray_blurred, cv::Size(), 15.0);

Я только на днях начал изучать программирование под андроид и только вчера попробовал NDK, поэтому многое для меня непривычно. Такое сильное отставание смартфонов от ПК -- это нормально? Я ожидал, что замедление будет раза в 2-4, тем более для Native, но не в 50 раз. Есть подозрение, что библиотека на ПК активно использует векторные инструкции и, возможно, многопоточность, в то время как на смартфоне эти фичи по умолчанию почему-то не задействованы, но это вряд ли. Мне сейчас просто интересно мнение тех, кто пишет на C++ под андроид и ПК.

Comments

[Олег]

Из всего вопроса понял только Ручной перебор пикселей
Пиксели для обработки всегда брал из картинки все сразу.
Потом работал с массивом интов.
даже на чистой яве за разумное для меня время получается провести цепочку графических преобразований
И за один прием потом присваивал битмапу.

[Александр Алексеев]

Олег, мне интересно сравнение скорости работы одинаковых алгоритмов на ПК и смартфонах. Бэнчмарки в интернете найти не смог. На яве и андройде алгоритм может работать "быстро", но относительно среднестатистического ПК это будет медленно.

[Олег]

Правильнее сравнивать на планшете с двойной загрузкой (андроид или винда).
Так как первая большая разница в процессоре. В смартфонах и планшетах камень заточен под низкое энергопотребление. Ну скорость оперативки в десктопах и планшетах разная. А для просчета графики ОЗУ важно.

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

Третье отличие в том как коду из вашей библиотеке предоставляются процессорные ресурсы
https://developer.android.com/training/articles/pe...

В андроиде ваша либа точно будет работать на фоновом потоке, так как запуск ее на UI треде вызовет ANR через 500 милисекунд.

[Денис Загаевский]

А измерялись непосредственно нативные вызовы, или вызовы этих методов из джавы?

[Александр Алексеев]

Денис Загаевский, вот пример кода с замером:

void JNICALL
Java_com_example_nativeopencvandroidtemplate_MainActivity_benchmarkFromJNI() {
    cv::Mat mat1 = cv::Mat::zeros(1000, 1000, CV_8UC4);
    cv::Mat mat2 = cv::Mat::zeros(1000, 1000, CV_8UC1);
    std::chrono::system_clock::time_point start =  std::chrono::system_clock::now();
    for(int i = 0; i < 1000; ++i) {
        cv::cvtColor(mat1, mat2, cv::COLOR_RGBA2GRAY);
        cv::cvtColor(mat2, mat1, cv::COLOR_GRAY2RGBA);
    }
    std::chrono::duration<double> dur = std::chrono::system_clock::now() - start;
    __android_log_print(ANDROID_LOG_DEBUG, TAG, "benchmark computation time = %f seconds\n", dur.count());
    using namespace std::chrono_literals;
    std::this_thread::sleep_for(20000ms);
}

Работает ровно в 10 раз медленнее, чем на интеловском процессоре.

Answer 1

[Deiwan]

Андроид просто платформа послабее винды(или линукса) да и само устройство оперативки меньше имеет чем комп, поетому я предполагаю что проблема в ОС или ОЗУ, а не в фичах

Answer 2

[maaGames]

1. одинаковый исходный код на х86 и ARM может работать с ОЧЕНЬ разной производительностью
2. java код в целом может работать быстрее, чем нативный С++, если время на вызов и преобразование данных будет больше, чем время работы нативной функции. Т.е. вызовы нативных функций из ява кода может ухудшить производительность, а не улучшить.

Comments

[maaGames]

Igor Borisov, Есть высокопроизводительные дохренаядерные ARM процессоры. Так что (1) делится на две части, что железо может быть на порядки слабее и, что код может быть написан с учётом х86 архитектуры, а для ARM надо было писать совсем иначе.
Впрочем, я это пишу без пруфов. Мне было проще Java изучить, чем на С++ писать с учётом особенностей платформы, даже не стал с NDK плотно разбираться.

[maaGames]

Igor Borisov, Очень сильно не вдавался в подробности, почитал сводные таблички с тестами и поверил, не проверяя. В общем, если основную часть приложения писать на NDK, то всё было супер. А если всё приложение на java и только отдельные функции, особенно в циклах, вызывались из нативного кода, то работало даже медленнее. Сама функция работала быстро, а вот её вызов был намного дольше вызова java функции.
Кстати, я не спорю, что размытие по Гауссу на андроиде работало медленнее из-за чистой разницы в производительности с большим ПК.

Answer 3

[Олег]

Андроид заточен под телефон. Служба телефонии должна работать надежно. Остальное там просто гость.
Даже программа, с которой сейчас взаимодействует пользователь может быть убита в любой момент.
Вся архитектура андроид приложения строиться над тем, что сейчас делает пользователь. Как только окно уходит
под другое, так сразу же оно переводится в состояние остановлено.
Возможности фоновые процессов в новых версиях зарезали по самое горлышко. Из-за попыток продлить время работы от батерии, теперь почти не возможно сделать то-то долго работающее в фоне. А ресурсы процессора достаются по остаточному принципу.

Comments

[Олег]

Igor Borisov, Сталкивались с тем как китайские прошивки у ТВ боксов себя ведут ?
Моментальный кил твоего приложения при StartActivityForResult ;(
Андроид Go и то так не зверствует

Answer 4

[Александр Алексеев]

Нашёл бэнчмарки для своих процессоров. Такой разрыв в скорости -- это не нормально. Позже буду детальнее изучать проблему.