Тестирование мультипоточности в Symbian

    Недавно мы ставили SDK для разработки под Qt for Symbian на Linux. Теперь пришло время что-нибудь написать на нем.
    Сейчас практически везде используются многопоточные архитектуры для выполнения каких-либо фоновых расчетов в то время как пользователь использует UI.
    Давайте разберемся, насколько это эффективно при разработке под Symbian.

    Для тестов был взят телефон Nokia 6120c (S60 v3 FP1). В свое время этот телефон был популярен как бюджетный и небольшой смартфон и является вполне типовым устройством на платформе Symbian.

    Описание тестирования


    В качестве фоновых расчетов был взят алгоритм проверки чисел на простоту. Он достаточно прост и короток и в то же время потребляет нехило процессорного времени.
    bool isPrime = true;
    for (int i = 2; i <= currentDummy/2; isPrime &= (currentDummy%i) != 0, ++i);


    * This source code was highlighted with Source Code Highlighter.


    Для чистоты эксперимента мы пробегаем все числа, а не останавливаемся на первом найденном делителе (иначе потоки бы завершались с очень большим временным разбросом). Данные между потоками разделены равномерно и не отрезками числовой прямой, а чередуются между потоками (что опять же дает нам более честный эксперимент с практически одновременно завершающимися потоками).

    Код класса потока (выложен финальный и включает в себя два варианта сразу, об этом подробнее чуть ниже).
    //workerthread.h
    #ifndef WORKERTHREAD_H
    #define WORKERTHREAD_H

    #include <QThread>

    class WorkerThread : public QThread
    {
    Q_OBJECT
    public:
      explicit WorkerThread(int start, int end, int step, QObject *parent = 0);

    signals:
      void updateProcess(int value);

    public slots:

    protected:
      void run();

    private:
      int rangeStart;
      int rangeEnd;
      int rangeStep;
    };

    #endif // WORKERTHREAD_H

    //workerthread.cpp
    #include "workerthread.h"

    WorkerThread::WorkerThread(int start, int end, int step, QObject *parent) :
      QThread(parent), rangeStart(start), rangeEnd(end), rangeStep(step)
    {
    }

    void WorkerThread::run()
    {
      int currentDummy = rangeStart;
      int currentProcess = 0;
      while (currentDummy <= rangeEnd)
      {
        bool isPrime = true;
        for (int i = 2; i <= currentDummy/2; isPrime &= (currentDummy%i) != 0, ++i)
        {
          //Method 2. Slower, but more responsive UI
    //      if (!(i%500))
    //        yieldCurrentThread();
        }
        if (!(currentProcess%1000))
        {
          emit updateProcess(currentProcess);
        }
        currentDummy += rangeStep;
        ++currentProcess;

        //Method 1. Faster, but with UI stucks
        yieldCurrentThread();
      }
      emit updateProcess(currentProcess);
    }


    * This source code was highlighted with Source Code Highlighter.


    Для исследование подтормаживаний UI был взят обычный слайдер, который по таймеру в GUI-потоке менял свое значение. Таким образом, моменты, когда основной поток не получает управление (что и приводит к подтормаживаниям и замерзаниям UI) мы можем отследить по этому слайдеру.
    Вот внешний вид формы тестирования:
    image
    Вполне такой минималистский стиль, выводится только процент выполнения расчетов (прогресс-барами), время выполнения расчетов, индикатор UI, количество потоков и кнопка Start.

    Тестирование


    Как говорилось ранее, у нас два варианта реализации рабочего потока:
    1. Отдавать (yield) управление другому потоку после каждого проверенного числа
    2. Отдавать (yield) управление другому потоку после некоторого количества проверенных делителей

    Даже без тестов понятно, что первый вариант будет быстрее работать, но иногда тормозить UI, а второй будет работать медленнее (за счет большего количества переключений контекста), но и тормозить UI меньше. Весь вопрос насколько это все будет критично и заметно.
    Тестировать будем для 1, 2, 3 и 4 рабочих потоков, оценивая время работы и плавность UI (то есть плавность перемещения слайдера).

    Тестирование первого варианта


    1 поток

    Выполнился за 64255мс, при этом было с десяток подтормаживаний (временем около секунды), но в целом слайдер передвигался плавно.

    2 потока

    Выполнились за 49477мс, при этом было 6 подтормаживаний (временем около секунды). Общие ощущения как от варианта с одним потоком.

    3 потока

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

    4 потока

    Выполнились за 46275мс, при этом работало аналогично варианту с 3 потоками.

    Выводы по первому варианту

    Больше двух рабочих потоков запускать нежелательно, но два потока дают прирост скорости примерно в 25 процентов и практически не влияют на UI.

    Тестирование второго варианта


    1 поток

    Выполнился за 463372мс, при этом было с десяток подтормаживаний (временем около секунды) и очень много мелких (гораздо меньше секунды, но заметных глазу).

    2 потока

    Выполнились за 231544мс, при этом было 6 подтормаживаний (временем около секунды) и также как во варианте с одним потоком очень много мелких.

    3 потока

    Выполнились за 154797мс, при этом было около 5 подтормаживаний (также временем около секунды), но в целом UI работал плавно.

    4 потока

    Выполнились за 116959мс, при этом работало аналогично варианту с 3 потоками.

    Выводы по второму варианту

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

    Общие выводы


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

    Мои выводы


    Я рад подобным результатам, так как они наглядно показывают что даже для бюджетных (и уже достаточно старых) устройств на Symbian можно писать многопоточные приложения без особых проблем, пусть и с несколькими оговорками и дополнительными тестами (например на оптимальную частоту йелдинга).

    Скачать описанное выше


    Исходники
    sis-файл первого варианта
    sis-файл второго варианта

    UPD про приоритеты потоков


    Запустил потоки с Idle и Low приоритетами (запускался только первый вариант тестирования). Результаты оказались даже хуже чем с Normal приоритетом. Два потоки замерли на середине, три и четыре потока замерли почти в самом начале. Скорость отличается в пределах погрешности (48с у двух и 45 у трех и четырех). Судя по всему шедулер не очень хорошо работает с разными приоритетами потоков.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 42

      0
      Nokia 5800., только 4 потока.

      Вариант 1 — завис, после перезапуска — 42346,
      Вариант 2 — без фризов, 114798. После перезапуска результат отличался незначительно.
        0
        А кстати первый вариант с 4 потоками на 5800 после перезапуска без фризов или с фризами также?
        +1
        Насколько мне помнится в Симбиане не рекомендуется злоупотреблять потоками в UI приложении. Для этого лучше использовать отдельный exe и взаимодействовать с ним через Client/server framework. Тогда фризов в приложении не будет, так как оно будет делать то что задумано — отображать данные, а не производить вычисления.
          –2
          Вообще, имхо, симбиан разрабатывали наркоманы. Оперативка в файловой системе, клиент-серверная модель на устройстве с ограниченными ресурсами и производительностью, гуй — отдельная песня. Странный он, проще говоря.
            +5
            Вы категорически не правы, все же Symbian единственная микроядерная мобильная RTOS. А то, что для вас выдумка наркомана, для разработчиков OS было единственным верным решением. Да в ней много вещей которые сначала отпугивают, потом же наоборот, осознаешь, что того же CleanupStack тебе не хватает на других платформах. Есть книга, в которой подробно расписано, что как и почему сделано в Symbian.
            www.amazon.com/Symbian-OS-Architecture-Sourcebook-Evolution/dp/0470018461/ref=sr_1_20?ie=UTF8&s=books&qid=1266887982&sr=8-20
            Главная проблема Symbian — сложность для разработчика на начальных этапах, это не Android, где HelloWorld пишется за 15 минут.
              0
              Возможно вы правы, я сталкивался только с нокиевской реализацией и их монструозным Carbide.UI.
                +1
                Что S60 от Nokia, что UIQ — OS одна и та же, а Carbide — всего лишь инструмент для разработки, основанный на Eclipse.
                  0
                  Ось-та одна, но построение интерфейса на них совершенно разное.

                  С точки зрения пользователя (не разработчика), s60 последнего издания отвратителен в плане юзабилити, т.к. для простых действий приходится совершать множество движений, никак не способствующих быстроте и простоте работы, а некоторые моменты системы попросту блещут своей нелогичностью. С другой же стороны, в некоторых частях системы продемонстрирована потрясающая предусмотрительность, контрастирующая со всей системой в целом.

                  С точки зрения разработчика же — очень высокий входной уровень (освоить симбиан сложней, чем тот же андроид, обджектив си для айфона или винмобайл), но сейчас появляются альтернативы в виде питона / QT-приложений, разработка которых приводит к куда меньшим затратам усилий и средств.
                    0
                    А вы пробовали предыдущие издания S60? Так в общем то было всегда и средств визуального проектирования долгое время не было. У S60 всегда было много косяков и проблемы с документацией, а альтернативный UI (UIQ) для Symbian попросту убили.
                    У Symbian есть шансы на успех, если только они полностью откажутся от наследия S60 и не будут париться о всяких backward compatibility. Только QT поверх Symbian, это мне кажется уже слишком. Так как может привести к путанице с обработкой ошибок/сигналов и прочего.
                      0
                      Немного тыка S60 3rd и UIQ версии тоже. Если третье издание в принципе не особо отличалось от обычных телефонов, как по юзабельности, так и по скорости работы, то пятое… :)

                      Чтобы послать 12 файлов по блютус одной пачкой (5800) нужно совершить… 64 клика. По 5 на каждый файл минимум. Не кажется, что это перебор?
                        0
                        Это плата за визуальную и программную( в некоторой степени) совместимость с предыдущей версий платформы. Нокия решила просто добавить touch в платформу, редизайна UI и юзабилити похоже не производили.
                          –2
                          Программы с S60 v3 не идут на пятом издании. Верней, идут, но на так, в отличии от Java, совсем не откликаются.
                            0
                            *тач
                              +1
                              Не все. Часть все таки идет. Достаточно большое число программ требует просто перекомпиляции. Ну а в остальные надо добавлять поддержку тача.
                              В плане юзабилити и user experience мне кажется между v5 и v3 достаточно много общего, потому и существуют косяки, вроде описанного вами.
                          0
                          А что плохого в Qt? С точки зрения разработчика она куда проще и удобнее, да и возможностей больше. А что насчет путаницы, то разве Symbian не posix совместимая?
                            0
                            В QT нет ничего плохого. Наоборот, данный framework очень хорош. Однако меня несколько беспокоит использование двух различных базовых идеологий. Скажем так, если использовать QT, то надо запретить программистам использовать API Symbian, иначе будет повсеместное использование костылей — приведение строк от платформенного типа к типу в QT, конвертация событий между системой и фреймворком итд.
                              0
                              Насколько мне известно, старый avkon будет выпилен напрочь
              0
              А почему просто не понизить приоритеты вычислительных потоков относительно потока UI?
                0
                Т.Е. Мы добиваемся повышения производительности через многопоточность, и тут же понижаем приоритет расчитывающих потоков?
                  +3
                  1. Повышение производительности через многопоточность возможно только при наличии нескольких вычислительных ядер. Во всех остальных случаях мы добиваемся упрощения логики, уменьшения связности, группировки кода и т.п.

                  2. Приоритет — это штука, которая определяет, какой поток будет исполняться из множества готовых к выполнению потоков. Интерфейсный поток большую часть времени простаивает ожидая сообщений. Однако, коль скоро он получил сообщение, вы сами хотите чтобы выполнялся он, а не вычислители.

                  Поэкспериментируйте, чтоли.
                    +1
                    Теперь все понятно, спасибо :)
                    –2
                    Повышение производительности через многопоточность на одноядерном процессоре? Бугага))))
                    В один момент времени он может обрабатывать только один поток, итого таким образом можно повысить отзывчивость приложения, затолкав длительное действие в отдельный поток
                      0
                      кстати зря смеешься) наилучшее количество потоков n+1 если что (где n-количество ядер), по причине неполной загрузки одним потоком проца полностью (в случае одноядерного проца)
                    0
                    Про смену приоритетов забыл, да. Привык уже что под линем нет их. Вечером дополню статью вариантами с приоритетами.
                      0
                      >Привык уже что под линем нет их.

                      Мсье не в курсе про nice и не слышал про posix?
                        0
                        я про QThread если что
                      0
                      добавил UPD
                      0
                      Используйте системный RThread, а не настройку QThread из Qt.
                        0
                        я так понимаю RThread это чисто симбиановская вещь? стояла цель именно полностью кроссового теста, без каких-либо дополнительных системных библиотек
                          0
                          Учите матчасть! (С)…

                          QThread это чисто cooperative multi-tasking, её предназначение — быстро выполнить какой нибудь асинхронный запрос (HTTP к примеру) и ВСЕ! Производить длительные или CPU интенсивные вычисления в таких нитях строго запрещено, и об этом четко сказано в документации.

                          RThread это системный вызов (аналог pthread) с pe-emptive multi-tasking. Такие нити как раз пердназначены для CPU-intensive вычислений.

                            0
                            В догонку. Даже pre-emptive multi-tasking (т.е. RThread и RProcess) в симбиане реализован крайне кривой, а системный шедюлер — полное говно! Любая нить может полностью повесить операционную систему, чего принципе быть не должно.
                              0
                              Дело не в матчасти (а в симбиане я полный профан, я не спорю). Я говорю про кроссовость.
                              Плюс (опять же не касаясь симбиана, а говоря про настольные оси) кутешная реализация потоков вполне на уровне. По крайне мере на винде (на x86) и на линуксе (x86 и SPARC) меня вполне устроила эта реализация (про SPARC правда могу сказать только за Qt3, я сравнивал это года 3 или 4 назад, когда например wxWidgets работала из рук вон плохо с потоками).
                                0
                                На PC и Sparc-ах вычислительная мощность столь велика (даже по сравнению с самыми современными ARM-ами), что подобные тесты влёгкую «проваливаются» незамеченными для остальных нитей/приложений. Вот вы попробуйте на PC вычислить в одной Q-нитке что нибудь посерьезнее, да подольше — эффект будет точно такой же.
                                  0
                                  ну я проверял на достаточно серьезных и долгих вычислениях) обработка изображения с камеры БПЛА в приближенном к риал-тайм режиме на Эльбрусах это не так-то и просто)
                                    0
                                    Некрокомментинг, канеш, но все ж: эльбурс, если мне память не изменяет — это vliw проц, на котором чем длинней «нитка» — тем лучше, не?
                                  0
                                  Я все к тому, что Symbian надо хоронить! Этот хаотичный набор классов и бесполезных абстракций называть операционной системой не поворачивается язык. И никакой Qt или иная надстройка сверху не только не помогает, а наоборот — усугубляет процесс разработки, так как приходится одновременно бороться с багами и фичами уже двух сложных сущностей, порой противоречивых. Как бы красив и лаконичен не был бы Qt, Symbian все равно все испортит! Это та самая ложка дёгтя, которая из бочки мёда делает бочку говна.
                                    0
                                    ну благо скоро появится Symbian^3, а за ней Symbian^4. Будем надеяться что там все будет гораздо лучше. В последней кстати, Qt будет основой UI.
                                      0
                                      Неа. Symbian^3 и прочее, это очередная поделка финских студентов (или даже переделка S60). От таких поделок надо избавляться на ранней стадии проектирования. Вообще, изобретение операционной системы давно сравнивается с изобретением вечного двигателя, т.е. является абсурдным и бесполезным занятием. Ничего нового в этой отрасли привнести уже давно не возможно, вся теория четко и ясно расписана в учебниках, а имплементировать теорию лучше чем это сделано в ядре Linux или BSD — тянет на нобелевку как минимум (если бы её еще давали за программизм). По этому, надо брать и адаптировать уже имеющиеся стабильные и отлаженные ОС, т.е. Linux. И в этом смысле у Nokia есть отличнеший проект — Maemo. Я был бы несказанно рад, если бы Nokia полность похоронила Symbian и начала бы выпускать девайсы только на Maemo. Технически это весьма просто, но политически — скорее всего нет.

                                      Я считаю, что любая реинкарнация Symbian заведомо обречена на провал, по одной существенной причине — годами заслуженное сугубо негативное отношение к этой ОС среди разработчиков.
                                        0
                                        откуда такие знания про симбиан3? просто из-за отношения к с60 или что-то более значимое? может вы инсайдер в Нокии?
                                          0
                                          Я не инсайдер, я давно пишу софт под S60 и читаю форумы девелоперские. Ничего хорошего из ^3 не выйдет по очевидным причинам.
                                            0
                                            ну то есть я так понял дело именно в отношении к с60?
                                          0
                                          Нельзя так говорить, что Symbian объективно плох. Про минусы уже много сказали, но из плюсов я вижу энергосбережение (до которого Маемо, к сожалению, далеко), реалтаймовость, поддержка symmetric multi-processor.

                                          ИМХО, лучшее, что можно сделать с Симбианом — оставить старые API но пометить их как deprecated (а кому хочется срочно переписывать всю работу с камерой, например, или сложное приложение на Active Objects?). И ввести новые API, основанные на Qt, GSreamer и STL. Компилятор чуть-чуть поновее взять :) (под эмулятор s60 v3 программа собирается компилятором, не знающим слова explicit)

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое