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

Question

При добавлении фотографий в каталог Lightroom 6 проходит обычное построение стандартных превью. Поскольку Adobe разработала этот процесс для работы в фоновом режиме, оставляя вам достаточно ресурсов для одновременной работы с вашими фотографиями, здание предварительного просмотра выделяет только 50% процессорного времени (использует все ядра).

Я обычно добавляю фотографии большими партиями и использую это время, чтобы сделать перерыв и сделать чай, пока Lightroom их жует. Естественно, я бы хотел, чтобы предварительный просмотр создавался быстрее, а не имел ресурсы, доступные для других задач во время процесса.

Есть ли способ заставить Lightroom использовать 100% ЦП для стандартного построения предварительного просмотра, так же, как при экспорте изображений RAW, например?

РЕДАКТИРОВАТЬ : чтобы прояснить ситуацию, Lightroom использует 100% ЦП и все ядра / потоки (мой ЦП - 2 ядра / 4 потока) для любых других задач, в том числе для экспорта фотографий, работа с корректирующими кистями в режиме разработки (которые, как правило, требуют значительных правок процессора) и рендеринг предварительного просмотра 1: 1. С системой / оборудованием проблем нет, все отлично работает.

Рассматриваемая проблема касается только создания стандартных предварительных просмотров , и, насколько я знаю, есть дизайн. Вопрос в том, можно ли каким-либо образом преодолеть это ограничение дизайна Lightroom.

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

@ Linwood ' answer довольно хорошо освещает свои измерения производительности и наблюдения за общей многопоточной производительностью 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 со входами, которые вы подаете.

Answer 3

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

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

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

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

---

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