[SOLVED] Оптимизация Питона
Ставя около 400+ бинарных пакетов на машину типа второго пентиума, я обратил внимание, что скачка и распаковка на ней занимают секунды, а вот примитивные файловые операции, которые делает portage - по паре минут на пакет. Причем затык не в IO, а в нехватке процессорных мощностей - все время висит нагрузка в 100%.
Скажу честно - я не люблю питон. Потому как если где-то что-то адски тормозит и жрет при этом прорву памяти, то скорее всего это что-то на питоне. Тот же перл, хоть и тоже интерпретатор, но работает в 3-10 раз быстрее, в зависимости от типа задачи.
Но, похоже, весь portage на питоне и с этим ничего нельзя поделать.
Итак, вопросы знатокам:
Стоит ли принудительно собрать portage на какой-то определенной версии питона (2.7, 3.3?), чтобы повысить производительность?
Есть ли какие-нибудь очевидные методы оптимизации скорости работы питона через его конфигурацию?
Есть ли альтернатива portage, написанная не на питоне?
-------------
Краткий итог:
- pypy - не вариант
- максимальная производительность у python3
- для дальнейшей оптимизации надо переходить с portage на paludis
- возможный вариант: ставить бинарные пакеты, подключив удаленные разделы по fuse и используя PORTAGE_ROOT, PORTAGE_CONFIG_ROOT
- Для комментирования войдите или зарегистрируйтесь
Вы хоть, надеюсь ставите из
Вы хоть, надеюсь ставите из бинарных пакетов, а не собираете на этой машине систему ?
Лучше возьмите соберите всю систему в chroot на более мощном ПК, потом заархивируйте установленую систему и распакуйте этот архви на целевом слабом ПК. Либо можете, если диск не медленный, подключить диск к мощному ПК и собирать систему в chroot прямо на этом диске, а потому просто подключите диск к слабому ПК.
С другой стороны, даже если ставите из бинарных пакетов, то лучше всё же установите систему в chroot на мощном ПК, т.к. portage всё равно будет тратить существенное время на просчёт зависимостей.
Удачи.
У меня нет более мощного ПК с
У меня нет более мощного ПК с ARM-процессором. Пакеты собираю на ~amd64 под qemu-static-user, и они-таки бинарные. Потому и возмущаюсь, что пакет эмержится быстро, а инсталлится черти-сколько и все из-за питона.
Вот нашел pypy2_0, но его под ARM нет вообще. Все равно попробую собрать и посмотреть, что из этого выйдет. Хотя предчувствия негативные - он хочет 2 гигабайта только для установки, а это уже как бы символизирует его отношение к ресурсам:
26188 portage 20 0 3135428 2,804g 3908 R 100,0 8,9 58:33.97 python2.7По итогу:
Походу python3.3 самый быстрый, а pypy - бесполезен (
Используйте нативный питон. У
Используйте нативный питон. У меня такая конфигурация работала. Подмонтируйте биндом рут в какую-нибудь папку и временно заменити python на скрипты для запуска нативной системы. Когда потребуется собирать питонозависимые пакеты, верните его обратно.
Локальный оверлей растёт
А какая целевая машина?
А какая целевая машина? Зачастую на реальном процессоре сборка быстрее. К тому же какой-нибудь телефон/планшет может собирать пакеты круглые сутки, а купить его можно за пару тыщ (б/у для таких целей сгодится)
Локальный оверлей растёт
Raspberry Pi rev2. Одно ядро
Raspberry Pi rev2. Одно ядро @ 900 МГц, 512 оперативка.
Собираю на машине с i7-3930K @ 3.20ГГц - шесть ядер. Получается намного быстрее - малинка несчастный gcc почти сутки собирала, а эмулятор за час управился. Ну и это позволяет экспериментировать - так бы я месяц ждал пока бы система собралась хотя бы раз.
Одна проблема - под эмулятором не собирается ни Хромиум (ругается на Thumb-1, даже если заставить его собираться под softfp), ни FF. Вот, подготовил все остальные пакеты и попробую собрать Хромиум уже на Raspberry. Быть может проблема в эмуляторе, потому как вроде бы ARMv6 имеет Thumb - флаги в cpuinfo есть.
Короче, утром выясню )
Тогда ясно, RPi действительно
Тогда ясно, RPi действительно не быстрые, к тому же i7. У меня Allwinner A10, он чуть быстрее. gcc не замерял, но FF 8 часов собирал. Когда я сравнивал двухъядерный core2 2.6GIPS + qemu и телефон PNG6715 416мгц, то телефон собирал быстрее несмотря на 2 потока.
Локальный оверлей растёт
А получилось в итоге собрать?
А получилось в итоге собрать? Потому как Хромиум у меня опять не собрался: http://system.crits.ru/trash/chromium-32.0.1700.39.armv6hardfp.build.log.terminal
RPi не поддерживает нужных
RPi не поддерживает нужных ассемблерных комманд. Сам crhomium не собирал, но webkit-gtk у меня не собирался по похожим причинам. С какими CFLAGS собираете? И с какими USE'ами? Под pnx6715 я браузеров не собирал т.к долго и не нужно, по ресурсам будет только opera mobile нормально работать и управлять браузером с телефона было бы не удобно.
Это куда лог так красиво выложен?
Локальный оверлей растёт
http://system.crits.ru/cfg/ar
http://system.crits.ru/cfg/arm/portage/ - тут весь конфиг.
На целевой системе почти такой же, за исключением buildpkg
Лог лежит на той же машине, которой собирал пакеты. Она домашним сервером работает. А оформление - скриптом конвертирую ansi в html для всех файлов с расширением .terminal на лету.
кроме 3-его питона скорее
кроме 3-его питона скорее всего ничего не поможет.
обсуждалось уже кучу раз
а pypy это глупость
Почему? Под ним portage
Почему? Под ним portage работает. Правда, почему-то, почти в два раза медленнее, чем под python3.3.
Извините, но моя Равшана так
Извините, но моя Равшана так и не понел, зачем нужен портейдж на целевом хосте
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Ради обновления системы,
Ради обновления системы, разумеется.
man PORTAGE_ROOT,
man PORTAGE_ROOT, PORTAGE_CONFIG_ROOT, ${ED} ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Спасибо, я как-нибудь
Спасибо, я как-нибудь обойдусь без необходимости бегать с SD-карточкой от компа к компу каждый раз, как мне потребуется обновление или новый пакет. :-)
Кстати, имхо все эти игры с *_ROOT - весьма небезопасны, поскольку отдельные пакеты плевать на них хотели и инсталлятся куда и как сами считают нужными. сhroot все-таки надежнее.
>>Спасибо, я как-нибудь
>>Спасибо, я как-нибудь обойдусь без необходимости бегать с SD
ИМХО бег это хорошо. Вместо сд карточки рекомендую использовать утяжелители, так будет эффективней. А для работы - замонтируйте удаленный корень (ну хотя бы при помощи sys-fs/sshfs-fuse).
>>поскольку отдельные пакеты плевать на них хотели
Можно уточнить какие?
По теме вопроса. Вроде как палдуису пистон не нужен. Почему бы в качестве пакетного менеджера не использовать его? Ну и базу /var/db/pkg/ посмотрел.
Практически ничего не изменилось. Для бинарей вполне можно свой пакетник на шелле прописать.
Я начал как раз с базовых
Я начал как раз с базовых инструкций по crossdev, где рекомендуют PORTAGE_CONFIG_ROOT. Собирая какой-то пакет - увы, уже не вспомню какой, наткнулся на конфликт с уже имеющимися файлами. Удивился. Полез читать и быстро нашел рекомендацию не делать так, а делать через chroot, а еще лучше через chroot+эмулятор.
Вот, собственно, с тех пор так и делаю. Это не отменяет fuse, но, в целом, если реальный затык на IO, как подсказывают ниже, то без разницы. :-(
А что за палдуис?
sys-apps/paludis видимо
sys-apps/paludis видимо
Интересная с виду вещь.
Интересная с виду вещь. Посмотрю.
А есть какие-то очевидные подводные камни и т.д.?
для встроенных систем вроде
для встроенных систем вроде ка кбыл pkgcore , незнаю на сколько он сейчас жив
"pkgcore is the latest of the
"pkgcore is the latest of the new generation package manager. Although at time of writing it cannot replace portage completely due to external tools trying to invoke emerge directly"
Согласно вики, сей пакетный менеджер "нового поколения" требует не токмо питон, но еще и портаж. И последний фикс был в августе 2012 года (пруфлинк https://code.google.com/p/pkgcore/issues/list?can=1&q=&colspec=ID+Type+Status+Priority+Milestone+Modified+Owner+Summary&cells=tiles)
Для встроенных систем используется это: http://code.google.com/p/opkg/ . В портажах есть app-arch/ipkg-utils. Но конвертить бинарь в ipkg имхо муторно. С палдуисом в качестве пакетника для бинарей должно быть полегче ибо почти родной.
>Причем затык не в IO, а в
>Причем затык не в IO, а в нехватке процессорных мощностей - все время висит нагрузка в 100%.
не знаю, как на малинке, но когда я года 3.5 назад экспериментировал с роутером, то IO было тухлым именно из-за того, что оно в значительной части обслуживалось процессором. Поставил файл копироваться – загрузка сразу 100%. Так что может и не питон?
/
Приснопамятный iowait bug (#12309)?
:wq
--
Live free or die
Это интересное замечание. Вот
Это интересное замечание. Вот что показывает топ на распаковке исходников:
%Cpu(s): 4.0 us, 8.4 sy, 0.0 ni, 0.0 id, 86.9 wa, 0.0 hi, 0.7 si, 0.0 st KiB Mem: 476044 total, 385108 used, 90936 free, 8224 buffers KiB Swap: 1052668 total, 316 used, 1052352 free. 210252 cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 41 root 20 0 0 0 0 S 3.9 0.0 0:48.53 mmcqd/0 866 root 20 0 26540 6972 1660 S 2.6 1.5 0:55.39 wicd 917 root 20 0 16260 6196 1876 S 1.0 1.3 0:20.95 wicd-monitor 3055 root 20 0 5168 1348 1008 R 1.0 0.3 0:06.67 toptar и xz даже не вошли в топ-5 процессов, хотя, разумеется, регулярно там всплывают. А wait доходит до 97%.
Вряд ли это имеет отношение к питону - там-то висят 100% нагрузки от самого питона, но такие проблемы с io - тоже не дело.
Поиск по форумам не дал ответа как это исправить - vm.vercommit_memory и vm_dirty_* не помогли, а остальные решения специфичны для ядер ~2.6, тогда как у меня - 3.10.25
сначала смотреть ps на
Сначала смотреть ps на предмет флага D – какой из процессов ожидает ввода-вывода (судя по топу, вычислительные мощности этими процессами не потребляются – может все-таки просто тухлое IO на малинке? :)).
Еще можно для общей картины iostat глянуть.
*upd* А еще есть iotop – он ЕМНИП на питоне :) Ну и в ядре кой-чего повключать может придется.
Может быть и тухлое, там же
Может быть и тухлое, там же SD-карта. Пусть и хорошая.
iotop смотрел, при распаковке чего-либо наверху болтается [jbd2/mmcblk0p2-]
Интересный момент, с которым я не знаком. На x64:
rootfs on / type rootfs (rw) /dev/sda3 on / type ext4 (rw,noatime,commit=60,commit=0) -- интересно, откуда тут появился второй commit?На RPi:
rootfs on / type rootfs (rw) /dev/root on / type ext3 (rw,relatime,data=ordered)Ну не успевает значит на
Ну не успевает значит на карту писаться/читаться. Не знаю, насколько может помочь использование ubifs/jffs2/yaffs2/logfs, но я бы взял бы какой-нить sys-block/fio и сравнил бы с extN, особенно латентность.
Насчет 2х коммитов – тут такое же безобразие описывается, хотя не знаю, Ваш ли случай.
Случай похож на мой, спасибо.
Случай похож на мой, спасибо. Поправил параметры, ночью перегружу машину, проверю...
fstab не заполнен?
fstab не заполнен?
Локальный оверлей растёт
Заполнен: localhost ~ # cat
Заполнен:
Я все же склоняюсь, что фаты
Я все же склоняюсь, что фаты и эксты – не лучший выбор для SD. Возможно, что специализированные FS покажут в чем-то лучшие результаты.
FAT - это требование самой
FAT - это требование самой rpi для boot-раздела. На основном разделе, возможно, лучше была бы ext4 или jfs.
В свете «немощности» IO
В свете «немощности» IO логично использовать FS, которая бы оптимизировала/минимизировала записи. Хотя кто знает, какие у Вас задачи – может туда лучше подойдет xfs c agcount=100 или вообще btrfs для скраба и дедупликации :D
На данный момент это просто
На данный момент это просто игрушка, от которой я хочу:
- Десктоп. xfce + хоть какой-нибудь браузер. Эдакий микрокомп-на-всякий-случай.
- Управление внешним железом. Тут надо еще подумать о контроллере, я использовал до этого Phidget, то в России он редко встречается, да и цена явно неадекватна относительно цены самого rpi. Надо поискать еще какие-нибудь управляемые через usb реле с хорошим временем срабатывания.
- Видеонаблюдение. Небольшая вебкамера и слив потока по wifi на сетевой диск.
- Если нападет креатив, то сделаю из нее уникальный дверной звонок с распознаванием лиц и хорошим синтезатором "приветствий".
- Если все будет совсем лень, то превращу ее в wifi-роутер.
ну я вообще-то утрировал про
ну я вообще-то утрировал про FS :)
А RTC уже прикуплен? Я как-то тоже хотел приобрести малинку, но как-то достаточно негатива прочел. Еще и удивился, что RTC на борту нет.
>wifi-роутер
интересно, какую скорость передачи данных удастся выжать? :)
>xfce
lxde м/б?
>браузер
можно midori попробовать собрать. он почти взрослый.
А зачем RTC? Она на старте
А зачем RTC? Она на старте получает время через NTP. Т.е., конечно, плохо, что RTC нет, но не критично.
Скорость передачи, думаю, будет лимитирована "свистком", а не процессором, все-таки по сравнению с роутерами это почти суперкомпьютер - отличный роутер Zyxel Keenetic имеет процессор втрое слабее и памяти всего 64М, а не 512М.
xfce мне привычнее, но если будет тормозить - попробую что-то другое. Хотя, обычно, ресурсы жрет сам x11.
Что же до браузера, то вот уже сутки собирается FF. На эмуляторе он падал в конце сборки. Тут тоже, наверное, упадет. Но надо сперва проверить, а судя по темпам проверка займет еще пару дней. Если не получится, то буду искать альтернативы. А пока попробую поставить midori на эмуляторе.
/
С учётом зависимостей (WebKit'а) я бы не сказал, что Midori (или кто ещё, начная с uzbl) соберётся быстрее/проще.
:wq
--
Live free or die
Да я уже вижу - эмулятор уже
Да я уже вижу - эмулятор уже два часа вебкит собирает. Какое-то запредельное количество варнингов сыплется в лог. В основном о неиспользуемом хламе и ошибках типизирования. Я каждый раз когда такое вижу - глаза кровью наливаются как у граммар-наци. :-(
Буквально хочется взять и уе... подарить разработчикам учебник по C++.
Update:
Сборка не удалась, ибо make: execvp: /bin/sh: Argument list too long
ENV ничем таким не занят. Так что, подозреваю, что придется увеличивать лимиты вручную. Но прежде чем пересобирать ядро все же спрошу - есть какой-то более простой способ решить эту проблему?
уже пора ставить «SOLDER»?
уже пора ставить «SOLDER»? Питон-то соптимизировался вроде :D
Походу, в этот раз выиграл
Походу, в этот раз выиграл Питон, так что можно ставить [SLOWED]. :-)
Но тема принесла много интересных побочных решений.