0003293: Склейка GeoTiff в несколько потоков на одну задачу

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	Количество тайлов 749769 (575981)/ размер 191595196642 Это чуть больше листа 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 (3744x), vdemidov (56x), rass (2x), Aveveritas (63x), Korobtsov (1x), ygorigor (1x), bk99 (3x), zed (28x), gma (1x), Garl (1x), Parasite (1x), zaresefat (1x)
Total Views	3902
Last View	21-11-2024 13:08

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

SASGIS