|
Notes |
|
|
|
|
Готов пожертвовать нужную сумму для введения данных опций в сас планету. |
|
|
|
|
|
Сомневаюсь что овчинка выделки стоит. Максимум, что можно вынести в отдельный поток, это чтение и декодирование тайлов, а это вряд ли самая трудозатратная операция при склейке. Хотя в целом вопрос интересный. Нужно будет запихнуть счетчики производительности и проверить сколько времени тратится на подготовку исходных данных, а сколько на саму склейку в итоговый формат. |
|
|
|
|
Просто я не представляю толком механизма, по которому работает склейка, но если этот процесс удалось бы ускорить за счет распаралеливания операций хотя бы на 20%, то это было бы очень здорово.
Зависит ли скорость склейки от частоты процессора? Просто проанализировав расход системных ресурсов, я пришел к выводу, что склейка упирается в процессор и оперативку. С оперативкой я решил вопрос, добавлением её до 64 гигов. Теперь планета не падает по ошибке оперативки, хотя я так понимаю вообще в программе в определенных режимах существует утечка памяти.
Процессор, что 2.40 Ггц , что 3,20Ггц склейка в пике догоняет каждый раз ядро до 100%
Пробовал клеить с ссд или хардов, но разницы никакой, планета берет с них файлы порциями и фактически не загружает дисковую систему. |
|
|
|
|
>если этот процесс удалось бы ускорить за счет распаралеливания операций хотя бы на 20%
Это будет сильно зависить от формата в который идет склейка. Например при экспорте в bmp на саму склейку процессор почти не будет задействован. А вот при склейке в ecw/jp2, c большой вероятностью, именно сама склейка и сожрет 90% процессора. Но это чисто мое ощущение и замеров никогда не проводилось. Попробую в ближайшее время добавить счетчики производительности, после чего можно будет посмотреть сколько можно выиграть за счет дополнительных потоков в идеальном случае. Если там для ECW будет меньше 10-15% потенциального выигрыша, то я просто закрою эту хотелку.
>С оперативкой я решил вопрос, добавлением её до 64 гигов.
Почти бессмысленно, так как 32-х битная программа не может использовать больше 3 гигабайт памяти. Остальное только для файлового кэша операционной системы или для запуска дополнительных экземпляров программы.
>я так понимаю вообще в программе в определенных режимах существует утечка памяти.
Не должно быть, но если сможете найти будет очень интересно. |
|
|
|
|
С памятью и процессорами понятно, а про склейку в GeoTIFF
(конкретнее с параметрами без сжатия и файл BigTiff) сможете посмотреть пожалуйста. Потому-что мы от ECW ушли к тифам, они клеятся как раз на 15-20% быстрее аналогичного ECW. |
|
|
|
|
> с параметрами без сжатия и файл BigTiff
Ага. Тогда тут совсем другой расклад будет.
Еще вопрос. Какие разрешения склейки, точнее максимальная ширина, интересуют.
Так как добавление распралеливания, как минимум удвоит требования по памяти на ту же ширину склейки, а как я уже писал ограничение весьма существенное и без перехода на 64 бита непреодолимое. |
|
|
|
|
Количество тайлов 749*769 (575981)/ размер 191595*196642
Это чуть больше листа 1:200000 генштаба на 19 уровне. |
|
|
|
(0018120)
|
|
zed
|
|
24-10-2017 10:01
|
|
|
Если результирующий формат не предполагает сжатия, то большинство времени будет уходить на декодирование тайлов из кэша, которые скорее всего в jpeg. В таком случае, по идее, можно сделать какой-то механизм параллельной упреждающей загрузки и декодирования тайлов. |
|
|
|
|
|
Ага. Я потому и говорю, что совсем другой расклад. Можно сделать IImageLineProvider, который будет запускать несколько потоков и разделять подготовку полоски тайлов на эти потоки. Доступ к результирующему буферу фиг с ним пусть через лок. Не идеально будет, но заметно быстрее при склейке без сжатия. |
|
|
|
|
> можно сделать какой-то механизм параллельной упреждающей загрузки и декодирования тайлов.
А вот это заметно сложнее. Сейчас при склейке в разные форматы обход может быть разный. В некоторых сверху вниз, в некоторых снизу вверх, а в некоторых, таких как ecw, вообще фиг его знает какой. |
|
|
|
|
|
Да, кэш Беркли используется. Но не принципиально. |
|
|
|
|
>Да, кэш Беркли используется. Но не принципиально.
Ну, чисто теоретически, он тоже может стать бутылочным горлышком. Доступ к тайлохранилищу идет через свой лок и все потоки будут выполнять его по очереди, так что если окажется, что проблема не в декодировании джепегов, а в чтении базы, то все сведется уже к ожиданию базы или файловой системы. |
|
|
|
|
|
Просто беркли удобнее переносить ,но если с ним сложно, то с родным сасовским кэшем будем работать. |
|
|
|
|
|
Вопрос не втему. А перенос Планеты на x64 рельсы это я так понимаю сложно, долго и никто не заинтересован, или в перспективе планируется? |
|
|
|
|
|
Максимальная ширина 195000, уточнил. |
|
|
|
|
|
Ну, в такой постановке задача вполне решаемая. Не совсем тривиальная, но с большой вероятностью скорость склейки заметно возрастет. |
|
|
|
|
|
Буду ждать Вашего вердикта на основании тестов. Вознаграждение за мной, если получится реализовать. |
|
|
|
|
|
Проверил. При экспорте в тиф без сжатия, как и ожидалось, 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
А еще кэширование на уровне ОС. Оно ж сбрасывает линиями, после чего в режиме ДМА пишется на диск, а процессор работает дальше.
|
|
|
|
|
У меня не ССД, но эту проблему тоже можно решить. Точнее, на каких-то машинах у меня ссд а на большей части хдд.
Т.е. я так понимаю этот процесс можно ускорить? |
|
|
|
|
> Т.е. я так понимаю этот процесс можно ускорить?
Ну, с большой вероятностью раза в два можно ускорить за счет распаралеливания подготовки тайлов для склейки. Может и больше, но там уже, скорее всего, новые бутылочные горлышки появятся.
Мои условия читайте на форуме в соответсвующей теме. |
|
|
|
(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), так что ещё присутствует довольно приличный оверхед помимо декодирования.
|
|
|
|
|
>Декодирование 1860 jpeg тайлов, которые участвовали в склейке, заняло около 1,7 сек. (счётчик /Content/TileLoad/LibJPEG/LoadStream), так что ещё присутствует довольно приличный оверхед помимо декодирования.
А у тебя не было, случайно включено наложение гибрида? А то очень уж похоже, что там еще 2 секунды декодирования png должно быть. |
|
|
|
(0018147)
|
|
zed
|
|
29-10-2017 08:37
|
|
|
Нет, слоёв/сеток и прочего не накладывалось. Тестировал на свежесозданной ночнушке в отдельной папке, с родным кэшем (пришлось качнуть эти 2 тыс. тайлов). Тест прогонял несколько раз подряд, так что винда наверняка эти тайлы закэшировала и IO можно пренебречь, как мне кажется. |
|
|
|
|
|
Возможно. Никогда не утверждал, что там все оптимально сделано. В любом случае, раза в 2 можно ускорить склейку простым разбрасыванием на несколько потоков процессора. Думаю даже специальных усилий с разбрасыванием потоков по ядрам предпринимать не нужно, достаточно поставить их количество в два раза больше чем физических ядер в процессоре. |
|
|
|
(0018239)
|
|
zed
|
13-12-2017 19:05
(edited on: 13-12-2017 19:06) |
|
Протестировал новую фичу на своём 2-х ядерном проце - стало быстрее процентов на 40-50. Но у меня HDD медленный - проц нагружается максимум процентов на 70, а диск, на который идёт запись, нагружается на все 100%.
А вот с 8-ми ядерным процессором, да SDD должно быть сильно быстрее.
|
|
|
|
|
> А вот с 8-ми ядерным процессором, да SDD должно быть сильно быстрее.
К сожалению, у меня на 4-х ядрах и SSD ускоряется примерно в той же пропорции.
Я чуть-чуть поизучал, что там еще много времени занимает и вышло, что очень дорогая операция принудительного добавления фона (этого следовало ожидать). И от нее можно в 90% случаев избавиться. Просто для растрового тайла нужно хранить и отслеживать на всем его жизненном цикле наличие прозрачных пикселей.
Так при загрузке jpg можно быть уверенным, что прозрачных пикселей нет, кроме случая, когда картинка меньше тайла. Для некоторых типов png прозрачности не будет. После принудительного добавления фона тоже можно ставить, что непрозрачное. После накладывания прозрачного на непрозрачное, тоже результат известен заранее. При рисовании сеток или карты заполнения, можно быть просто сохранить наличие прозрачных участков. Чуть сложнее с метками, но там можно считать, что прозрачность есть всегда. И тд.
Если все это внимательно отслеживать, то просто не понадобится принудительно добавлять фон для непрозрачных тайлов. |
|
|
|
(0018254)
|
|
zed
|
|
06-03-2018 14:59
|
|
|
Наверное, тикет можно считать отработанным? |
|
|
|
|
|
Да. Что-то я забыл про этот тикет. |
|