8 Гб ОЗУ и Фотошоп

Статус
Закрыто для дальнейших ответов.
Ответ: 8 Гб ОЗУ и Фотошоп

Шарфюрер
есть средства проще
Не самое лучшее решение. Если уж улучшать дисковую, то лучше смотреть в сторону RAID-а на SSD. Правда получится дико дорого, но быстро и неплохо по объему.

ch_alex

Не по теме:
Это 100%. Хотя небольшие эксперименты с X4 показали, что PDF-ы с извратами X4 пишет вполне неплохо. Буду, наверное, внедрять в техпроцесс.
 
Ответ: 8 Гб ОЗУ и Фотошоп

TRANTOR сказал(а):
Шарфюрер
Не самое лучшее решение. Если уж улучшать дисковую, то лучше смотреть в сторону RAID-а на SSD. Правда получится дико дорого, но быстро и неплохо по объему.

неправда ваша, ссд будет хуже чем айрам,
http://www.fcenter.ru/online.shtml?articles/hardware/hdd/23761

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

Ну и, наконец, сверхбыстрые диски с интерфейсом SAS и скоростью вращения 15000 об./мин, фактически, элита жестких дисков, уступают SSD-накопителям на нагрузках с преобладанием запросов на чтение данных со случайным адресом. На потоковых же операциях и на записи в данном сравнении твердотельные накопители выглядят очень слабо и не могут пока соревноваться с "пятнадцатитысячниками".

А где же, в результате, будет рационально использовать твердотельные накопители? В первую очередь, это, конечно же, промышленные компьютеры и ударопрочные ноутбуки, то есть те применения, где особенно будут востребована высочайшая устойчивость флэш-памяти к вибрационным воздействиям, в отличие от жестких дисков. По большому счету, в данном секторе у них нет серьезных соперников, а возросшие скорость и объем обеспечивают возможность выполнения этими компьютерами максимально широкого круга задач.
 
Ответ: 8 Гб ОЗУ и Фотошоп

У айрама плохое ограничение в сата-1, 150 всего. Очень плохо, что дорогая старая ддр-1.

Было бы в виде сата-2 хотя бы и на ддр2 до 16-32 гиг -- было бы вообще хорошо. Или на выбор в виде pci-e карты -- видал такие, но цены у них безобразные.
 
Ответ: 8 Гб ОЗУ и Фотошоп

SINL сказал(а):
У айрама плохое ограничение в сата-1, 150 всего. Очень плохо, что дорогая старая ддр-1.

Было бы в виде сата-2 хотя бы и на ддр2 до 16-32 гиг -- было бы вообще хорошо. Или на выбор в виде pci-e карты -- видал такие, но цены у них безобразные.
есть еще айрам в виде коробки с еСАТА
 
Ответ: 8 Гб ОЗУ и Фотошоп

Шарфюрер
ссд будет хуже чем айрам,
Да не. Они уже вполне подтягиваются. А если штук 8 в рейд заколбасить, то вообще... А если 16, то совсем вообще. :) Цена будет катастрофической, но зато ураган.

К тому же, у иРама объем просто смешной. Скратч быстро кончится, если что-то большое крутить.
 
Ответ: 8 Гб ОЗУ и Фотошоп

Шарфюрер
Интереснее, но маленький он по объему.
 
Ответ: 8 Гб ОЗУ и Фотошоп

TRANTOR сказал(а):
Шарфюрер
Интереснее, но маленький он по объему.
Я же говорю. есть коробка. туда больше влезет.
 
Ответ: 8 Гб ОЗУ и Фотошоп

TRANTOR сказал(а):
В качестве иллюстрации, что, дескать, "ведь могут, когда захотят", скриншот Корела X4. Ожидаем то же самое и для ФШ.

Неужели так сложно скомпилировать "старые исходники" под 64 бита? Где-то прочитал, что программистам из Adobe придётся переписывать миллион строк, но из-за чего, там язык уже другой?
Пробовал качать несколько разных релизов бета CS4, но все упорно 32-битные.
 
Ответ: 8 Гб ОЗУ и Фотошоп

Madguy сказал(а):
Неужели так сложно скомпилировать "старые исходники" под 64 бита? Где-то прочитал, что программистам из Adobe придётся переписывать миллион строк, но из-за чего, там язык уже другой?
Пробовал качать несколько разных релизов бета CS4, но все упорно 32-битные.

Язык-то тот же, но проблемы будут обязательно. Например, сейчас в структуре FilterRecord (передаётся аргументом в Filter plug-in) под указатели void * inData и void * outData отдано 32bit, а в 64bit environment все указатели 64bit'ные. Если просто механически заменить 32bit указатели на 64bit, то появятся новые проблемы - съедет выравнивание внутри структуры. А что-то мне подсказывает, что эта структура вполне может генерироваться автоматически генерируемым кодом, написанным на другом языке (скорее всего, скриптовым, транслируемым в run-time), который ссылается на поля структуры по смещениям. Значит, придётся править все константы, используемые во все скриптах. И это только пара переменных.

А их там в каждой структуре (Adobe Photoshop SDK использует для связи между модулями бинарный plug-in specific формат передачи информации) чуть не сотни.

А ещё есть проблемы, связанные с не всегда качественным кодом. Например, нанятый на временную "арбайтен по Стахановски" работу индус/китаец/русский/да кто угодно мог на честном глазу наколотить код, в котором short int используется вместо int16, unsigned short вместо uint16 и т.д. Опять же, в некоторых численных алгоритмах используются некоторые особенности машинной арифметики. Например то, что 32768=-1 в 16bit арифметике. Или то, что 32 сдвига всегда ноль. А 32 циклических сдвига не меняют переменную. В 64bit environment многие допущения могут посыпаться.

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


Не по теме:
Практика больших проектов показывает, что в таких ситуациях иногда проще физически закрыть разработчикам доступ к имеющейся кодовой базе и написать всё "с нуля". Именно так, например, был написан Microsoft Office 97.


Шутка в том, что на "чистом" языке программирования полезную программу написать очень сложно, если возможно вообще. Ибо "чистые" языки слишком для того чисты. Программы пишутся на конкретной реализации языка программирования. И не всегда у авторов хватает квалификации/времени/денег/других ресурсов на достаточно полную изоляцию "платформо-зависимого" кода от бизнес-логики. А, судя по Adobe Photoshop SDK, в коде Adobe Photoshop платформенно-зависимые вещи от бизнес-логики или не изолированы вообще, или изолированы очень слабо. Ибо проект это, во-первых, большой, во-вторых, очень-очень старый.
 
Ответ: 8 Гб ОЗУ и Фотошоп

pell, спасибо! Внёс ясность 'ok)'
 
Ответ: 8 Гб ОЗУ и Фотошоп

Шарфюрер сказал(а):
Я же говорю. есть коробка. туда больше влезет.

Кстати. приятная новость. сей девайс (I-RAM)? в виде слотовой версии с 4гб DDR, попал мне в руки. так что есть возможность его обстоятельно протестировать (что в данный момент и делаеться), задача была поставленна на тестирование в реальных приложениях.
В течении 2-3-х недель думаю будет обзор за моим или не за моим авторством, с результатами. ;)
 
Ответ: 8 Гб ОЗУ и Фотошоп

Мне почему-то кажется что такие девайсы доживают последние деньки. Можно сколько угодно пинать Висту но x64 системы через год-другой завоюют рынок. В т.ч. полиграфический. И надобность в I-RAM просто отпадет.
 
Ответ: 8 Гб ОЗУ и Фотошоп

lunatik сказал(а):
Мне почему-то кажется что такие девайсы доживают последние деньки. Можно сколько угодно пинать Висту но x64 системы через год-другой завоюют рынок. В т.ч. полиграфический. И надобность в I-RAM просто отпадет.
А причем тут х64, и айрам?
Поясните плиз, я немного не понимаю вашего хода мыслей...
И если на то пошло, то х64 есть и ХР, так что...
ДА и 2003 сервер на рабочей машине не плохо смотриться. И проблема тут не в ХР или виста, а в адобе, которая все никак не может сделать фотошоп под Х64, ибо 32-х разрядному софту на х64 системе пофиг сколько памяти. больше 3гб он все равно не заюзает.
 
Ответ: 8 Гб ОЗУ и Фотошоп

Шарфюрер
так что есть возможность его обстоятельно протестировать (что в данный момент и делаеться)
Это интересно.

Дык, я так понимаю, что больше 4 гигов туда вставить нельзя? Или я неправильно понимаю?
 
Ответ: 8 Гб ОЗУ и Фотошоп

TRANTOR сказал(а):
Шарфюрер
Это интересно.

Дык, я так понимаю, что больше 4 гигов туда вставить нельзя? Или я неправильно понимаю?
Да, понимаете вы совершенно правильно, и при большом размере исходника скратч на него может не уместиться. НО!
Вы сами понимаете. что покупаться это будет для серьезных Workstation, а на материнке примерно как эта, можно будет уместить таких штуки 3, и сказать фолтошопу что бы все 3 устройства под скратч использовал.
Пока я толкьо его успел в бытовых режимах попробовать, установка винды. и её запуск. Ну так симпатишненько, винда за 15 мнут стваиться, грузиться вместо 30-40 секунд 15-17.
Остальное на выходных :)
 
Ответ: 8 Гб ОЗУ и Фотошоп

Шарфюрер сказал(а):
Вы сами понимаете. что покупаться это будет для серьезных Workstation, а на материнке примерно как эта, можно будет уместить таких штуки 3, и сказать фолтошопу что бы все 3 устройства под скратч использовал.

Пардон. что я говорю, зачем весь этот изврат. Вот же, питание уже от молекса, заставил айрамами отсеки 5,25 радуйся жизни :)
 
Ответ: 8 Гб ОЗУ и Фотошоп


Не по теме:
Шарфюрер сказал(а):
а в адобе, которая все никак не может сделать фотошоп под Х64
Я неточно выразился. Конечно проблема в софте. Но фотошоп делают. Корел Х4 уже сделали. За 1-2 года выйдут х64 версии практически всех прог. И зачем тогда нужен I-RAM? Чтобы напихать в мамку памяти больше чем позволяет ее конструкция?

 
Ответ: 8 Гб ОЗУ и Фотошоп

lunatik сказал(а):

Не по теме:

Я неточно выразился. Конечно проблема в софте. Но фотошоп делают. Корел Х4 уже сделали. За 1-2 года выйдут х64 версии практически всех прог. И зачем тогда нужен I-RAM? Чтобы напихать в мамку памяти больше чем позволяет ее конструкция?



Не по теме:
Да хоть 128bit. Потребность в быстром файловом кэше всё равно остаётся и останется, полагаю, на очень на долго.

Вот, например, у меня один десктоп и два ноутбука. На десктопе медленный процессор и всего 512MB RAM, на "мощном" ноутбуке очень быстрый процессор и 2GB RAM. Проект собирается на десктопе почти в полтора раза быстрее. Почему? Потому что современные компиляторы/компоновщики уже давно ограничены по скорости не CPU/RAM, а файловой системой. На десктопе у меня дисковая подсистема гораздо производительней. А если всю систему сборки (исходные коды, заголовочные файлы, библиотеки, компилятор и компоновщик) на что-нибудь вроде i-RAM запихать, вот тогда начнётся совсем другая жизнь!

Теперь к вопросу "А почему бы не сделать RAM-диск для быстрого файлового кеша?" Ответ настолько прост, что понять его не очень просто: "Не надо путать тёплое с мягким. Из двухметровой доски сделать две метровых просто, а наоборот?"

 
Ответ: 8 Гб ОЗУ и Фотошоп

pell сказал(а):

Не по теме:
Да хоть 128bit. Потребность в быстром файловом кэше всё равно остаётся и останется, полагаю, на очень на долго.

Вот, например, у меня один десктоп и два ноутбука. На десктопе медленный процессор и всего 512MB RAM, на "мощном" ноутбуке очень быстрый процессор и 2GB RAM. Проект собирается на десктопе почти в полтора раза быстрее. Почему? Потому что современные компиляторы/компоновщики уже давно ограничены по скорости не CPU/RAM, а файловой системой. На десктопе у меня дисковая подсистема гораздо производительней. А если всю систему сборки (исходные коды, заголовочные файлы, библиотеки, компилятор и компоновщик) на что-нибудь вроде i-RAM запихать, вот тогда начнётся совсем другая жизнь!

Теперь к вопросу "А почему бы не сделать RAM-диск для быстрого файлового кеша?" Ответ настолько прост, что понять его не очень просто: "Не надо путать тёплое с мягким. Из двухметровой доски сделать две метровых просто, а наоборот?"

Совершенно с вами согласен :)
Дисковая система самый медленный компонент в современном компе.
 
Статус
Закрыто для дальнейших ответов.