Конвертируем из pbf в sqlite

В общем, залез в код поиска QT в поисках примеров - оказалось, CMAKE не так уж ужасен (только чуть-чуть). Спасибо за подсказки! :slight_smile:

Сделал вариант, с более навязчивыми запросами BOOST_ROOT, ZLIB_* , попробуйте патч:
https://dl.dropboxusercontent.com/u/63393258/CMakeLists.txt.patch

Автору большой респект!

Кстати, а зачем мы PBF конвертируем в SQLITE? )))

Поскольку данные плохо лезут в память, а самим лениво заниматься эффективным ее распределением, то есть надежда, что за нас всё сделает дядя SQLITE.

Под linux от PCH лучше вообще отказаться. Во-первых, по сравнению с адекватной фильтрацией инклудов и использованием forward declarations они дают копеечный выигрыш, который вообще не будет заметен на таком небольшом проекте. Во-вторых, они мешают работе ccache и distcc, от которых пользы намного больше.

PS. Под фрю пока не собралось, там boost 1.52

Смотрю народ на работу вышел :slight_smile: А то, подумал, никому не надо.

Отвечаю на предыдущие вопросы:

Для смаке мне нехватило следующих знаний - на заявленных платформах смаке умеет ТОЛЬКО настроить компилятор, для указанных исходников, И ВСЁ.

Я то грешным делом подумал что они(смаксисты) попытались объединить плюсы основных компиляторов/ide разных платформ. А на самом деле всё что смогли, так это предоставить маке файл и настроить ide на его использование.

Единственный плюс это язык позволяющий добавлять свои фишки для конкретных IDE/платформ. Но я не понимаю как в этом окружении обеспечивать рост знаний. Если я смог настроить смаке проект на два ide/платформы то это не значит что оно заработает на других платформах. Поэтому я никому не расскажу о моём опыте. Переход на 3 одновременно поддерживаемые платформы НЕВОЗМОЖЕН если нет чувака которые может проверить на всех трёх.

to akks спасибо за патч. Применил.

“Кстати, а зачем мы PBF конвертируем в SQLITE? )))” Отвечу вопросом на вопрос. А зачем, вообще, скачивать себе osm?

to “Ivan Komarov” - “Хитрый-относительный” - это вряд ли правильный подход.
Да, вы правы, была ошибка, непонятно как работало :slight_smile:

to “AMDmi3” - Под linux от PCH лучше вообще отказаться…
хм. Я в общем то слаб в линукс. Но мне казалось что PCH уже давно должон был тут появится. Сборкой тут гораздо чаще занимаются чем под win.
gss -x тоже не новая опция. Ну и бог с ней. А вы поможете настроить смаке под ccache и distcc?

to “AMDmi3” - Под фрю пока не собралось, там boost 1.52.
Надо?. Если да. То как скоро? Может подождать до 1.53 на фрю? Иначе шлите мне ошибки компиляции будем думать вместе.

Нет, они сделали систему сборки, и пока лучшую. Компиляторы и IDE с системой сборки никак не связаны.

Да всегда был, собственно, только неудобен и никому не нужен.

Его не надо настраивать, нужно просто добавить в начало $PATH путь к директории с линками ccache и/или distcc.

Мне лично не надо, мне надо чтобы софт не писали под одну платформу :slight_smile:
Лучше подождать 1.53.

Вы либо слишком молоды, либо не писали под Windows.
Посла появления в каждом модуле <windows.h> прекомпайл в умелых руках очень сильно облегчает жизнь.
Шаблоны, пока они в разумных дозах, тоже вполне укрощаются прекомпайлом и на линукс.
Ну а для тех, кто пишет в нынешнем новомодном стиле всю программу шаблонами в хедер-файлах, цепляя как можно больше кривовато написанных сторонних “свободных” библиотек, действительно возможно другие методы будут эффективнее.

Ещё проблема: на конфигурации древний RedHat + вручную собранные gcc4.7.2, zlib, bzip2, boost 1.53 (наш кластер)
после успешного уговаривания Cmake, make выдаёт следующую ошибку компиляции:

/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/PBFRO/PbfFBytes.h:44:19: warning: no newline at end of file
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/OSMPBF/../PBFRO/TFuint.h:182:20: warning: no newline at end of file
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/OSMPBF/../PBFRO/TFsint.h:58:20: warning: no newline at end of file

/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp: In member function `boost::filesystem::path CDB::GetFileNameOut() const':
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:84: error: no matching function for call to `boost::filesystem::path::assign(const char* const&, char*)'
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:207: note: candidates are: boost::filesystem::path& boost::filesystem::path::assign(const char*, const std::codecvt<wchar_t, char, mbstate_t>&)
make[2]: *** [OsmPbf2sqlite/CMakeFiles/OsmPbf2sqlite.dir/DB.cpp.o] Error 1

Это в Boost чего-то не хватает или как?

Угу вторые аргументы у функций не совпали.

“no newline at end of file” поправил

ошибку в CDB::GetFileNameOut() вроде поборол но не проверял, так как на моих системах ошибок нет.

Пожалуйста попытайтесь еще раз.

Ругается ещё страшнее :slight_smile:

/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp: In member function ‘boost::filesystem::path CDB::GetFileNameOut() const’:
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:84:53: error: no matching function for call to ‘boost::filesystem::path::assign(const char* const&, char*)’
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:84:53: note: candidates are:
In file included from /gpfs/soft/boost/include/boost-1_53/boost/filesystem.hpp:16:0,
                 from /gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/stdafx.h:32,
                 from /gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:1:
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:206:11: note: boost::filesystem::path& boost::filesystem::path::assign(const value_type*, const codecvt_type&)
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:206:11: note:   no known conversion for argument 2 from ‘char*’ to ‘const codecvt_type& {aka const std::codecvt<wchar_t, char, __mbstate_t>&}’
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:213:11: note: template<class Source> boost::filesystem::path& boost::filesystem::path::assign(const Source&, const codecvt_type&)
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:213:11: note:   template argument deduction/substitution failed:
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:84:53: note:   cannot convert ‘strrchr(((const char*)((const CDB*)this)->CDB::m_pSource), 46)’ (type ‘char*’) to type ‘const codecvt_type& {aka const std::codecvt<wchar_t, char, __mbstate_t>&}’
In file included from /gpfs/soft/boost/include/boost-1_53/boost/filesystem.hpp:16:0,
                 from /gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/stdafx.h:32,
                 from /gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:1:
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:221:11: note: template<class InputIterator> boost::filesystem::path& boost::filesystem::path::assign(InputIterator, InputIterator)
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:221:11: note:   template argument deduction/substitution failed:
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:84:53: note:   deduced conflicting types for parameter ‘InputIterator’ (‘const char*’ and ‘char*’)
In file included from /gpfs/soft/boost/include/boost-1_53/boost/filesystem.hpp:16:0,
                 from /gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/stdafx.h:32,
                 from /gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:1:
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:227:11: note: template<class InputIterator> boost::filesystem::path& boost::filesystem::path::assign(InputIterator, InputIterator, const codecvt_type&)
/gpfs/soft/boost/include/boost-1_53/boost/filesystem/path.hpp:227:11: note:   template argument deduction/substitution failed:
/gpfs/home/ak/osm/osmpbf2sqlite/OsmPbf2sqlite/DB.cpp:84:53: note:   deduced conflicting types for parameter ‘InputIterator’ (‘const char*’ and ‘char*’)
make[2]: *** [OsmPbf2sqlite/CMakeFiles/OsmPbf2sqlite.dir/DB.cpp.o] Error 1
make[1]: *** [OsmPbf2sqlite/CMakeFiles/OsmPbf2sqlite.dir/all] Error 2
make: *** [all] Error 2

Но если больше ни у кого этой ошибки не будет, смысла мучаться и исправлять нет - система просто тестовая (кластер без обновления основной ОС с 2007 г.).

Видимо, все дело в разных _tcsrchr или std::codecvt . Там в системе 2 разных GCC, причём системный - древнейший 3.4. Я постарался перестроить на новый переменными окружения, но, видимо, не до конца получилось…

Но если кто знает, как “кросплатформеннее” написать boost::filesystem::path sOut; Out.assign(m_pSource,_tcsrchr( m_pSource,_T(‘.’))); - подскажите :slight_smile:

Я достаточно писал под windows в своё время чтобы искренне жалеть тех кто продолжает этим заниматься :slight_smile: Тем не менее отквоченное к windows вообще никак не относилось.

Дальше было и не про windows. Просто под windows пришлось-таки овладеть технологией и использовать на разных платформах.
Если у кого-то не получается, не факт, что технология виновата.

Попытка 2. Добавил изменение в исходники.

Пробуйте.

Добрался до кластера. Всё отлично компилируется, да и выглядит sOut.replace_extension(“.db3”) приятнее :slight_smile: Спасибо!

Решил попробовать на многопоточность (12 ядер на узле всё же). Получилось вот что:
на файле RU-BA.osm.pbf (Башкирия):
1 ядро - 40.6 с
2 ядра - 46.7 с
4 ядра - 46.2 с
12 ядер - 49.4 с
При переходе с жесткого диска на временные файлы в оперативке (/dev/shm) стало на 5 сек. быстрее, но соотношение не изменилось.

То же на рабочей машине под Windows (VS2012,x64) (Core2duo 6700): 1 ядро - 57.5-61.9 с., 2 ядра - 58.9-61 с.
Число ядер менял, передавая его в конструктор:

CThreadManager m_tm(threadsToUse);
info("Thread count: %d\n",m_tm.GetCountThread());

В диспетчере задач число потоков меняется. Что-то здесь не то :slight_smile:

Вы всё правильно делаете.

Получается что boost::mutex работает чуть по другому чем виндовые критические секции. То есть дольше чем я предполагал. В результате расходы на переключения контекста съедают все преимущества мультипоточности.

Или я их неправильно использую. Буду ковырять дальше.

Необязательно. Ещё может быть блокировка на каком-то общем ресурсе. Для анализа желателен профайлер и дампы состояний потоков в ключевые моменты прогона.

Попробовал обновленную версию, всё стало лучше:
1поток - 39 c 2 - 32.2 c 3 - 31.8c 4 - 31.2c 12 - 30.7c
(2x6 core Xeon X5670, Redhat 6)

То же компилятором Intel (лучше оптимизирует):
1поток - 32 c, а больше - хуже

Выгоды от использования больше 2 потоков пока не видно (а на сервере - даже наоборот вред, т.к. тормозится всё остальное), так что предлагаю как-то ограничить программно. Все равно все упрется в диск и SQLITE. Прилагаю свой патч, c которым тестировал (можно выбирать число ядер третьим параметром + в CMake есть закомментированные настройки для нестандартных GCC/boost): https://dl.dropboxusercontent.com/u/63393258/threads.patch

Спасибо. Патч применил.
Теперь количеством потоков можно управлять из командной строки.

По умолчанию теперь 2 потока трудятся.

а как ключи посмотреть?

А нету ключей!
Если екзешник запустить без параметров он скажет чтото умное, про порядок имен файлов.
см https://code.google.com/p/osmpbf2sqlite/source/browse/OsmPbf2sqlite/OsmPbf2sqlite.cpp