PC для фотографии --- (ворочать большие файлы)

Всего 157 сообщ. | Показаны 81 - 100
Re[Годзи]:
фотошоп всегда был очень неплохо заточен под использование нескольких процов
http://www.ixbt.com/cpu/amd-phenom-x4-2600-mhz.shtml - там есть табличка из которой видно что 4-хядерники в CS2 в 1,5 раза быстрее 2-хядерников (что интел, вто АМД) Так что 4-ре ядра ФШ слопает легко. Кажется, и 8 ядер лишними не будут (при условии быстрого диска)...
Re[ДМБ]:
Цитата:
от: ДМБ
Немного смущает, что по всем отзывам FB-DIMM весьма не быстра в реальной работе,


Поскольку все уперлось в итоге в ускорение скратча шопа... мне кажется, что виртуальный HDD (пусть даже в относительно медленной памяти) всяко будет быстрее, чем жесткие диски даже в страйпе. Особенно когда дело касается времени доступа, что как бы критично для скратча фотошопа. Но, в таком случае надо избавиться от скратча шопа на реальных дисках полностью.

Мне в частной переписке все же советуют отдать шопу на растерзание страйп из 10000prm дисков с минимальным сиком... так что вопрос остается открытым.












Re[abc373]:
Цитата:
от: abc373

Мне в частной переписке все же советуют отдать шопу на растерзание страйп из 10000prm дисков с минимальным сиком... так что вопрос остается открытым.


Не, все-таки для свопа i-RAM рулит, даже несмотря на SATA-1.
Re[Юраста]:
Цитата:
от: Юраста
Кажется, и 8 ядер лишними не будут (при условии быстрого диска)...


Будут. Потому что узкое место - доступ к данным, а не их вычислительная обработка.
Re[Игорь Долгов]:
Цитата:
от: Игорь Долгов

А можно по-подробнее?


Если прочесть ветку внимательнее, автор уверяет, что файл подкачки фотошопа у него не вылазит за 10 ГБ, поэтому если мы поставиь 16 ГБ в машину из которых 12 отдадим под RAM Disk то получим больший прирост, чем машина с 4 гигами + RAID.

Далее, если мы говорим о RAID-5, то, как вы верно заметили, данный массив требует большого объема вычислений и может уперется в вычислительную мощность контроллера, чем собственно и плохи большинство встроенных контроллеров.

Я высказывал предположение, что фотошопу сколько памяти не дай всеравно мало будет, поэтому лучше сразу задуматься о RAID, но у автора темы свои наблюдения и он четко сформулировал задачу. Т.е. мы его предупредили, но дело то хозяйское.
Re[Юраста]:
Цитата:
от: Юраста
фотошоп всегда был очень неплохо заточен под использование нескольких процов

ВСЕГДА он не мог быть заточен, так раньше его разработчики даже не задумывались о такой возможности. Да и сейчас, похоже, ситуация никак не поменялась, я периодически просматриваю тесты. Вот тест с большим числом вариантов:
http://www.thg.ru/cpu/intel_core2_e6750_q6600_overclock/intel_core2_e6750_q6600_overclock-12.html# , там есть результаты по PS3.
Re[ДМБ]:
похоже, придется тестировать самому. завтра гляну загрузку процов на мак-про на разных операциях в ФШ...

только что глянул на винде - некоторые фильтры (emboss к примеру) действительно не испульзуют даже 2 ядра. А вот конвертация в CMYK, трансформ, blur, reduce noise - все эти операции грузят все ядра, то есть выигрыш от 4-х ядер все-таки будет
Re[abc373]:
Цитата:
от: abc373
Поскольку все уперлось в итоге в ускорение скратча шопа... мне кажется, что виртуальный HDD (пусть даже в относительно медленной памяти) всяко будет быстрее, чем жесткие диски даже в страйпе.

Мысли вслух:
1. Вполне может быть, что в данный момент у тебя весь скратч влезет на i-RAM, но вот при небольшом увеличении размеров файлов... А если не влезет, то всё насмарку. У меня сейчас скан с 4х5 и 8 битами на цвет получился ровно 3.5Gb - это только для будущей станции. Даже использование самых маленьких Savvio 15K.1 внушает уверенность в завтрашнем дне.
2. При работе с сохранением промежуточных результатов, различных вариантов и просмотров их, большое значение имеет пропускная способность канала связи с памятью. Измеренная производительность записи/чтения i-RAM не достигает 130 Мбайт/с, это не очень здорово по сравнению с хорошим RAID 0.

Сейчас как раз готовимся к сборке станции для приятеля для обработки и вывода на принтер больших файлов от 1-2Gb. Надеюсь, свои самые большие файлы буду на ней и обрабатывать. Первоначально решили собрать промежуточный вариант с относительно недорогими дисками, а потом эти диски использовать в других машинах или в базе данных, а вместо них поставить твердотельные диски. Но в последние дни начинаю склоняться к изготовлению сразу полноценной машины на нормальных дисках, по деньгам будет дешевле и работать по-полной можно будет сразу. Сейчас осталось уточнить размер действительно необходимой ОП, но никак не могу узнать, какой максимальный размер файла способен обрабатывать следующий ФШ. Народ уже пользуется бета-версией, но конкретики маловато. Может кто знает?
Re[Юраста]:
Цитата:
от: Юраста
эти операции грузят все ядра, то есть выигрыш от 4-х ядер все-таки будет

Более, чем косвенный признак. Можно загрузить все ядра и процессоры по полной какой-то вспомогательной и могущей быть полезной работой, а суммарная производительность может уступать одному быстрому одноядерному процессору. Пока Адобовские разработчики не придумают эффективных алгоритмов распараллеливания вычислений по обработке 2D изображений и не внедрят их в готовый продукт (что весьма существенно), то ожидать чуда от большой кучи процессоров не следует.
Re[ДМБ]:
Простите, а как вы жили раньше? Не обрабатывали? БФ ведь у вас давно.
Re[ДМБ]:
Цитата:
от: ДМБ
Народ уже пользуется бета-версией, но конкретики маловато. Может кто знает?


Бета CS4? 64 разряда?

Если рассуждать спекулятивно, исходя из 64-битной адресации - то размер файла вылезает за любые разумные границы.
:D
Re[Годзи]:
А как связана адресация и размер файла? Полагаю, будет возможность работы с разной глубиной цвета: 8, 16 и 24 бита. Или мои надежды беспочвенны? Кстати, свежие новости:

64-битная версия Adobe CS4 будет доступна только для Windows

Это объясняется тем, что в прошлом году Apple заявила о своем решении прекратить разработку 64-битной версии Carbon. Несмотря на то, что CS3 совместима с компьютерами Mac, работающими на базе процессоров Intel, ядро программы основано именно на Carbon. Именно поэтому разработчикам Adobe необходимо переписать огромные фрагменты кода (более миллиона строк), используя Cocoa, чтобы Photoshop успешно работал на 64-битных Маках.

Согласно данным Adobe, при работе с 64-битными версиями Photoshop будет наблюдаться прирост производительности от 8 до 12%, однако пользователи, работающие с изображениями большого размера и использующие мощные компьютеры с большим количеством оперативной памяти, получат значительно большие преимущества.
Re[ДМБ]:
Цитата:
от: ДМБ
А как связана адресация и размер файла?


Самым непосредственным образом :) Смещение в файле задается числом. Максимальное число, которое можно записать 32 разрядами, дает 4 гига смещения (то же и с памятью). Если адрес 64 разряда, то максимальное смещение (и адрес памяти ) 1.84467441 × 10^19. Это очень дофга. :) Не представляю себе такую картинку.
Re[ДМБ]:
Цитата:
от: ДМБ
Мысли вслух:
1. Вполне может быть, что в данный момент у тебя весь скратч влезет на i-RAM, но вот при небольшом увеличении размеров файлов...

2 i-RAM, и уже 8Гб.
Re[ДМБ]:
Цитата:
от: ДМБ
А как связана адресация и размер файла?


С размером файла никак не связана, просто речь о том, что не надо будет извращаться с созданием рам-дисков в памяти под своп, сам фотошоп сможет использовать столько, сколько ему дадут.
Re[ДМБ]:
dkjfhjfdsk.
Re[Годзи]:
Это я к утру засыпая понял Вашу фразу самым невероятным образом, что из-за "нового стандарта на качественный цвет" размеры обрабатываемых файлов здорово распухнут. Сейчас сильно удивляюсь, как такое могло прийти в голову. Организацию памяти и адресацию в ней представляю себе неплохо, когда-то писал операционки реального времени на мнемокоде.
Re[bc----]:
Цитата:
от: bc----
2 i-RAM, и уже 8Гб.

С одной строны да, но и неудобств там хватает. Вымирающие PCI слоты, DDR память, SATA 1, немалый объём и потребляемая мощность. i-RAM BOX, да ещё и в количестве двух штук, будут подороже и вряд ли в итоге лучше покупки матери под 32Gb. Недавно видел сообщение человека, протестировавшего в реальной работе несколько вариантов и выбравшего себе в итоге RAID 0 всего с двумя дисками вместо i-RAM. Видимо, при работе именно с большими файлами, время доступа становится не столь важным, как пропускная способность канала связи.
Re[ДМБ]:
Цитата:

от:ДМБ
Это я к утру засыпая понял Вашу фразу самым невероятным образом, что из-за "нового стандарта на качественный цвет" размеры обрабатываемых файлов здорово распухнут. Сейчас сильно удивляюсь, как такое могло прийти в голову. Организацию памяти и адресацию в ней представляю себе неплохо, когда-то писал операционки реального времени на мнемокоде.

Подробнее



Меня, признаться, удивил такой вопрос с Вашей стороны. :D
Re[abc373]:
Цитата:
от: abc373
Мне в частной переписке все же советуют отдать шопу на растерзание страйп из 10000prm дисков с минимальным сиком... так что вопрос остается открытым.

Небольшое вступление -

наибольший файл с которым я работал - 30GB, собственноручная панорама в 1.6 гигапикселя, 60,000+ пикс по длинной.

О моем текущем компе -

куплен в 2005-м, 8GB, Dell Precision 380, больше чем 4x2GB DDR2 не жует. WinXP 64-bit.

Как диск для scratch использую обычно один iRAM в 4GB, когда мало - пробрасываю шнурки до лежащей рядом машинки с еще двумя i-RAM, рэйд на мамочке из 3-х iRAM вполне выдает 370-380 MB/sec, хотя на компе от 2004-го на виртуальном диске я видел за 500MB/sec без всяких рейдов ;) когда что-то не лезет в рэйд из i-RAM на подхвате есть Raptor.

Далее, не знаю как для двух мониторов, а мой нынешний план на прекрасное будущее - Dell Precision T7400, там у него не 4 и не 8 а до 16 планок, легко набивать 2GB планками до 16*2=32GB, много дешевле набивать 2GB планками чем 4GB, и, как грозятся, 8GB планками.

Я не знаю изменит ли 64-битность фотошопа его поведение, в конце концов фотошоп при открывании даже маленького файла скажем в 20MB гадит в scratch-disk не потому что в компе мало памяти (8GB), а потому что он так написан был во времена ветхозаветные.
Вы не авторизованы

Пожалуйста, авторизуйтесь, чтоб иметь доступ к полному функционалу сайта

Обратная связь

Здесь вы можете оставить свои контактные данные, чтобы мы могли связаться с вами.