Как заставить Lightroom полностью использовать процессор при создании стандартных превью?

Я много экспериментировал с Lightroom и производительностью, но ничего не знаю о его внутренней работе (и вам понадобятся комментарии Adobe).

ОКАЗЫВАЕТСЯ, что в Lightroom есть участки кода, которые не могут выполняться параллельно. С годами он улучшился, но еще не там. Недавно я построил новую систему для фотосъемки, состоящую из твердотельных накопителей, с отдельными контроллерами (один U.20 для подключения к SATA), с 64 ГБ памяти. Я попытался устранить все узкие места, и он по-прежнему имеет тенденцию запускать предварительные просмотры зданий примерно на 50-75%. При тестировании я вообще не вижу очередей на дисках и, конечно, нехватки памяти.

Я полагаю, что вы получите немного лучшее использование, если запустите несколько заданий в отдельных файлах, но это не полное решение, и запуск 3, 4 и т. Д. Процессов не помогает. Два, кажется, получают все, что можно получить, и это немного. Мое эмпирическое впечатление состоит в том, что определенные действия являются однопоточными (вероятно, критическими разделами), и пользователь ничего не может сделать.

В общем, вы можете сделать многое, например: если ваши диски заняты, отделить кеш предварительного просмотра/ACR от изображений на отдельных дисках (особенно если они вращаются) и/или контроллерах, и, в свою очередь, отдельно от каталога ( символическая ссылка необходима для отделения кеша предварительного просмотра от каталога), имея адекватную и быструю память (я обнаружил, что для отдельных изображений (по сравнению с панорамными слияниями) сложно заставить LR использовать более 8-12 ГБ), выбирая наименьший предварительный просмотр, который вам нужно («авто» работает довольно хорошо), и, наконец, самое важное: использование процессора, который имеет самую высокую скорость одиночного кода, которую вы можете получить.

Если вы используете Intel, который поддерживает Hyperthreading, я считаю, что он работает немного лучше, когда Hyperthreading выключен, а не включен (т. е. без «поддельных» ядер).

Следствием всего этого является то, что получение большего количества более медленных ядер не очень полезно; получение нескольких (скажем, 4) более быстрых ядер помогает гораздо больше. При значительном однопоточном коде (очевидно) в качестве эталона для выбора ЦП для LR одноядерная обработка кажется наиболее важной.

Я думаю, что 4 лучше, чем 2; Я, конечно, иногда вижу как минимум три активных ядра. Я не думаю, что 6 будет лучше, тем более 8 (это может измениться в более поздних версиях, и, как уже упоминалось, это больше касается скорости одного ядра, чем числа).

Я также попробовал более быструю память (тактовая частота 3000 МГц против 2400 МГц) и обнаружил, что это немного помогло (около 10%). Повышение производительности графического процессора ТОЛЬКО помогает разрабатывать слайдеры экрана, это не повлияет (начиная с текущей версии 2015.10) на предварительные сборки. Разгон процессора дает практически линейный прирост скорости. Очевидно, что любой разгон может снизить стабильность.

Что бы это ни стоило, одна часто запрашиваемая функция, которой нет в Lightroom, — это возможность использовать встроенный предварительный просмотр вместо его создания. Для многих, с большими объемами и низким процентом киперов (т. е. большим количеством отбраковки), это слишком медленное создание предварительных просмотров для использования. Мое личное решение для этого состояло в том, чтобы прекратить использовать Lightroom для выбраковки; Я отбраковываю, обрезаю и выпрямляю снаружи с помощью более быстрого инструмента, который использует встроенный предварительный просмотр (в моем случае Photo Mechanic, но их много), и делаю только те снимки, которые с высокой вероятностью будут сохранены в Lightroom.

Я предполагаю, что вы, вероятно , привязаны к памяти или кешу . Ваш i7-3520 имеет общий кеш объемом 4 МБ, что означает, что оба ядра совместно используют кеш L3 объемом 4 МБ. Поскольку ваш ЦП поддерживает гиперпоточность, в той мере, в какой каждый поток SMT действует как «ЦП», ваш кеш L3 распределяется между 4 «ЦП».

Конкретный размер кеша не важен, равно как и 50% использования, которые вы наблюдаете, не особенно показательны. То есть не предполагайте, что, поскольку 50% совпадает с «одной половиной», происходит некоторая неэффективность «деления на 2». Использование также может быть 42% или 61,803% и т. д.

Давайте на мгновение задумаемся о данных, с которыми работает Lightroom, пытаясь создать превью. Это версии реального изображения с низким разрешением, что означает, что для создания меньших превью используется своего рода субдискретизация или интерполяция N: 1. Таким образом, предварительное построение быстро работает с большим набором данных, пропуская или быстро усредняя значения соседних пикселей, а не выполняя попиксельные тяжелые вычисления, которые могут выполняться при редактировании в модуле «Разработка».

Кроме того, мы понятия не имеем, как изображение представлено в памяти Lightroom. Лично я бы предположил, что данные хранятся в виде троек RGB, вероятно, 16 бит на пиксель (или больше) на цвет. (Обратите внимание, что это не имеет никакого отношения к тому, как изображение хранится на диске , или к тому, было ли оно снято в формате RAW или JPEG. Это детали хранения файла.)

Таким образом, предполагая, что изображения представлены в памяти в виде несжатых троек 16-битных данных, каждое «ядро» ЦП с гиперпоточностью может работать не более чем, в идеале, √(1 МБ / (3 цвета/пиксель) / (2 байта/цвет) ) ≈ 418 квадратных областей px. Однако затраты времени на заполнение областей кэша данными изображения из ОЗУ намного больше, чем требуется ЦП для работы с некоторой долей каждой области размером ~ 420 × 420 пикселей.

Ответ @Linwood довольно хорош , поскольку он описывает его измерения производительности и наблюдения за общей многопоточной производительностью Lightroom. Я хотел бы добавить это исследование многоядерной производительности Lightroom CC/6 , проведенное Мэттом Бахом из Puget Systems , производителя компьютеров с нестандартной производительностью. Следует отметить наблюдаемое увеличение производительности на ядро, используемое при создании превью 1:1, примерно до 5 или 6 ядер. После 6 ядер использование каждого ядра становится невозможным.

Также следует отметить в тесте Puget Systems, что задачи Lightroom, которые получают наибольшее увеличение количества ядер (не гиперпотоков):

1. Экспорт изображений на диск
2. Преобразование из RAW в DNG
3. Создание превью 1:1

Другие задачи по редактированию изображений и библиотек не так сильно выигрывают от увеличения количества ядер.

Вернемся к вашей конкретной системе. Если бы мы могли гипотетически изменить определенные параметры вашего компьютера, вот что мы, вероятно, увидели бы:

• Уменьшите тактовую частоту ЦП : при условии, что частота ОЗУ одинакова (1600 МГц), вы увидите увеличение использования, поскольку доля времени загрузки данных в/из ОЗУ по сравнению со временем выполнения инструкций уменьшится. Вы потратите немного больше времени на выполнение, чем на загрузку/хранение в ОЗУ. Конечно, ваша реальная совокупная пропускная способность будет ниже, так что это нежелательно.

• Отключите гиперпоточность : вы, вероятно, увидите немного более высокий процент использования ЦП, но ваша чистая пропускная способность количества предварительных просмотров, созданных в минуту, упадет. Я не знаю, компенсируют ли они прибыль/убыток. Опыт Линвуда подсказывает, что будет по крайней мере небольшая чистая прибыль.

• Удвойте количество физических ядер (без гиперпоточности) : процент ЦП будет аналогичным (при условии, что ядра используют общий кэш L3).

• Удвойте размер кэша L3 : это, вероятно, даст наибольший наблюдаемый прирост как в использовании ЦП, так и в чистой пропускной способности.

Суть, однако, в том, что нет, вы не можете ничего сделать, чтобы увеличить загрузку ЦП в вашей системе во время создания предварительного просмотра Lightroom с входными данными, которые вы ему подаете.

Если ваша система имеет 2 ядра, а Lightroom привязан к 50%-му использованию ЦП, то я могу сделать следующие наблюдения:

1. Lightroom использует 100% одного из ядер. Так что импорт в Lightroom привязан к скорости процессора. Это ограничение вашего оборудования.

2. Lightroom не был написан для использования преимуществ многоядерности. Это ограничение Lightroom.

Таким образом, я думаю, вы столкнулись с комбинированным ограничением Lightroom и вашей системы. И вы не можете изменить работу своей копии Lightroom! ¹ Таким образом, единственный способ улучшить ситуацию — получить систему с более быстрым процессором.

^{1. Хотя другая версия Lr может иметь значение. Но я ничего не знаю о том, какую версию Lr вы используете и как идет процесс разработки Adobe. На самом деле я все равно пытаюсь уйти от Adobe, так что даже знать не хочу!}