Тесты производительности при компиляции и сборке исходников
Сравниваем LBochs на Xiaomi Redmi Turbo 3 с компом 10-летней давности.
На обоих стоит ОС Windows XP SP3 32-битная.
Комп:
4-ядерный процессор Intel i5-4670 (Haswell) @ 3.4 ГГц 2013 года выпуска,
оперативная память DDR3 8 Гбайт (из которых в Windows XP доступны 3,31 Гбайт)
LBochs:
CPU IPS: 30
Clock Sync method: realtime & rtcsync
RAM: 2048 Мбайт (guest и host)
CPU Level: 686 (32-битный)
CPU Model: Pentium IV
Разрешение экрана: 1024х768х32 бит
Screen fitting (Масштабирование на экран): Smart
Quality zoom (Сглаживание при масштабировании): Да
Fix AR 4:3 (Исправить соотношение сторон 4:3): Да
Тест 1 - Полный ребилд PaintCAD 4Windows в Delphi 7
После чистого запуска Windows запускаем тест и не смотрим его результат, т.к. Windows первый раз открывает некешированные файлы, а это гораздо дольше, чем во второе и последующие открытия. А дальше запускаем этот же тест три раза и считаем усредненное значение.
Комп:
4.17 с
4.05 с
4.10 с
Среднее: 4.11 с
LBochs на Redmi Turbo 3:
73.27 с
69.61 с
71.37 с
Среднее: 71.42 с
Итог: LBochs медленнее компа 10-летней давности в 17.4 раза
Тест 2 - Полный ребилд PaintCAD Mobile в Borland JBuilder 2006
Комп:
14.91 с
14.09 с
14.53 с
Среднее: 14.51 с
LBochs - значения менялись (возможно, телефон сам меняет разгон процессора, или какие-то службы фоновые в андроиде/в windows xp то работают, то нет), запустил тест более чем 3 раза:
136.74 с
135.97 с
119.13 с
120.01 с
134.85 с
Среднее: 126.37 c
Итог: LBochs медленнее компа 10-летней давности в 8.7 раза
Тест 3 - Превращение явовского PaintCAD.jar в андроидовский PaintCAD.apk с помощью Microemu
Комп:
19.11 с
18.79 с
18.33 с
Среднее: 18.74 с
LBochs:
370.91 с
400.05 с
420.57 с
Среднее: 397.17 с
Итог: LBochs медленнее компа 10-летней давности в 21.2 раза
Тест 4 - Полный ребилд мобильного андроид-браузера JustCode в Eclipse
Eclipse в LBochs с видеокартой Voodoo Banshee крашит весь LBochs при запуске. При прочтении лога ошибки было обнаружено что ошибка прямо в самом модуле поддержки видеокарты Banshee. На других видеокартах (типа cirrus) все хорошо. Ошибка крылась, как оказалось, в возможностях явовских программ использовать DirectX (DirectDraw) для отрисовки окон.
Про Banshee даже на сайте Bochs написано что сыровата ее поддержка. Видимо одно из таких сырых мест - проблемы с DirectX.
В общем, надо все это поотключать и краша не будет. Для этого в папке eclipse открываем файл eclipse.ini и дописываем в конец (где аргументы ява-машины прописываются) три строчки (без слова vmparam) из этой темы про jbuilder
viewtopic.php?p=3504&hilit=jbuilder#p3504 , а именно:
....
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Xms40m
-Xmx512m
-Dsun.java2d.ddoffscreen=false
-Dsun.java2d.noddraw
-Dsun.java2d.d3d=false
И Eclipse работает на видеокарте Voodoo Banshee в LBochs!
(но только если запускать его в свежезапущенном виндоусе. а если до этого запускали уже jbuilder - то при запуске eclipse снова краш lbochs. Вероятно, jbuilder дергает каким-то образом через те три команды в настройках directx отрисовку, и когда эту отрисовку второй раз отменяют уже в eclipse - ей это не нравится)
Ребилд с вызова команды Run на очищенном билде до появления окошка "выберите эмулятор или реальное устройство для запуска этого apk". Понятно что кроме самого ребилда в это измеряемое время будет входить запуск исполняемых файлов эмулятора, проверка наличия эмуляторов (виртуальных устройств) и настоящих подключенных по USB устройств, чтоб это окошко со списком эмуляторов появилось. Но зато когда окошко появляется - APK уже лежит готовый в папке bin проекта. Поэтому будем считать этот момент появления окошка гарантированным окончанием сборки APK. И измерять время сборки по нему.
Комп:
4.90 с
4.70 с
4.94 с
Среднее: 4.85 с
LBochs:
788.55 с
792.26 с
Среднее: 790.41 с (т.е. 13 минут с лишним)
Итог: LBochs медленнее компа 10-летней давности в
161.3 раза (вот это Эклипс... =) )
Дополнительные тесты - Ребилд PaintCAD 4Windows в Delphi 7
Убираем сглаживание и обработку граф.вывода (не помогло ускорить)
LBochs на Redmi Turbo 3:
Поправил параметры отрисовки на менее требовательные:
Screen fitting (Масштабирование на экран):
Shrink only (Только уменьшать)
Quality zoom (Сглаживание при масштабировании):
Нет
Fix AR 4:3 (Исправить соотношение сторон 4:3):
Нет
83.22 с
79.36 с
77.72 с
Ничего не изменилось, даже немного ухудшилось. Отрисовка со сглаживанием этот телефон явно не напрягает =)
Обратно включил настройки сглаживания, растягивания на экран и фиксации 4:3 соотношения.
Выбираем другие процессоры в LBochs (не помогло ускорить)
Сменил процессор на Atom N270, рестартнул LBochs:
119.49 с
112.12 c
Сменил процессор на Core Duo T2400, рестартнул LBochs:
121.42 с
115.34 с
Сменил процессор обратно на Pentium IV, рестартнул LBochs. Начались чудеса)
33.77 с
59.83 с
85.44 с
Всегда бы так работал, чтоб за 33 секунды =)
Включаем Ultimate mode на Redmi Turbo 3 кнопкой в шторке сверху экрана (не помогло ускорить)
Включил Ultimate Mode в настройках (быстрее разряжается батарея телефона, что-то это должно ускорять)
84.80 с
Выключил Ultimate Mode (ничего не ускорилось ведь)
Поворачиваем экран горизонтально, эмулятору придется рисовать увеличенный сглаженный экран (не помогло ускорить, и замедлить тоже не помогло)
Повернул экран в горизонтальное положение
82.11 с
Горизонтальное положение его не тормозит, но и не ускоряет
А как всё было на старом Redmi Note 8 Pro (было еще медленнее в 2 раза)
Попробовал запустить LBochs на старом телефоне Redmi Note 8 Pro (там Windows 98 стоял, выбран Pentium IV, 256 мегабайт оперативной памяти). Полный ребилд занимает времени побольше:
179 секунд
160 секунд
Т.е. на Redmi Note 8 Pro эмулятор LBochs работает минимум раза в 2 медленнее.
Что делает в LBochs режим синхронизации часов slowdown (тормозит всё еще в 4 раза)
Продолжаем с Redmi Turbo 3
Поменял Clock Sync method на slowdown, рестартнул LBochs.
322.95 секунд! 322/80 = 4 раза. Slowdown замедляет эмуляцию в 4 раза, получается.
Играем с частотой обновления экрана настройках Redmi Turbo 3 (не помогло ускорить)
В настройках телефона
Settings - Display & brightness - Refresh rate есть выбор частоты обновления экрана. По умолчанию телефон сам выбирает - и когда-то обновляет экран с частотой 120 Гц, когда-то включает 60 Гц. Выставим принудительно в 60 Гц, возможно это снизит нагрузку на телефон и эмулятор станет работать быстрее. Пробуем:
87.28 с
84.74 с
83.12 с
Среднее: 85.05 с
Теперь наоборот - выставим принудительно частоту обновления экрана 120 Гц. Пробуем:
83.81 с
80.49 с
80.46 с
Среднее: 81.59 с
Принудительная частота 120 Гц даже ускоряет (немного, на 4%) сборку =) А, в общем-то, разительно не влияет на скорость сборки.
Используем ускоритель Game Turbo в Redmi Turbo 3 (не помогло ускорить)
Game Turbo - ускоритель игр Xiaomi спрятан в приложении Security. При первом запуске он добавляет свой ярлык на "рабочий стол" телефона. Пробуем добавить в него LBochs - тогда при запуске LBochs появляется шторка сбоку экрана, в ней можно посмотреть график загрузки телефона и переключаться на вкладке Ultimate mode между режимами Balanced и Wild Boost.
LBochs с Game Turbo в режиме Ultimate mode - Balanced:
85.98 с
90.03 с
86.42 с
Среднее: 87.48 с
LBochs с Game Turbo в режиме Ultimate mode - Wild Boost:
86.17 с
87.69 с
85.02 с
Среднее: 86.29 с
Итог: Game Turbo, судя по графикам, увеличивает FPS. Но скорость эмуляции он не увеличивает вообще. Возможно, шторка лаунчера тратит часть ресурсов на свою отрисовку, так что скорость сборки в режимах Balanced и Wild Boost даже слегка спадает =)
Выключаем увеличение оперативной памяти за счет внутренней флешки в Redmi Turbo 3 (не помогло ускорить)
Memory Extension - функция, расширяющая оперативную память за счет использования внутренней флешки как оперативной памяти. Redmi Turbo 3 в настройках по умолчанию стоит дополнительно 4 Гбайт расширенной памяти за счет флешки. Выключаем Memory Extension вообще - телефон перезагружается, и теперь у него честно обычная оперативная память и всё. Может быть (если файл жесткого диска кешируется в оперативную память) такое отключение могло бы ускорить работу эмулятора. Скорость сборки в LBochs с отключенной расширенной памятью:
82.05 с
83.23 с
84.54 с
Среднее: 83.27 с
Итог: отключение Memory Extension не влияет на скорость работы эмулятора.
Настройка видеокарты VGA Freq realtime - включает привязку отрисовки к времени, а не к процессору. По умолчанию - выключена. Поэтому обновление картинки зависит от процессора и параметра IPS (инструкций в секунду). Попробуем ее включить - и посмотрим на скорость сборки:
87.68 с
87.58 с
86.98 с
Итог: VGA Freq realtime не влияет на скорость работы эмулятора
Меняем количество кадров в секунду в настройках видеокарты (не помогло ускорить)
Есть и настройка количества кадров в секунду, отображаемых эмулятором на экран. По умолчанию выставлено 25 кадров в секунду. Минимальное количество кадров в секунду - 5. При таком низком FPS скорость сборки:
84.92 с
86.55 с
86.91 с
Выставим, наоборот, самое высокое количество кадров в секунду - 60. При нем скорость сборки:
88.25 с
88.20 с
88.45 с
Итог: Количество кадров в секунду - тоже не влияет на скорость работы эмулятора на Redmi Turbo 3. Можно выставить 5, можно выставить 60 - эмулятору все равно, при большом FPS скорость упадет не больше чем на 1% (конечно, вопрос с какой скоростью при этом будет тратиться заряд аккумулятора, но это другая история).
Вернем обратно 25 кадров в секунду (для чистоты эксперимента).
Отключаем у приложения LBochs ограничения Battery saver (не помогло ускорить)
В андроиде в свойствах приложения LBochs есть пункт Battery Saver. По умолчанию выбрано "принимать решения самому battery saver-у по поводу ограничений". Попробуем выставить "No restrictions" (Нет ограничений). Скорость сборки без этих ограничений:
76.56 с
74.96 с
76.93 с
Скорость вроде бы выросла. Попробуем снова выставить ограничения как были (чтоб быть уверенным что именно они повлияли). Скорость сборки с ограничениями battery saver:
82.21 с
82.22 с
Может быть когда battery saver активен - то сам решает тормозить ли проги или нет. Снова выключим его, и заодно вообще перезагрузим телефон (чтоб точно сохранилось что Battery saver для LBochs отключен). И опять измерим скорость сборки:
84.78 с
83.31 с
83.09 с
Нет. Скорость снова стала прежней, медленной)
Итог: Battery saver не влияет на скорость работы LBochs
Включаем высокий приоритет среды разработки (помогло ускорить!)
Если воспользоваться стандартным Диспетчером задач Windows (Ctrl+Shift+Esc), например, утилитой Sysinternals Process Explorer в Windows XP, то можно кликнуть правой кнопкой мыши по процессу и в открывшемся меню выставить высокий приоритет для процесса Delphi.
Выставляем realtime (реального времени, т.е. самый высокий, при нем вся система и другие проги виснут почти намертво, но зато ваш процесс работает быстрее) и смотрим скорость сборки:
74.35 с
67.56 с
69.26 с
Переключим приоритет Delphi обратно на normal:
80.46 c
82.36 c
84.02 c
Снова переключим на realtime:
75.07 с
74.35 с
Снова переключим на normal:
85.64 с
Снова переключим на realtime:
73.65 с
Итог: выставление приоритета процесса вашей среды программирования на realtime (ну или любой повыше normal) действительно ускоряет сборку. В данном случае время сборки сократилось на 15% где-то (что неплохо!). Мало того - все верхние прыжки с 75 до 85 секунд и обратно - видимо, следствие запуска в Windows XP фоновых процессов от других программ. При высоком приоритете они не мешают - и всегда за 70-75 секунд происходит сборка. А при обычном приоритете - чаще всего мешают и тогда сборка замедляется до 85 секунд =)
