Кто не слышал, Тим Брей какое-то время назад решил проверить, как сильно распараллеливаемый Erlang справится с простой задачкой: распарсить Апачевский лог и посчитать в нем количество вхождений каждого URL'а. Это превратилось в долгоиграющую эпопею под названием Wide Finder Project, в которой сейчас участвует куча народу. Одни занимаются тем, что думают, как ускорить Erlang'овую версию, а другие — решением задачки на своих любимых языках.
Известный питонщик Фредрик Лунд сделал свое решение, которое можно демонстрировать как показатель крутости Питона как языка и как платформы. Для затравки скажу, что изначальное наивное решение на Питоне "в лоб" он разогнал в 8 раз, а оригинальный Erlang'овый код оно при этому обгоняет в 600 раз.
Я не хочу пересказывать его статью, но очень советую ее почитать и в нее вникнуть. Для себя же я вынес несколько уроков:
- Питон иногда можно тупо оптимизировать, исключив разрешение методов из цикла
- Питон развивают и разгоняют все время, от чего тепло и приятно (это я про новый быстрый алгоритм поиска подстрок в Питоне 2.5)
- GIL не особенно мешает распараллеливанию в тредах даже на таких сильно вычислительных задачах, если применять правильную стратегию (то есть не заставлять треды все время общаться с питоновскими объектами)
- поддержку распараллеливания по процессам в Питоне хорошо бы оформить в какую-нибудь высокоуровневую библиотеку, которая бы автоматизировала вещи типа "выдать следующий кусок из файла", скрывая синхронизацию отработанных разными процессами кусков через маршалинг
Комментарии: 10 (особо ценных: 1)
Особо ценный комментарий
Хех... Надо было все таки дойти по ссылками из статьи Фредрика! Оказывается, есть модуль — processing —, который очень похож на стандартный threading, но работает на процессах, прозрачно обеспечивая межпроцессную синхронизацию По крайней мере, межпроцессная Queue там есть точно.
Кажется, в stackless python было много всякого на тему лёгкой параллеизации, почти что в духе того же эрланга.
Да, впечатляет…
Stackless Python не расползается сам на десяток компов.
Логи тоже сами не расползаются на десяток компов (=
А если и расползаются, то со значительными расходами на IO.
В общем ерланг для распределённой обработки сигналов, а не для CPU-intensive byte crunching.
Да, для всего свои задачи.
Erlang как язык очень интересен как раз для сетевых приложений. Тот же например ejabberd я считаю пошел правильным путем.
И не надо запбывать что erricsson как раз связью и занимается, так что они сделали язык под свои задачи и сделали это похоже красиво.
История продолжается: http://www.dalkescientific.com/writings/diary/archive/2007/10/07/wide_finder.html
Осталось дождаться, что кто-нибудь из Google выложит решение под MapReduce.
Что-то мне подсказывает, что оптимизировать Питончик под эту задачу будет не совсем просто. Хотя в принципе сделать можно всё.
У меня почему-то глючила Queue из модуля processing, когда я туда передавал данные размером больше 100 килобайт. Я забил и вернулся на родные threading и Queue.