← All posts tagged Python

tilarids

Похоже, я не писал в жуйк о чудесном эксперименте с сортировкой флоатов, который я когда-то проводил. Предлагаю провести его и вам(@SannySanoff, например, тебе). Итак, основа для эксперимента — задачка с Ponder This: domino.research.ibm.com
Если очень кратко: представьте, что вы стоите в саду на плоскости, в точке 0,0. В каждой точке с целыми координатами растёт дерево определенного радиуса. Сам сад тоже имеет радиус — 9801, за пределами сада деревья не растут. Начиная с определенного радиуса деревьев вы не сможете увидеть край сада. Нужно определить радиус, начиная с которого это произойдёт.
Но я хотел рассказать о подзадаче, которая может возникнуть при решении в лоб. Для определённого радиуса деревьев для каждого дерева(если забить на остальные деревья) у вас есть угол, начиная с которого дерево блокирует зрение, и угол, начиная с которого дерево больше ничего не блокирует. Подзадача: для каждого дерева в первой кварте (половина первой четверти) построить пары таких флоатов и затем лексикографически эти пары отсортировать. Пар должно быть около 40 миллионов.
Интересны результаты для разных языков, если писать в лоб и использовать стандартные фичи. С++ очень шустр, требует мало памяти (около 300мб, ЕМНИП). СPython помедленней, но ест тоже совсем чуть-чуть, 500-600мб. PyPy намного быстрее CPython, но и памяти съедает больше гига. OCaml съедал два гига. Другая OCaml версия с чьей-то помощью приближалась к Python по потреблению памяти, обгоняя его по скорости. Java версия сжирала 4 гига, работала очень медленно. А если VM ограничить по памяти, то вообще ооочень медленно. Благодаря помощи джавистов удалось загнать Java в рамки 2-х гигов, но качество кода пострадало. Haskell версию заставить нормально работать я не смог, падала по памяти. JS версия тоже не пережила такие запросы по памяти.
Теперь дополнительно, по выразительности по версиям, которые показывали максимальную производительность при минимальном потреблении памяти:
1 место — Python. Никаких оптимизаций проводить не понадобилось. Сортируем стандартные таплы, получаем малое потребление.
2 место — С++. Никаких оптимизаций проводить не понадобилось. Сортируем пары, получаем скорость и малое потребление.
5 место — Java. Пришлось отказаться от использования стандартных средств языка для работы с парами как с объектами.
8 место — OCaml. После оптимизаций код на OCaml стал больше походить на С, чем на функциональщину.
Обратите внимание на отсутствие 3,4,6 и 7 места. Это из-за разрыва в читабельности. Вывод: Python и C++ — офигенные языки, в которых выразительность не принесена в жертву memory footprint, а в случае с С++ — и скорости. Функциональные языки очень расстроили своим непредсказуемым потреблением памяти. Java удивила тем, насколько простая задача может требовать ручных оптимизаций.
Если кто считает, что я не прав — пишите программы, сравнивайте. Буду рад почитать.

tilarids

Наконец-то заопенсорсил свою прекрасную утилиту для мержа Xcode проектов: github.com
Кто хоть раз пытался замержить Xcode проект тулзами для мержа текстовых файлов знает, насколько это неприятная вещь. Эта утилита мержит Xcode проекты по возможности автоматически, без участия пользователя. Год назад, когда писалась тулза, аналогов не было. Важные моменты:
* Кроссплатформенная. А не только под макосью.
* Читает и пишет Xcode проекты в OpenStep plist формате. CocoaPods, это плевок в вашу сторону. Брать пользовательский файл в OpenStep формате и пересохранять его потом в XML? Вы представляете, как это потом мержить, если вдруг?
* Чтение и запись файла без его изменения должны давать в результате тот же самый файл. Побайтово. Т.е., прогон через тулзу не добавит никаких лишних пробелов, не потеряет комментарии. Тулза старается редактировать файлы так, как их редактирует Xcode.
* У Xcode иногда бывают тяжелые дни и он меняет Xcode проект просто так. Тулза достаточно умная, чтобы распознавать такие ситуации. Это значит, что вам не нужно будет мержить проекты из разных веток, когда вы ничего не меняли, а Xcode все же решил что-то поменять.
* Тулза тестировалась на очень сложных и развесистых проектах. Но она всё еще бета. Используйте на свой страх и риск :)

tilarids

UA PyCon в этом году оказался хорош как никогда, особенно харкдорные доклады второго дня с рекламой postgresql, dtrace, illumos и легких наркотиков от undev. Кто не попал — готовьтесь к следующему году или к RU PyCon, который обещают в феврале в Екатеринбурге

tilarids

PyCon завершился. Как обычно на таких евентах, afterparty и общение в коридорах интересней самих докладов(e.g., после закрытия последних пабов мы еще долго обсуждали формальность математики, вопросы полноты теории множеств и прочие философские вопросы, и это обсуждение было полезней официальной программы конференции). Фотографии с первого дня: picasaweb.google.com

tilarids

Выезжаю. Рюкзак легок, как никогда. Вернусь в Харьков 25-го числа. 24-го, если повезет, попаду на окончание PyCon UA. Если кто из питонщиков будет там — можем пообщаться

tilarids

Подсмотрел у @dk в Google Reader Shared Items, не смог не поделиться, это офигительно:
>> import re
>> R = re.compile(r"^1?$|^(11+?)\1+$")
>> is_prime = lambda x: R.match("1" * x) is None
Функция рабочая. Если кто хочет понять, как это работает (а оно красиво получается, честное слово), вам сюда: noulakaz.net

tilarids

Попробовал для автоматизации функционального тестирования GUI приложения такую интересную штуку, как Sikuli. Представляет собой IDE, с помощью которой пишутся и запускаются тесты на Jython. Основной фишкой и идеей Sikuli является поиск частей изображений по скриншотам. Идеально это проиллюстрировано вот здесь: sikuli.org
Т.е., предлагается программировать при помощи картинок.
На деле:
* Под Windows выглядит и работает плохо. Даже запустить приложение не получилось (встроенные функции не работают, subprocess нет, функции popen2 и os не работают). Поиск изображений иногда не работает
* Под MacOS X выглядит и работает намного лучше, даже вполне юзабельно. Из минусов — dragDrop, похоже, не предназначен для реализации простого drag.
* Нельзя сказать, что такое написание тестов очень быстрое — нашим QA больше нравятся инструменты, которые просто записывают текущие действия и потом повторяют их. С другой стороны, использование высокоуровневого языка позволяет делать интересные проверки
* Модули языка порезаны, средств для красивого и быстрого запуска пачки тестов найдено не было, хотя, возможно, к этому можно приспособить nose.

tilarids

Вот подумываю в качестве эксперимента один небольшой проектик написать на haskell. И вроде как задача подходящая для функционального языка: в основе парсинг бинарных данных. Но начал ближе присматриваться, изучать предметную область и уже вижу, что если начну писать на haskell, то скорее всего кучу ненужной работы доведётся выполнить, потому что вспомогательные библиотеки нужно будет писать самому. А вот для Python такие библиотеки уже есть. Размышляю. Если не смогу найти нужные либы под Haskell, то это может похоронить интересное начинание :(

tilarids

Говорят, что Python — язык медленный. Например, были у нас скрипты, которые генерят тонны плюсового кода. Процесс генерации на виндовой машине с 1.6 ггц процом занимал полтора-два часа. Почему? До некоторых пор считалось что это потому, что Python медленный. Что было мною проделано:
1. Генератор перенёс на linux машину с 2.2 ghz процом. Так как на linux еще и кеширующая подсистема намного лучше, то это дало внушительный скачок производительности.
2. Пофиксил разную фигню, вроде использование list там, где надо использовать set.
3. Убрал постоянное насилование файловой системы (сделал небольшое кеширование в памяти информации о структуре папок на фс). Дало внушительный скачок производительности.
В итоге, сейчас скрипты отрабатывают за 2 с половиной минуты. PROFIT! Дальше оптимизировать уже и смысла нет, скрипты запускаются крайне редко и такая оптимизация понадобилась только для того, чтобы можно было вычистить из скриптов некоторые баги и добавить фичи.
Также интересно, что не помогло в ускорении:
1. Использование cStringIO не является панацеей при работе с большими объемами текстовых данных, как я думал раньше. Прямая запись в файл при работающем кеше отрабатывает быстрее
2. Использование psyco замедляло работу скриптов.
Что еще можно было бы сделать: скрипт до сих пор однопоточный, но при этом распараллеливание возможно.
Вывод: Python совсем не медленный. Если скрипт на Python работает долго, посмотрите на него внимательно. Возможно, несколько часов работы позволят ускорить его в 30-50 раз.

tilarids

Сравнения Торнадо и Erlang-based сервисов: lionet.livejournal.com . В принципе, торнадо выглядит относительно неплохо, но я бы всё же хотел посмотреть и на другие аналогичные сравнения. Например, на ту же джангу с 4мя nginxами, или на cherrypy, или на twisted.web, или на cogen.