Форум SAS.Планета

Назрело, назрело...
В эту тему будут переезжать (ну или задаваться напрямую, если вдруг удача) все ну совершенно нубские вопросы, заданные в тех или иных ветках. Ибо сколько ж можно игнорировать уже заданное\отвеченное другими, не напрягать межушный нервный узел, и не юзать поиск... Будет этакий паноптикум и парад юзеров, цинично игнорящих RTFM.

Если у кого из старожилов ВНЕЗАПНО нахлынет приступ альтруизма - то могут и поотвечать, а нет - так и нет. Тем хуже для задавших - тема будет безжалостно модерироваться.

kerby2000 писал(а):11.7 это размер tar.gz файла
полный размер разархивированой папки:

Код: Выделить всё

sergey@nas:/torrent/torrentsru SAS/cache/yamapng$ ls
z1  z10  z11  z12  z13  z14  z15  z16  z17  z18  z19  z2  z21  z23  z24  z3  z4  z5  z6  z7  z8  z9
sergey@nas:/torrent/torrentsru SAS/cache/yamapng$ du -ch | grep total
35G     total

gzip не очень хорошо пакует png (точнее, почти никак), так что суммарный размер файлов должен быть ненамного больше 11 GB. A du показывает занимаемое место на диске с учётом кластеров (собсна, Disk Usage). Впрочем, в данном вопросе это не важно.

количество файлов такое:

Код: Выделить всё

sergey@nas:/torrent/torrentsru SAS/cache/yamapng$ time find . -type f | wc -l
7753887

real    7m25.455s
user    0m9.530s
sys     1m42.900s

Да, я посчитал хорошо.
Вот, смотрите на приложенные файлы:
А сколько у вас показывает, пришлите пожалуйста ваши настройки?

Действительно, 7.7 млн файлов, а программа показывает 22 млрд...
Но SAS.Планета показывает правильно!
Она показывает не сколько файлов в кэше, а сколько в принципе всего тайлов в выделенной области!
Вы выделили весь мир, а надо выделять только интересующие области.
Посмотрите на вкладке Download, сколько тайлов занимает карта всего мира на зуме 18?
17 миллиардов. Плюс на зуме 17 - 4.3 млрд, 16 - 1 млрд и т.д. Так что в сумме наверно и получится 22 млрд.

Можно подробную инструкцию, как это делать

Я, правда, не уверен, что этот способ работает с iPhone, а с МЯК 3 я делаю так:
Выбираю всю територию, экспорт - масштабы с 1, например, по 10.
Потом выбираю территорию поменьше, экспорт - масштабы с 11 по 13, в ту же папку. В случае МЯК ничего не испортится, т.к. разные зумы хранятся в разных папках.
Ну и так далее.


Судя по картинкам, Вам нравится англоязычное меню (как и мне). Скачайте 110427.Beta, в ней английский текст полностью переработан.

гугл удалил снимки моего города. в Google Earth, по меню вид - исторические изображения, открыл карту города 2007 года. мне нужно ее выкачать для распечатки. как это можно следать с помощью SAS. планета?

Tolik писал(а):

kerby2000 писал(а):11.7 это размер tar.gz файла
полный размер разархивированой папки:

Код: Выделить всё

sergey@nas:/torrent/torrentsru SAS/cache/yamapng$ ls
z1  z10  z11  z12  z13  z14  z15  z16  z17  z18  z19  z2  z21  z23  z24  z3  z4  z5  z6  z7  z8  z9
sergey@nas:/torrent/torrentsru SAS/cache/yamapng$ du -ch | grep total
35G     total

gzip не очень хорошо пакует png (точнее, почти никак), так что суммарный размер файлов должен быть ненамного больше 11 GB. A du показывает занимаемое место на диске с учётом кластеров (собсна, Disk Usage). Впрочем, в данном вопросе это не важно.

вот и прекрасно значит карта на iPhone будет занимать те же ~12 ГБ. Я даже на iPhone жены смогу установить

Я, правда, не уверен, что этот способ работает с iPhone, а с МЯК 3 я делаю так:
Выбираю всю територию, экспорт - масштабы с 1, например, по 10.
Потом выбираю территорию поменьше, экспорт - масштабы с 11 по 13, в ту же папку. В случае МЯК ничего не испортится, т.к. разные зумы хранятся в разных папках.
Ну и так далее.

Yandex Maps for iPhone 4.1.0 хранит карты в одном файле Tiles.db
Такой функциональности у вас пока нет
viewtopic.php?f=39&t=1345
В случае экспорта в Google Maps, у вас файл перезаписывается, так что комбинация из разных территорий невозможна
А в чем проблема экспорта только тех тайлов, что находятся в кеше?

Как я уже писал в предыдущем письме, я готов взяться за разработку конвертера для iPhone 4 и для Yandex Maps for iPhone 4.1.0. Вы бы не могли прислать свои наработки, чтобы с нуля этим не заниматься. Мне бы хотя бы кусок кода, который у вас отвечает за экспорт в iPhone ver 2.2+. Я попробую написать консольный конвертер под Линуксом, у меня кеш стоит на RAID5 c XFS и проблем со скоростью доступа к файлам не должно быть, ну а если и будут, можно все файлы в рамдиск перенести.

Еще я подумал, что для такой многочасовой задачи экспорта может пригодиться CUDA, я как раз собирался что-то под CUDA написать, но не было задачки Тут есть что распараллеливать. Что думаете?

kerby2000 писал(а):А в чем проблема экспорта только тех тайлов, что находятся в кеше?

Вообще-то такой проблемы нет, экспортируются только те файлы, что есть в кэше.
Проблема в том, что программа (няп) перебирает все тайлы из выделенной области, и на это уходит много времени.

Может быть, можно изменить алгоритм так, чтобы программа перебирала только тайлы из кэша и их экспортировала? Было бы здорово. Вопрос к разработчикам.

Tolik писал(а):

kerby2000 писал(а):А в чем проблема экспорта только тех тайлов, что находятся в кеше?

Вообще-то такой проблемы нет, экспортируются только те файлы, что есть в кэше.
Проблема в том, что программа (няп) перебирает все тайлы из выделенной области, и на это уходит много времени.

Может быть, можно изменить алгоритм так, чтобы программа перебирала только тайлы из кэша и их экспортировала? Было бы здорово. Вопрос к разработчикам.

Дык, а вы кто? Я думал разработчик. Кому конкретно задавать вопросы и с кем говорить про участие в проекте, если это возможно?
Можно и в личку.

kerby2000 писал(а):Дык, а вы кто? Я думал разработчик. Кому конкретно задавать вопросы и с кем говорить про участие в проекте, если это возможно?

Я инженер техподдержки
А разработчики - feya, vdemidov и примкнувший к ним zed

kerby2000 писал(а):Тут есть что распараллеливать. Что думаете?

С такими исходными данными и с желанием "завоевать" весь мир (до последнего зума) надо смотреть в сторону распределённых вычислений. Просто распараллелить по ядрам толку будет немного.
Насколько хорошо именно параллелится экспорт в ябломяки - не могу сказать, не знаю алгоритма. Но из теории следует очевидная вешь, что не разнеся кэш по вычислительным нодам, принципиально не получится добиться ускорения больше единицы.

kerby2000 писал(а):Yandex Maps for iPhone 4.1.0 хранит карты в одном файле Tiles.db

Кстати, новая версия МЯК для iPhone будет использовать тот же (новый) формат кэша, что и МЯК для других платформ, например, 3.91 бета для Symbian:
http://clubs.ya.ru/mobilemaps/replies.x ... maps-55758
Экспорта в этот новый формат пока нет, хотелка есть №658.

Бета-тестирование МЯК 4.2 для iPhone уже началось:
http://clubs.ya.ru/mobilemaps/replies.xml?item_no=55877

vasketsov писал(а):

kerby2000 писал(а):Тут есть что распараллеливать. Что думаете?

С такими исходными данными и с желанием "завоевать" весь мир (до последнего зума) надо смотреть в сторону распределённых вычислений. Просто распараллелить по ядрам толку будет немного.
Насколько хорошо именно параллелится экспорт в ябломяки - не могу сказать, не знаю алгоритма. Но из теории следует очевидная вешь, что не разнеся кэш по вычислительным нодам, принципиально не получится добиться ускорения больше единицы.

А вы бы не могли тут по подробней объяснить, почему распараллеливание по ядрам тут не поможет?
Вы считаете bottleneck'ом будет I/O, а не CPU ?
CUDA сообщает повышение обработки параллельных алгоритмов до 100 раз.
Вот я и хотел бы знать как алгоритм экспорта тут работает ?

kerby2000 писал(а):А вы бы не могли тут по подробней объяснить, почему распараллеливание по ядрам тут не поможет?

Я не утверждаю, что совсем не поможет. Просто подозреваю, что практически работающего решения не получить. Ну уменьшится время с 10 лет условно до 5 - какая разница?

kerby2000 писал(а):Вы считаете bottleneck'ом будет I/O, а не CPU ?

Понятия не имею. Я не знаю алгоритма экспорта.

Общая логика такова. Пусть задача выполняется за время t на одном узле. На N узлах та же задача выполняется за время T. Тогда ускорение будет равно t/(TN). Понятно, что в обычных случаях при идеально распараллеливаемом алгоритме с отсутствием побочных затрат на синхронизацию и межузловое взаимодействие невозможно достичь ускорения больше 1. Чтобы решить задачу быстрее в N раз, обычно надо увеличить число узлов никак не меньше чем в N раз. Пример практически идеально распараллеливаемом задачи для SAS - это скачивание тайлов (для идеалистов - с нескольких сетевых интерфейсов, на несколько хардов,...), в простейшем случае один "поток" качает с одной стороны списка тайлов, другой - с другой. Условие остановки работы алгоритма известно заранее и не меняется (впрочем, алгоритм легко модифицируется и для случая докачивания области ответственности одного "потока" другим "потоком"), специальная синхронизация не нужна (как если бы потоки качали тайлы с одной стороны примерно по очереди через одного и не лезли вдвоём за одним тайлом). В общем, полная аналогия с каменщиками, кладущими стену из кирпичей. Но увеличить скорость более чем вдвое так не получится.

Здесь написано "обычно" - потому что бывают случаи, когда ускорение реально бывает больше 1. Чтобы понять, когда это бывает, надо в деталях знать алгоритм. Реальный пример могу привести, как задачи матфизики считают. Есть много процессоров, у каждого свой сетевой интерфейс и свой диск для данных - по сути процессорный кэш. Если общий массив даных не может быть поделён на все процессоры (а судя по всему это Ваш случай, ибо я не поверю, что в ближайшее будущее будет создан "железячный" кэш на сотню гигов и соответствующие бытовые процы с соответствующми коммуникациями) - придётся использовать "дорогую" скачку по сети во время работы (аналогия с бытовым компом весьма очевидна). Однако начиная с некоторого числа процессоров взаимодействие по сети скачкообразно сводится к минимуму (обусловленному обработкой граничиных условий, передачей данных между узлами и т.п.) - данные полностью попали в кэш. Впрочем, при дальнейшем увеличении количества вычислительных узлов ускорение где-то опять начнёт падать. Просто потому что невозможно любой параллельный аглоритм бесконечно масштабировать. Даже если (добиваясь максимальной производительности) строить стену в один кирпич толщиной и высотой (этакая дорожка из кирпичей), и каждый каменщик возьмёт по кирпичу и приготовится его поставить на место по команде, добавление новых каменщиков никак не скажется на скорости работы, а ускорение очевидно уменьшится (вследствие увеличения числа каменщиков). Поэтому определение оптимального числа вычислительных узлов является составной частью реализации параллельного алгоритма.

kerby2000 писал(а):CUDA сообщает повышение обработки параллельных алгоритмов до 100 раз.

Ну, обещать-то можно многое. Например 2 - это тоже "до 100". Мой опыт в параллельным вычислениях говорит, что если серебряная пуля и существует, то явно не в этой области. Даже для казалось бы вдоль и поперёк изученных вычметодов решения уравнений матфизики не всегда известна (в смысле "доказана") оптимальная архитектура решения.