SASGIS

Веб-картография и навигация


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003293SAS.Планета[All Projects] Хотелкаpublic24-10-2017 06:4104-02-2019 09:36
ReporterAveveritas 
Assigned Tovdemidov 
PriorityhighSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
PlatformWindowsOS7OS VersionProfessional
Product Version160707 
Target Version181221Fixed in Version181221 
Summary0003293: Склейка GeoTiff в несколько потоков на одну задачу
DescriptionДобрый день!
Нельзя ли реализовать многопоточную обработку склейки в сас планете в геотифах. Чтобы один процесс обрабатывался несколькими ядрами и потоками.
По работе приходится клеить большие объёмы, 200k 500k масштабы на 19 уровне. И было бы очень здорово ускорить этот процесс.
TagsVIP
Attached Files

- Relationships
related to 0003403closedvdemidov Ускорение процесса склейки файлов ECW 

-  Notes
(0018113)
Aveveritas (reporter)
24-10-2017 06:44

Готов пожертвовать нужную сумму для введения данных опций в сас планету.
(0018114)
vdemidov (manager)
24-10-2017 06:54

Сомневаюсь что овчинка выделки стоит. Максимум, что можно вынести в отдельный поток, это чтение и декодирование тайлов, а это вряд ли самая трудозатратная операция при склейке. Хотя в целом вопрос интересный. Нужно будет запихнуть счетчики производительности и проверить сколько времени тратится на подготовку исходных данных, а сколько на саму склейку в итоговый формат.
(0018115)
Aveveritas (reporter)
24-10-2017 07:54

Просто я не представляю толком механизма, по которому работает склейка, но если этот процесс удалось бы ускорить за счет распаралеливания операций хотя бы на 20%, то это было бы очень здорово.
Зависит ли скорость склейки от частоты процессора? Просто проанализировав расход системных ресурсов, я пришел к выводу, что склейка упирается в процессор и оперативку. С оперативкой я решил вопрос, добавлением её до 64 гигов. Теперь планета не падает по ошибке оперативки, хотя я так понимаю вообще в программе в определенных режимах существует утечка памяти.
Процессор, что 2.40 Ггц , что 3,20Ггц склейка в пике догоняет каждый раз ядро до 100%
Пробовал клеить с ссд или хардов, но разницы никакой, планета берет с них файлы порциями и фактически не загружает дисковую систему.
(0018116)
vdemidov (manager)
24-10-2017 09:19

>если этот процесс удалось бы ускорить за счет распаралеливания операций хотя бы на 20%
Это будет сильно зависить от формата в который идет склейка. Например при экспорте в bmp на саму склейку процессор почти не будет задействован. А вот при склейке в ecw/jp2, c большой вероятностью, именно сама склейка и сожрет 90% процессора. Но это чисто мое ощущение и замеров никогда не проводилось. Попробую в ближайшее время добавить счетчики производительности, после чего можно будет посмотреть сколько можно выиграть за счет дополнительных потоков в идеальном случае. Если там для ECW будет меньше 10-15% потенциального выигрыша, то я просто закрою эту хотелку.

>С оперативкой я решил вопрос, добавлением её до 64 гигов.
Почти бессмысленно, так как 32-х битная программа не может использовать больше 3 гигабайт памяти. Остальное только для файлового кэша операционной системы или для запуска дополнительных экземпляров программы.

>я так понимаю вообще в программе в определенных режимах существует утечка памяти.
Не должно быть, но если сможете найти будет очень интересно.
(0018117)
Aveveritas (reporter)
24-10-2017 09:28

С памятью и процессорами понятно, а про склейку в GeoTIFF
(конкретнее с параметрами без сжатия и файл BigTiff) сможете посмотреть пожалуйста. Потому-что мы от ECW ушли к тифам, они клеятся как раз на 15-20% быстрее аналогичного ECW.
(0018118)
vdemidov (manager)
24-10-2017 09:34

> с параметрами без сжатия и файл BigTiff
Ага. Тогда тут совсем другой расклад будет.
Еще вопрос. Какие разрешения склейки, точнее максимальная ширина, интересуют.
Так как добавление распралеливания, как минимум удвоит требования по памяти на ту же ширину склейки, а как я уже писал ограничение весьма существенное и без перехода на 64 бита непреодолимое.
(0018119)
Aveveritas (reporter)
24-10-2017 09:43

Количество тайлов 749*769 (575981)/ размер 191595*196642
Это чуть больше листа 1:200000 генштаба на 19 уровне.
(0018120)
zed (manager)
24-10-2017 10:01

Если результирующий формат не предполагает сжатия, то большинство времени будет уходить на декодирование тайлов из кэша, которые скорее всего в jpeg. В таком случае, по идее, можно сделать какой-то механизм параллельной упреждающей загрузки и декодирования тайлов.
(0018121)
vdemidov (manager)
24-10-2017 10:08

Ага. Я потому и говорю, что совсем другой расклад. Можно сделать IImageLineProvider, который будет запускать несколько потоков и разделять подготовку полоски тайлов на эти потоки. Доступ к результирующему буферу фиг с ним пусть через лок. Не идеально будет, но заметно быстрее при склейке без сжатия.
(0018122)
vdemidov (manager)
24-10-2017 10:11

> можно сделать какой-то механизм параллельной упреждающей загрузки и декодирования тайлов.
А вот это заметно сложнее. Сейчас при склейке в разные форматы обход может быть разный. В некоторых сверху вниз, в некоторых снизу вверх, а в некоторых, таких как ecw, вообще фиг его знает какой.
(0018123)
Aveveritas (reporter)
24-10-2017 10:14

Да, кэш Беркли используется. Но не принципиально.
(0018124)
vdemidov (manager)
24-10-2017 10:18

>Да, кэш Беркли используется. Но не принципиально.
Ну, чисто теоретически, он тоже может стать бутылочным горлышком. Доступ к тайлохранилищу идет через свой лок и все потоки будут выполнять его по очереди, так что если окажется, что проблема не в декодировании джепегов, а в чтении базы, то все сведется уже к ожиданию базы или файловой системы.
(0018125)
Aveveritas (reporter)
24-10-2017 10:22

Просто беркли удобнее переносить ,но если с ним сложно, то с родным сасовским кэшем будем работать.
(0018126)
Aveveritas (reporter)
24-10-2017 10:25

Вопрос не втему. А перенос Планеты на x64 рельсы это я так понимаю сложно, долго и никто не заинтересован, или в перспективе планируется?
(0018127)
Aveveritas (reporter)
24-10-2017 11:44

Максимальная ширина 195000, уточнил.
(0018130)
vdemidov (manager)
24-10-2017 12:21

Ну, в такой постановке задача вполне решаемая. Не совсем тривиальная, но с большой вероятностью скорость склейки заметно возрастет.
(0018131)
Aveveritas (reporter)
24-10-2017 13:07

Буду ждать Вашего вердикта на основании тестов. Вознаграждение за мной, если получится реализовать.
(0018140)
vdemidov (manager)
28-10-2017 13:56

Проверил. При экспорте в тиф без сжатия, как и ожидалось, 95% времени занимает именно подготовка тайлов. Например экспорт 1,5 ГБайт файла у меня занял 45 секунд, а подготовка тайлов из них 44 секунды.
(0018141)
zed (manager)
28-10-2017 14:19

Как-то слишком быстро оно у тебя на диск записалось. Всего за 1 секунду 1,5Гб?
(0018142)
vdemidov (manager)
28-10-2017 14:27
edited on: 28-10-2017 14:29

SSD :)
У топикстартера, кстати, тоже SSD
А еще кэширование на уровне ОС. Оно ж сбрасывает линиями, после чего в режиме ДМА пишется на диск, а процессор работает дальше.

(0018143)
Aveveritas (reporter)
28-10-2017 16:01

У меня не ССД, но эту проблему тоже можно решить. Точнее, на каких-то машинах у меня ссд а на большей части хдд.
Т.е. я так понимаю этот процесс можно ускорить?
(0018144)
vdemidov (manager)
28-10-2017 20:07

> Т.е. я так понимаю этот процесс можно ускорить?
Ну, с большой вероятностью раза в два можно ускорить за счет распаралеливания подготовки тайлов для склейки. Может и больше, но там уже, скорее всего, новые бутылочные горлышки появятся.
Мои условия читайте на форуме в соответсвующей теме.
(0018145)
zed (manager)
28-10-2017 21:02
edited on: 28-10-2017 21:04

Протестировал на своём обычным HDD: при склейке снимка 15200x7776 pix (около 340Мб на выходе) весь процесс занял 5.5 сек, из них 4.5 сек. ушло на подготовку тайлов (из jpeg). И если раскинуть подготовку на 4 ядра, то теоретически, можно склеить секунды за 2. Но тут, по-моему, надо принимать специальные усилия для того чтобы потоки действительно распределялись по разным ядрам, а не исполнялись на одном. Иначе, никакого выигрыша может и не оказаться.

Кстати, тот же участок, при склейке со сжатием LZW, занял 11,5 сек, из них, все те же 4,5 сек на подготовку.

Декодирование 1860 jpeg тайлов, которые участвовали в склейке, заняло около 1,7 сек. (счётчик /Content/TileLoad/LibJPEG/LoadStream), так что ещё присутствует довольно приличный оверхед помимо декодирования.

(0018146)
vdemidov (manager)
29-10-2017 07:46

>Декодирование 1860 jpeg тайлов, которые участвовали в склейке, заняло около 1,7 сек. (счётчик /Content/TileLoad/LibJPEG/LoadStream), так что ещё присутствует довольно приличный оверхед помимо декодирования.

А у тебя не было, случайно включено наложение гибрида? А то очень уж похоже, что там еще 2 секунды декодирования png должно быть.
(0018147)
zed (manager)
29-10-2017 08:37

Нет, слоёв/сеток и прочего не накладывалось. Тестировал на свежесозданной ночнушке в отдельной папке, с родным кэшем (пришлось качнуть эти 2 тыс. тайлов). Тест прогонял несколько раз подряд, так что винда наверняка эти тайлы закэшировала и IO можно пренебречь, как мне кажется.
(0018149)
vdemidov (manager)
30-10-2017 06:41

Возможно. Никогда не утверждал, что там все оптимально сделано. В любом случае, раза в 2 можно ускорить склейку простым разбрасыванием на несколько потоков процессора. Думаю даже специальных усилий с разбрасыванием потоков по ядрам предпринимать не нужно, достаточно поставить их количество в два раза больше чем физических ядер в процессоре.
(0018239)
zed (manager)
13-12-2017 19:05
edited on: 13-12-2017 19:06

Протестировал новую фичу на своём 2-х ядерном проце - стало быстрее процентов на 40-50. Но у меня HDD медленный - проц нагружается максимум процентов на 70, а диск, на который идёт запись, нагружается на все 100%.

А вот с 8-ми ядерным процессором, да SDD должно быть сильно быстрее.

(0018240)
vdemidov (manager)
14-12-2017 08:12

> А вот с 8-ми ядерным процессором, да SDD должно быть сильно быстрее.
К сожалению, у меня на 4-х ядрах и SSD ускоряется примерно в той же пропорции.

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

Так при загрузке jpg можно быть уверенным, что прозрачных пикселей нет, кроме случая, когда картинка меньше тайла. Для некоторых типов png прозрачности не будет. После принудительного добавления фона тоже можно ставить, что непрозрачное. После накладывания прозрачного на непрозрачное, тоже результат известен заранее. При рисовании сеток или карты заполнения, можно быть просто сохранить наличие прозрачных участков. Чуть сложнее с метками, но там можно считать, что прозрачность есть всегда. И тд.

Если все это внимательно отслеживать, то просто не понадобится принудительно добавлять фон для непрозрачных тайлов.
(0018254)
zed (manager)
06-03-2018 14:59

Наверное, тикет можно считать отработанным?
(0018255)
vdemidov (manager)
06-03-2018 22:15

Да. Что-то я забыл про этот тикет.

- Users who viewed this issue
User List Anonymous (3741x), vdemidov (56x), rass (2x), Aveveritas (63x), Korobtsov (1x), ygorigor (1x), bk99 (3x), zed (28x), gma (1x), Garl (1x), Parasite (1x), zaresefat (1x)
Total Views 3899
Last View 21-11-2024 09:34

- Issue History
Date Modified Username Field Change
24-10-2017 06:41 Aveveritas New Issue
24-10-2017 06:44 Aveveritas Note Added: 0018113
24-10-2017 06:54 vdemidov Note Added: 0018114
24-10-2017 07:54 Aveveritas Note Added: 0018115
24-10-2017 09:19 vdemidov Note Added: 0018116
24-10-2017 09:28 Aveveritas Note Added: 0018117
24-10-2017 09:34 vdemidov Note Added: 0018118
24-10-2017 09:43 Aveveritas Note Added: 0018119
24-10-2017 10:01 zed Note Added: 0018120
24-10-2017 10:08 vdemidov Note Added: 0018121
24-10-2017 10:11 vdemidov Note Added: 0018122
24-10-2017 10:14 Aveveritas Note Added: 0018123
24-10-2017 10:18 vdemidov Note Added: 0018124
24-10-2017 10:22 Aveveritas Note Added: 0018125
24-10-2017 10:25 Aveveritas Note Added: 0018126
24-10-2017 11:44 Aveveritas Note Added: 0018127
24-10-2017 12:21 vdemidov Note Added: 0018130
24-10-2017 13:07 Aveveritas Note Added: 0018131
27-10-2017 09:46 vdemidov Tag Attached: VIP
28-10-2017 13:56 vdemidov Note Added: 0018140
28-10-2017 14:19 zed Note Added: 0018141
28-10-2017 14:27 vdemidov Note Added: 0018142
28-10-2017 14:28 vdemidov Note Edited: 0018142 View Revisions
28-10-2017 14:29 vdemidov Note Edited: 0018142 View Revisions
28-10-2017 16:01 Aveveritas Note Added: 0018143
28-10-2017 16:26 zed Product Version .Nightly => 160707
28-10-2017 16:26 zed Summary Склейка в несколько потоков на одну задачу. => Склейка в несколько потоков на одну задачу
28-10-2017 20:07 vdemidov Note Added: 0018144
28-10-2017 21:02 zed Note Added: 0018145
28-10-2017 21:04 zed Note Edited: 0018145 View Revisions
29-10-2017 07:46 vdemidov Note Added: 0018146
29-10-2017 08:37 zed Note Added: 0018147
30-10-2017 06:41 vdemidov Note Added: 0018149
03-11-2017 08:47 vdemidov Assigned To => vdemidov
03-11-2017 08:47 vdemidov Status new => assigned
03-11-2017 08:47 vdemidov Target Version => 181221
03-11-2017 08:47 vdemidov Summary Склейка в несколько потоков на одну задачу => Склейка GeoTiff в несколько потоков на одну задачу
01-12-2017 07:25 vdemidov Target Version 181221 => 190707
13-12-2017 19:05 zed Note Added: 0018239
13-12-2017 19:06 zed Note Edited: 0018239 View Revisions
14-12-2017 08:12 vdemidov Note Added: 0018240
06-03-2018 14:59 zed Note Added: 0018254
06-03-2018 22:15 vdemidov Note Added: 0018255
06-03-2018 22:15 vdemidov Status assigned => resolved
06-03-2018 22:15 vdemidov Fixed in Version => 181221
06-03-2018 22:15 vdemidov Resolution open => fixed
05-04-2018 13:26 zed Target Version 190707 => 181221
04-02-2019 09:36 vdemidov Relationship added related to 0003403



Copyright © 2007 - 2024 SAS.Planet Team