SASGIS - SAS.Планета
View Issue Details
0003293SAS.Планета[All Projects] Хотелкаpublic24-10-2017 06:4104-02-2019 09:36
Aveveritas 
vdemidov 
highfeaturealways
resolvedfixed 
Windows7Professional
160707 
181221181221 
0003293: Склейка GeoTiff в несколько потоков на одну задачу
Добрый день!
Нельзя ли реализовать многопоточную обработку склейки в сас планете в геотифах. Чтобы один процесс обрабатывался несколькими ядрами и потоками.
По работе приходится клеить большие объёмы, 200k 500k масштабы на 19 уровне. И было бы очень здорово ускорить этот процесс.
VIP
related to 0003403closed vdemidov Ускорение процесса склейки файлов ECW 
Issue History
24-10-2017 06:41AveveritasNew Issue
24-10-2017 06:44AveveritasNote Added: 0018113
24-10-2017 06:54vdemidovNote Added: 0018114
24-10-2017 07:54AveveritasNote Added: 0018115
24-10-2017 09:19vdemidovNote Added: 0018116
24-10-2017 09:28AveveritasNote Added: 0018117
24-10-2017 09:34vdemidovNote Added: 0018118
24-10-2017 09:43AveveritasNote Added: 0018119
24-10-2017 10:01zedNote Added: 0018120
24-10-2017 10:08vdemidovNote Added: 0018121
24-10-2017 10:11vdemidovNote Added: 0018122
24-10-2017 10:14AveveritasNote Added: 0018123
24-10-2017 10:18vdemidovNote Added: 0018124
24-10-2017 10:22AveveritasNote Added: 0018125
24-10-2017 10:25AveveritasNote Added: 0018126
24-10-2017 11:44AveveritasNote Added: 0018127
24-10-2017 12:21vdemidovNote Added: 0018130
24-10-2017 13:07AveveritasNote Added: 0018131
27-10-2017 09:46vdemidovTag Attached: VIP
28-10-2017 13:56vdemidovNote Added: 0018140
28-10-2017 14:19zedNote Added: 0018141
28-10-2017 14:27vdemidovNote Added: 0018142
28-10-2017 14:28vdemidovNote Edited: 0018142bug_revision_view_page.php?bugnote_id=18142#r7214
28-10-2017 14:29vdemidovNote Edited: 0018142bug_revision_view_page.php?bugnote_id=18142#r7215
28-10-2017 16:01AveveritasNote Added: 0018143
28-10-2017 16:26zedProduct Version.Nightly => 160707
28-10-2017 16:26zedSummaryСклейка в несколько потоков на одну задачу. => Склейка в несколько потоков на одну задачу
28-10-2017 20:07vdemidovNote Added: 0018144
28-10-2017 21:02zedNote Added: 0018145
28-10-2017 21:04zedNote Edited: 0018145bug_revision_view_page.php?bugnote_id=18145#r7217
29-10-2017 07:46vdemidovNote Added: 0018146
29-10-2017 08:37zedNote Added: 0018147
30-10-2017 06:41vdemidovNote Added: 0018149
03-11-2017 08:47vdemidovAssigned To => vdemidov
03-11-2017 08:47vdemidovStatusnew => assigned
03-11-2017 08:47vdemidovTarget Version => 181221
03-11-2017 08:47vdemidovSummaryСклейка в несколько потоков на одну задачу => Склейка GeoTiff в несколько потоков на одну задачу
01-12-2017 07:25vdemidovTarget Version181221 => 1906xx
13-12-2017 19:05zedNote Added: 0018239
13-12-2017 19:06zedNote Edited: 0018239bug_revision_view_page.php?bugnote_id=18239#r7279
14-12-2017 08:12vdemidovNote Added: 0018240
06-03-2018 14:59zedNote Added: 0018254
06-03-2018 22:15vdemidovNote Added: 0018255
06-03-2018 22:15vdemidovStatusassigned => resolved
06-03-2018 22:15vdemidovFixed in Version => 181221
06-03-2018 22:15vdemidovResolutionopen => fixed
05-04-2018 13:26zedTarget Version1906xx => 181221
04-02-2019 09:36vdemidovRelationship addedrelated to 0003403

Notes
(0018113)
Aveveritas   
24-10-2017 06:44   
Готов пожертвовать нужную сумму для введения данных опций в сас планету.
(0018114)
vdemidov   
24-10-2017 06:54   
Сомневаюсь что овчинка выделки стоит. Максимум, что можно вынести в отдельный поток, это чтение и декодирование тайлов, а это вряд ли самая трудозатратная операция при склейке. Хотя в целом вопрос интересный. Нужно будет запихнуть счетчики производительности и проверить сколько времени тратится на подготовку исходных данных, а сколько на саму склейку в итоговый формат.
(0018115)
Aveveritas   
24-10-2017 07:54   
Просто я не представляю толком механизма, по которому работает склейка, но если этот процесс удалось бы ускорить за счет распаралеливания операций хотя бы на 20%, то это было бы очень здорово.
Зависит ли скорость склейки от частоты процессора? Просто проанализировав расход системных ресурсов, я пришел к выводу, что склейка упирается в процессор и оперативку. С оперативкой я решил вопрос, добавлением её до 64 гигов. Теперь планета не падает по ошибке оперативки, хотя я так понимаю вообще в программе в определенных режимах существует утечка памяти.
Процессор, что 2.40 Ггц , что 3,20Ггц склейка в пике догоняет каждый раз ядро до 100%
Пробовал клеить с ссд или хардов, но разницы никакой, планета берет с них файлы порциями и фактически не загружает дисковую систему.
(0018116)
vdemidov   
24-10-2017 09:19   
>если этот процесс удалось бы ускорить за счет распаралеливания операций хотя бы на 20%
Это будет сильно зависить от формата в который идет склейка. Например при экспорте в bmp на саму склейку процессор почти не будет задействован. А вот при склейке в ecw/jp2, c большой вероятностью, именно сама склейка и сожрет 90% процессора. Но это чисто мое ощущение и замеров никогда не проводилось. Попробую в ближайшее время добавить счетчики производительности, после чего можно будет посмотреть сколько можно выиграть за счет дополнительных потоков в идеальном случае. Если там для ECW будет меньше 10-15% потенциального выигрыша, то я просто закрою эту хотелку.

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

>я так понимаю вообще в программе в определенных режимах существует утечка памяти.
Не должно быть, но если сможете найти будет очень интересно.
(0018117)
Aveveritas   
24-10-2017 09:28   
С памятью и процессорами понятно, а про склейку в GeoTIFF
(конкретнее с параметрами без сжатия и файл BigTiff) сможете посмотреть пожалуйста. Потому-что мы от ECW ушли к тифам, они клеятся как раз на 15-20% быстрее аналогичного ECW.
(0018118)
vdemidov   
24-10-2017 09:34   
> с параметрами без сжатия и файл BigTiff
Ага. Тогда тут совсем другой расклад будет.
Еще вопрос. Какие разрешения склейки, точнее максимальная ширина, интересуют.
Так как добавление распралеливания, как минимум удвоит требования по памяти на ту же ширину склейки, а как я уже писал ограничение весьма существенное и без перехода на 64 бита непреодолимое.
(0018119)
Aveveritas   
24-10-2017 09:43   
Количество тайлов 749*769 (575981)/ размер 191595*196642
Это чуть больше листа 1:200000 генштаба на 19 уровне.
(0018120)
zed   
24-10-2017 10:01   
Если результирующий формат не предполагает сжатия, то большинство времени будет уходить на декодирование тайлов из кэша, которые скорее всего в jpeg. В таком случае, по идее, можно сделать какой-то механизм параллельной упреждающей загрузки и декодирования тайлов.
(0018121)
vdemidov   
24-10-2017 10:08   
Ага. Я потому и говорю, что совсем другой расклад. Можно сделать IImageLineProvider, который будет запускать несколько потоков и разделять подготовку полоски тайлов на эти потоки. Доступ к результирующему буферу фиг с ним пусть через лок. Не идеально будет, но заметно быстрее при склейке без сжатия.
(0018122)
vdemidov   
24-10-2017 10:11   
> можно сделать какой-то механизм параллельной упреждающей загрузки и декодирования тайлов.
А вот это заметно сложнее. Сейчас при склейке в разные форматы обход может быть разный. В некоторых сверху вниз, в некоторых снизу вверх, а в некоторых, таких как ecw, вообще фиг его знает какой.
(0018123)
Aveveritas   
24-10-2017 10:14   
Да, кэш Беркли используется. Но не принципиально.
(0018124)
vdemidov   
24-10-2017 10:18   
>Да, кэш Беркли используется. Но не принципиально.
Ну, чисто теоретически, он тоже может стать бутылочным горлышком. Доступ к тайлохранилищу идет через свой лок и все потоки будут выполнять его по очереди, так что если окажется, что проблема не в декодировании джепегов, а в чтении базы, то все сведется уже к ожиданию базы или файловой системы.
(0018125)
Aveveritas   
24-10-2017 10:22   
Просто беркли удобнее переносить ,но если с ним сложно, то с родным сасовским кэшем будем работать.
(0018126)
Aveveritas   
24-10-2017 10:25   
Вопрос не втему. А перенос Планеты на x64 рельсы это я так понимаю сложно, долго и никто не заинтересован, или в перспективе планируется?
(0018127)
Aveveritas   
24-10-2017 11:44   
Максимальная ширина 195000, уточнил.
(0018130)
vdemidov   
24-10-2017 12:21   
Ну, в такой постановке задача вполне решаемая. Не совсем тривиальная, но с большой вероятностью скорость склейки заметно возрастет.
(0018131)
Aveveritas   
24-10-2017 13:07   
Буду ждать Вашего вердикта на основании тестов. Вознаграждение за мной, если получится реализовать.
(0018140)
vdemidov   
28-10-2017 13:56   
Проверил. При экспорте в тиф без сжатия, как и ожидалось, 95% времени занимает именно подготовка тайлов. Например экспорт 1,5 ГБайт файла у меня занял 45 секунд, а подготовка тайлов из них 44 секунды.
(0018141)
zed   
28-10-2017 14:19   
Как-то слишком быстро оно у тебя на диск записалось. Всего за 1 секунду 1,5Гб?
(0018142)
vdemidov   
28-10-2017 14:27   
(edited on: 28-10-2017 14:29)
SSD :)
У топикстартера, кстати, тоже SSD
А еще кэширование на уровне ОС. Оно ж сбрасывает линиями, после чего в режиме ДМА пишется на диск, а процессор работает дальше.

(0018143)
Aveveritas   
28-10-2017 16:01   
У меня не ССД, но эту проблему тоже можно решить. Точнее, на каких-то машинах у меня ссд а на большей части хдд.
Т.е. я так понимаю этот процесс можно ускорить?
(0018144)
vdemidov   
28-10-2017 20:07   
> Т.е. я так понимаю этот процесс можно ускорить?
Ну, с большой вероятностью раза в два можно ускорить за счет распаралеливания подготовки тайлов для склейки. Может и больше, но там уже, скорее всего, новые бутылочные горлышки появятся.
Мои условия читайте на форуме в соответсвующей теме.
(0018145)
zed   
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   
29-10-2017 07:46   
>Декодирование 1860 jpeg тайлов, которые участвовали в склейке, заняло около 1,7 сек. (счётчик /Content/TileLoad/LibJPEG/LoadStream), так что ещё присутствует довольно приличный оверхед помимо декодирования.

А у тебя не было, случайно включено наложение гибрида? А то очень уж похоже, что там еще 2 секунды декодирования png должно быть.
(0018147)
zed   
29-10-2017 08:37   
Нет, слоёв/сеток и прочего не накладывалось. Тестировал на свежесозданной ночнушке в отдельной папке, с родным кэшем (пришлось качнуть эти 2 тыс. тайлов). Тест прогонял несколько раз подряд, так что винда наверняка эти тайлы закэшировала и IO можно пренебречь, как мне кажется.
(0018149)
vdemidov   
30-10-2017 06:41   
Возможно. Никогда не утверждал, что там все оптимально сделано. В любом случае, раза в 2 можно ускорить склейку простым разбрасыванием на несколько потоков процессора. Думаю даже специальных усилий с разбрасыванием потоков по ядрам предпринимать не нужно, достаточно поставить их количество в два раза больше чем физических ядер в процессоре.
(0018239)
zed   
13-12-2017 19:05   
(edited on: 13-12-2017 19:06)
Протестировал новую фичу на своём 2-х ядерном проце - стало быстрее процентов на 40-50. Но у меня HDD медленный - проц нагружается максимум процентов на 70, а диск, на который идёт запись, нагружается на все 100%.

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

(0018240)
vdemidov   
14-12-2017 08:12   
> А вот с 8-ми ядерным процессором, да SDD должно быть сильно быстрее.
К сожалению, у меня на 4-х ядрах и SSD ускоряется примерно в той же пропорции.

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

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

Если все это внимательно отслеживать, то просто не понадобится принудительно добавлять фон для непрозрачных тайлов.
(0018254)
zed   
06-03-2018 14:59   
Наверное, тикет можно считать отработанным?
(0018255)
vdemidov   
06-03-2018 22:15   
Да. Что-то я забыл про этот тикет.