Anonymous | Login | Signup for a new account | 21-11-24 09:34 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0003293 | SAS.Планета | [All Projects] Хотелка | public | 24-10-2017 06:41 | 04-02-2019 09:36 | ||||
Reporter | Aveveritas | ||||||||
Assigned To | vdemidov | ||||||||
Priority | high | Severity | feature | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | Windows | OS | 7 | OS Version | Professional | ||||
Product Version | 160707 | ||||||||
Target Version | 181221 | Fixed in Version | 181221 | ||||||
Summary | 0003293: Склейка GeoTiff в несколько потоков на одну задачу | ||||||||
Description | Добрый день! Нельзя ли реализовать многопоточную обработку склейки в сас планете в геотифах. Чтобы один процесс обрабатывался несколькими ядрами и потоками. По работе приходится клеить большие объёмы, 200k 500k масштабы на 19 уровне. И было бы очень здорово ускорить этот процесс. | ||||||||
Tags | VIP | ||||||||
Attached Files | |||||||||
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 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |