Новая резалка по-новому режет

Пару недель назад Йохен Топф рассказал про новую функцию osmium-tool: режим extract для вырезания областей. Диаграммы в заметке показывают, что osmium вырезает в два-три раза быстрее, чем osmconvert. То есть, как когда-то osmconvert заменил osmosis, потому что был не в пример быстрее, так теперь osmium, кажется, может заменить его.

Я решил сравнить утилиты чуть тщательнее и взял файл планеты в pfb от 30 января. Сделал его копию в o5m — формат стал популярен именно из-за osmconvert, который обрабатывает его чуть быстрее других. И поскольку osmuim не умеет писать в o5m, а только читает, сравнил скорость преобразования обратно в pbf:

33 минуты против 86! Серьёзная заявка на победу. Причина проста: osmium многопоточный. Пока osmconvert вяло крутит 70% одного ядра процессора, его конкурент задействует 265%, то есть, около трёх ядер. Отсюда и разница в 2,6 раза.

Для проверки вырезания регионов я взял Мюнхен, который в pbf займёт примерно 200 мегабайт. Вырезал по прямоугольнику и по полигону из 1200 точек. У обоих утилит есть настройка полноты вырезанных данных: простой режим сохраняет только те точки, что попали в область обрезки. Сложный «complete ways» досыпает точек за пределами области, которые принадлежат линиям изнутри её. То есть, в итоговом файле не будет неполных линий. Режим «complex ways» («smart» в osmium) дополнительно сохраняет целостность мультиполигонов.

Как видно, при работе с pbf osmium в полтора-два раза быстрее osmconvert. Разумеется, за счёт многопоточности. Но с o5m работать в несколько потоков не получается, поэтому столбцы красного оттенка отличаются несильно. Как видно, нет такого режима выгрузки, в котором osmium не превзошёл бы osmconvert.

Превосходство будет ещё заметнее, если не читать файл планеты для каждого региона отдельно, а вырезать несколько регионов за раз. Да, osmium это умеет. Правда, требует очень много памяти: Йохен советует сначала вырезать континенты, затем группы стран и так далее. Понадобится написать файл конфигурации, как описано в документации. В январе на многопоточное одновременное вырезание регионов перешли в Geofabrik, ускорив подготовку выгрузок с 10 до 4 часов.

А теперь непонятная диаграмма, дополняющая предыдущую:

Утилита time, которой я замерял время работы, выдаёт «real time», время от запуска до остановки, и «user time»: время процессора, затраченное исключительно на приложение. И если я правильно понимаю, osmium оказался менее оптимизированным, чем osmconvert, но он эффективнее использует ресурсы компьютера.

Итак, osmium может заменить osmconvert, и почти всегда окажется быстрее. Кроме того, он позволит снять зависимость от формата o5m, который хоть и поддерживается osm2pgsql и другими программами, основанными на libosmium, но требует больше места и дополнительной конвертации. Что с другими приложениями из комплекта osmctools?

Osmupdate удобен простым обновлением выгрузки или файла планеты. Достаточно указать в параметрах имя существующего и нового файла, и получим данные из OpenStreetMap на минуту запуска. Умеет ли подобное osmium-tool? Нет, к сожалению. Но osmupdate — лишь надстройка над wget и osmconvert, скачивающая файлы репликации и передающая в osmconvert для объединения и применения к исходному файлу. Osmium-tool может делать всё, что умеет osmconvert, и возможно слегка переписать osmupdate, чтобы он запускал его вместо osmconvert (и заодно curl вместо wget). Или встроить подобную функциональность в osmium — увы, пока этого никто не сделал.

Но в плане сравнения производительности можно посмотреть на время обновления файла планеты диффом за одни сутки:

Как и обещала справка osmconvert, файлы в формате o5m он обрабатывает быстрее. Как показали прошлые замеры, osmium работает быстрее независимо от формата.

Заменой для osmfilter должен стать osmium-filter. Мне удалось его скомпилировать, но я так и не разобрался в его формате запросов. Инструкция из readme не помогла. Поэтому сравнивать пока нечего. Увы, именно osmfilter требует формата o5m, поэтому если в ваш процесс обработки данных входит, например, фильтрация береговой линии, полностью снять зависимость от o5m не получится.

И ещё одно может стать препятствием: пакет osmctool очень редко обновляется, и потому он достаточно свеж во всех дистрибутивах Linux. А режим extract в osmium-tool появился только в версии 1.5, которая на этот момент загружена только в репозитории Debian (jessie-backports) и, конечно, AUR для Arch Linux. В Fedora устанавливается версия 1.4.0, а в Ubuntu — вообще 1.3.1. Для этих систем придётся собирать osmium-tool из исходников.

Тестирование проводилось на среднем по характеристикам ноутбуке Asus с четырёхъядерным i7-4700 @ 2,4 ГГц с гипертредингом, 12 гигабайтами памяти и каким-то HDD.

Поделиться
Отправить
Запинить
3 комментария
Vort

По поводу user time: значительная часть времени, скорее всего, идёт на организацию взаимодействия между ядрами процессора.

freeExec

Формат o5m можно обрабатывать в несколько потоков если его правильно подготавливать. Формат предусматривает таблицу секций, а каждую секцию можно обрабатывать независимо. Другое дело, что сейчас эту таблицу не заполняют даже для быстрого перемещения между nodes, ways и relations.

Илья Зверев

Всё так, но до сих пор, как понимаю, существует только одна сишная реализация чтения и, особенно, записи в o5m. Не многопоточная. Если бы кто-то — хотя бы автор формата — написал пример чтения в несколько потоков, формат был бы более конкурентен.

freeExec

Можно конечно попробовать, правда у меня реализация на С# и секцию с jump я не реализовывал, т. к. нигде не использовалась. Но в свете многопоточности возможно стоит прикрутить. Вдруг догоню osmconvert :)