Вопросы по Lightroom (LR, Лайтрум)

"реально авторитетного" - нет. "достаточно авторитетное" - встречается.

 

Все равно разумному скепсису подвергать и проверять хотябы один вывод самому. Придумать как померить "пип...ку" всегда можно, вопрос в том отражает ли полученая цифирь реально необходимый эффект.

---------- Сообщение добавлено 02.01.2011 21:44 ----------

Скорости явно не будет.

 

В данном конкретном тесте (производительность в cs5) отражает, т.к. другие тесты в CS5 (например на fcenter) показывают аналогичные результаты - i7 лидирует, более бюджетные 4х ядерники отстают, двухядерники внизу хитпарада.

 

Провёл я сегодня довольно долгий ряд экспериментов. Всё пытался понять, за счёт чего можно на конкретном компе скорость работы лайтрума увеличить.

Система такая: пенёк E5300 (Wolfdale, частота 2.6, кеш 32/2048), чипсет P45, память PC2-6400, объём 4 гига.

На 32-битной винде скорость перерисовки в режиме Develop (загрузка проца падает, прекращается дисковая активность, исчезает надпись Loading) - 3 секунды. Причём даже в том случае, если ВСЕ ФАЙЛЫ, ВКЛЮЧАЯ СНИМКИ, НАХОДЯТСЯ НА RAM-ДИСКЕ!!!!!!!!!!!!!!!!!!!! Короче, время вообще не зависит от того, находятся ли файлы, каталог и кеш на одном физическом диске, на разных или даже все они находятся в памяти. Это, конечно, жесть, товарищи. Причём наижестянейшая. Понятно ведь, что скорость рамдиска по определению выше скорости любого HDD или SSD винчестера. При этом крутится в руме каких-то жалких 25 равов, т.е. они вообще все могли бы в кеше оперативной памяти уместиться.

3 секунды - время полного прекращения активности, но крутить движки можно начинать практически сразу.

В 64-битной макоси надпись Loading исчезает мгновенно, если перемещаться по кругу, допустим, между пятью выделенными файлами. Соответственно, может создаться ошибочное впечатление, что макось работает быстрее винды. В то же время, при "длинном" листании (10 и более файлов) время загрузки ровно то же самое - 3 секунды. Несколько выше виндузной отзывчивость интерфейса, но не сказать, что прям вот принципиально.

Выводы, по всей видимости, надо делать следующие:

1) скорость работы зависит в наибольшей степени от ОС и процессора
2) лайтруму, по большому счёту, пофиг на винты
3) макось перелистывает как бы шустрее, но в целом ускорение непринципиальное, потому что на самом деле просто характер динамики интерфейса другой.
4) видно, что то ли в макоси диспетчер памяти и дисковый кэш значительно оптимальнее виндузных, то ли просто лайтрум скомпилирован по-другому: в винде-то даже между соседними файлами перелистывается по 3 секунды, и время это никогда не уменьшается

Ну а главный вывод, думается, следующий: винты и память апгрейдить бесполезно. Апгрейд проца тоже, видимо, существенной погоды не сделает. По крайней мере, у знакомого пень 8400, и время перелистывания сравнимое. Так шо поможет только апгрейд всей системы в целом.

---------- Сообщение добавлено 04.01.2011 22:51 ----------

P.S. Да, разумеется, я генерировал превьюшки размера 1:1

Неплохо бы спросить разработчиков, нахрена вообще эти превьюшки нужны, если с ними и без них скорость, считай, одинаковая. Если б эти превьюшки использовались как положено, то не было бы этой тупой 100%-ной 3-секундной загрузки проца при перелистывании. В Capture One, к слову, превью кеш работает очень даже замечательно и на каждый чох заново не пересчитывается.

 

я думаю тут принципиальна не скорость чтения с диска, а алгоритм декомпрессирования равки.

1. память -да
2. дисковый кеш - ты имел ввиду часть OS которая работает с дисками? это весьма спорный вопрос. Но вполне возможно.
3 по-любому по-другому ))) хотя-бы размер сравни ))

Я думаю принесет пользу повышение частоты шины (как системной так и внутренней процессора).Либо написание более прямых алгоритмов компрессии/декомпрессии равок.

 

Вот и выясняется причина тупняков при перелистывании: http://forums.adobe.com/message/3314850#3314850

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

Вот ёшкин же кот, ну почему бы не скидывать в кэш полностью просчитанную версию картинки, а? За каким же, звиняюсь, мужским органом каждый раз картинку заново-то пересчитывать?

Вообще, исходя из потрясающей скорости перелистывания, я ожидал от них какой-то подобной невыносимой тупости. Надобно заметить, что ребятишки на 100% оправдали мои ожидания. Даёшь индусский код!!!

---------- Сообщение добавлено 05.01.2011 00:06 ----------

Я-то думал, что у меня хакинтош тупит! Видюха неправильно заведена или что-то в этом духе! А у чувака на фирменном макпро ровно та же пэстня!!!
http://forums.adobe.com/message/3315065#3315065

 

У меня в ACR при перескоке превьюха тоже за 2-3 сек обновляется, но проц грузится примерно на 50-60% - 4 ядра пожилого Q6600 адобовский движок генерируя превьюшку похоже, загрузить не может, только 2.
Зато 6мегапиксельные равчики от старичка D70 обновляются очень шустро.

Я тут сделал собственный тест - загрузил 100 равчиков сбросил все настройки в дефолт и сделал экспорт в jpeg.
Экспорт 100 равчиков от D70 занял 122 сек. Экспорт 100 равчиков от D700 занял 255 секунд. Т.е. чем больше мегапикселей тем медленнее, у меня получилась линейная зависимость.
Кстати при экспорте все 4 ядра грузятся под завязку, это приятно.

Это если памяти достаточно. А если памяти недостаточно и система интенсивно свопится, то апгрейд памяти даст весьма чуствительный результат.

---------- Сообщение добавлено 05.01.2011 00:18 ----------

Дикари-с. Небось индусы кодят.

 

У меня - я сейчас посмотрел - загрузка за эти 3 секунды в пике 100%-ная, но недолго, так что в среднем тоже где-то процентов 40-60

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

---------- Сообщение добавлено 05.01.2011 02:05 ----------

Вот ещё интересная статейка, почему быстрые винты и, в особенности, SSD-шники - не очень хороший способ ускорения лайтрума. Думается мне, это сильно похоже на правду. По крайней мере, выводы статьи примерно соответствуют тем умозаключениям, что сделал я на основе своих экспериментов.

http://forums.adobe.com/message/3000688#3000688

Так что единственный более-менее хороший способ ускорения лайтрума, как бы это ни было грустно - апгрейд проца, чипсета и памяти. Всё это из-за жуткой индийской кривизны лайтрумовских внутренностей. Действительно, на одну простую операцию лайтрум делает тыщи миллиардов записей в различные базы данных. Там, соответственно, включаются транзакции, блокировки и т.д. и т.п. Плюс к тому, непродуманно частые обсчёты и бесчисленные перерисовки. Плюс к тому замечательный мелкомягкий .NET с его волшебными объектно-ориентированными библиотеками, диспетчерами памяти и неторопливым интерфейсом. Плюс к тому общая современная тенденция к упрощению текстов программ за счёт высокоуровневых структур, классов вместо процедур и слабой оптимизации.

Короче, дисковая подсистема, судя по всему, последнее, что влияет на скорость работы лайтрума. Так что вместо покупки рейдов и SSD-шников лучше систему поапгрейдить. Деньги те же, а самообману меньше и толку больше. Причём двигаться не в сторону увеличения числа ядер и мегагерцев, а в сторону новых техпроцессов, быстрых шин и объёмистых кешей.

Ну и на макось переходить, само собой Она поотзывчивее винды всё-таки.

 

[
В наше время это одно и тоже.
Кстати, вот-вот новые процы попрут от интеля, как раз на "новых техпроцессах"
http://www.fcenter.ru/online.shtml?articles/hardware/processors/30089

 

ну у рейдов есть один большой плюс - отказоустойчивость. так что вот не надо про рейды.

---------- Сообщение добавлено 05.01.2011 02:52 ----------

угумс

 

И в чем тогда смысл? ХРень х64 - страшное извращение.

Это очевидная необходимость. И я не про лайтрум. Все-таки фотошоп тоже, наверняка, на этом компе стоит, а не на отдельном.

Да всё там нормально. Кстати, а тебе так уж нужны эти обновления?

 

очень быстро и поверхностно посмотрел систему с i7 на SSD. Не понял от чего Флавиус кончает )
разницу заметил в том, что на ссд фотошоп с момента нажатия на иконку до появления лого окна с загрузкой проходит минимум времени, причем сама подгрузка библиотек происходит так же долго как и на core2quad на hdd с 6 гигами памяти. аналогично и с ЛР

это все лишь собственное ощущение ни на что не претендующее

 

Anton-34,
У меня ФШ загружается примерно две секунды. Причем вместе с фотографией. Это если сразу .psd файлу щелкнуть, или или загрузка из бриджа. А уж как система, игры начали загружаться...
Проц i5-750, 4Гб (3.5 видно). HDD - OCZ 12Гб. Пока я не вижу смысла в наращивании памяти и использование 64-х битной оси. Я редко когда больше 5-8 файлов одновременно открываю, для моих нужд памяти хватает.

Сергей А. Максимов,
Корпоративная версия, с активацией через kms сервер. Обновляется без проблем. Офис кстати тоже.
Ставить ХР на современное железо особого смысла нет - оси уже 10 лет.
У АМД вроде есть и шестиядерник.

 

А по мне - гораздо отказоустойчивее тот же самый винт из рейда вынуть, воткнуть снаружи компа и бэкапы на него сливать. Или на соседний комп (лично я оба этих метода применяю). По-любому хреновенький бэкап надёжнее самых мега-супер-надёжных райдов.

На 4 гигах у 64 бит нет практически никаких реальных преимуществ перед 32 битами. И уж, тем более, у висты-семёрки нет в этом случае преимуществ перед хрюшей. Если только не считать преимуществом новый интерфейс. Я к этому выводу пришёл, честно два месяца потратив на поюзание 64-битной семёрки и стараясь быть объективным в оценке производительности.

Вот макось - да, она вообще по-другому работает. На неё, может, и имеет смысл переходить.

Самое интересное - скорость перелистывания и прорисовки, а тут мои опыты с рамдиском обязывают делать выводы, что причина тормозов совершенно не в винтах кроется. В конце концов, какая разница, стартует лайтрум 3 секунды или 30?

Кстати, в лайтруме 3.3, вроде бы, поправили тормоза с кистями. Если так, то вся статья для обработки на макось переходить. И переучиваться нажимать Win вместо Ctrl

Т.е. ты полагаешь, что новые программы на новом железе работают быстрее старых?

 

- )) я же сказал - спорный вопрос - но не буду спорить.. Как всегда все зависит от целей. Если нужно обеспечить постоянный доступ к данным - то от рейда не уйдешь. Если просто "на память" - то да - отдельный винт на полку.

К сожалению не знаю в деталях сегодняшнего положения, но раньше было так и не думаю, что что-то изменилось. AMD-шный конвейер в проце был умнее и короче, поэтому математику они обсчитывали лучше Пеньков. С другой стороны при необходимости делать много (!!) простых действий, типа лопатить сетевые пакетики, юзались Pentium из-за более быстрой шины и высокой частоты. Поэтому платформа выбиралась исходя из приложений, которые будут использоваться и исходя из того для каких процессоров оптимизированы эти приложения.

Эх... если бы так было (((((

---------- Сообщение добавлено 05.01.2011 16:14 ----------

Поверь - 99% тестов - лажа. IMHO

 

В целом чаще так оно и есть. На адекватном железе есс-но.
Тот же ФШ: версия cs5 под Win7 работает ощутимо шустрее версии cs3 под WinXP.
Практически все свежие игры под Win7 работают быстрее и качественней чем на XP.
Тот же directX 10 и 11 под ХР не реализован.

Win7 и свежий софт более эффеткивно используют современное железо, стабильнее, работает обновление и поддержка.

Вы постоянно от батарей работаете? Срок автономной работы больше зависит от выполняемых на компе задач и настройках энергопотребления. Можно текст в ворде печатать, а в инете сидеть по вай-фаю или в StarCraft2 гонять. Яркость экрана может быть 30%, а может все 100%.

Я так понимаю тут собственно фотораздел. А ноутбук и обработка фотографий, как и работа с графикой - вообще вещи несовместимые.

Ерунда эти тесты. Если так любите тесты - ориентируйтесь на игровые - они более менее адекватны.
Меня всегда удивляли "тестеры", ставящие современную ось на железо пяти-шести летней давности или на всякие нетбуки, а потом расписывающие, как семерка тормозит.
Есс-но на Атоме или на откровенно старых машинах с 1-2 Гб ОЗУ Win7 будет не очень. Но дайте семерке к2д а лучше Ай 3/5/7 , 4Гб. и все будет замечаптельно.

 

В этих "адекватных" тестах обычно все в видюху упирается и пишутся игры в расчете на "среднестатистическое" железо, что бы не потерять рынок. Даже сегодня мало какая игрушка может 4 ядра нормально загрузить, вто время как прикладных программ использующих многоядерность навалом. Чем мне может помочь игровой тест, если в реальной жизни приходится решать совсем другие задачи?

 

IvUs,
Но в игровых тестах другое железо, помимо видюшки вполне адекватно. Никто не станет тестить на каком нибудь E5200 или его аналоге от АМД. Там будет 2-4-х ядерник i5/i7.

А некоторые "гуру" умияют.
На днях читал железячные обзоры одного вроде как авторитетного блоггера.
В одном обзоре товарищ купил мышку Разер Мамба, и пишет, что мышь дрянь, т.к. по столу плохо катается. Тапа Логитеч за 500р. лучше. НА коврик наверное денег жалко стало.
В другом взял нетбук ASUS Lamborghini VX6 на Атоме D525. Ему не понравилось, что стоит дорого, а работает медленно, Корел и игры притормаживают. И экран маленький. А сравнивал он его с Леново на i5, весом под три килограмма.

 

Скорость - понятие растяжимое. Быстрее запускается? Быстрее скроллирует? Быстрее файлы грузит? Быстрее обработку производит?

Что именно шустрее происходит-то? И потом, "шустрее" объективно или субъективно?

Пример: до вчерашнего дня я был свято уверен, что макосный лайтрум быстрее виндового файлы перелистывает

И неплохо бы ещё учесть известную проблему, что все новые проги не любят освобождать память, раздуваются и тормозят. Сколько файлов без перезапуска этот новый ЦС5 способен быстро обработать?

В CS/CS3 я могу сотни файлов в течение целого дня без перезапуска обрабатывать, а вот CS4/5 чуть поработаешь - тормоза включаются, перезапускать приходится. Лайтрум тоже перезапуски любит, хотя и в меньшей степени.

Так что не всё так уж гладко в мире нового софта.

 

Иногда даже возникает ощущение, что программеры специально коды раздувают, что бы юзвери новое, всё более и более быстрое железо покупали.. ;о)

 

К счастью, специально программы никто не подтормаживает Проблема в ООП и всяческого рода высокоуровневых абстракциях. Сначала проги пишутся "чтоб работали", а потом до оптимизации ни у кого так руки и не доходят. Примерчик: екзешник "хелло ворлд", написанный на чистом си, весит несколько килобайт и стартует мгновенно. Та же программа с использованием RAD-ов весит уже мегабайты, стартует за секунды и отображает картинку неспешно. Зато в первом случае текст проги состоит из десятков строк и для написания требует высокой квалификации и знания внутренностей ОС, во втором он лепится в визуальном конструкторе и руками писать ни строчечки не приходится. Можно вообще программирования не знать. Любая кухарка может прогу написать. Кухарки, собственно, нынче их и пишут.

Про обработку строк, сообщений и работу с базами данных я ваще молчу. Кто бы это оптимизировал. Там глубины вложенностей процедур и длины циклов - мама не горюй. Зато пишется быстро. Сейчас же главное - новые фишки и скорость выдачи новых версий. Вот и дают нам новые фишки вместе с двух-трёх и так далее кратными тормозами.

---------- Сообщение добавлено 05.01.2011 18:02 ----------

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

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

 

Мелкомягкие сами признали, что в менеджере управления питанием в семерке есть серьезные ошибки. Часть они устранили еще осенью, а остальные должны были устранить до нового года. Устранили или нет не знаю, пока не обновлялся.

 

Да нет, просто тупо быстро кодируют. А быстро кодировать быстрый код могут только мастера, а мастеров мало. Зато много индусов

---------- Сообщение добавлено 05.01.2011 21:17 ----------

СОM весит байты Сейчас не надо хорошо продуманных программ, нужно быстро выводить новый продукт на рынок. К оптимизации дело дойдет только когда будет конкретно тормозить Ну или дождутся более производительного железа.
Хотя есть редкие исключения когда в комерческом продукте исмользуют asm для написания оптимизированного кода под конкретные семейства процов. Но это большая я редкость.

 

Нет такого железа, на котором не смог бы тормозить индусский код

 

Ага, есть такое.

---------- Сообщение добавлено 15.01.2011 22:13 ----------

Сегодня сапгрейдился c Q6600 на i7 2600K и решил посмотреть, а что, собсно я приобрел в результате ограбления семейного бюджета.
Так вот, вместо 122сек и 255 сек стало 41 сек и 76 сек - даже не ожидал, фактически в 3 раза быстрее стало. Правда i7 самую малость разогнан - проcто тупо включил какую-то пипку в bios типа optimal performance.

 

IvUs, винты и операционка те же самые остались? И второй вопрос: ты, так понимаю, про время рендеринга пишешь. А как насчёт времени перерисовки при перелистывании?