Вопрос из серии "какой фотик самый крутой".

Цитата:

от: Дык
Нету там ничего. Только "Internal Server Error".
Вы давно туда ходили?
Или это только мне так не повезло?

Мдя... по моей ссылке только мелкосовтовским эксплорерор можно попасть
Вот универсальная: RAMDisk "Enterprise" для Windows 2000 / Windows XP / Server 2003

2Дык
Вы категорически не понимаете суть проблемы. О каком незапуске компьютера Вы говорите, при резервировании железом адресного пространства. Поучите пожалуйста матчать, а то скучно. Нахватались вершков, пае, 3Gb, а в чем суть не понимаете. Сатурн совершенно верно написал, что на вин64 у него 32битный фотошоп видит 3,7 Гб, что на вин 32 не возможно в принципе, а конкретно на моей кофигурации тем более, потому как под вин32 у меня видно чуть более 2ГБ, в отличие от вин64, где видно все 4Гб. Сходите в знания майкрософт.

ЗЫ 20 лет назад, действительно у меня был XT с двумя пяти дюймовыми дисководами без винчестера, но году так в девяностом у меня появился 10 мб винчестер.

Цитата:

от: Дык

>>Я писал про то, что в том, какое количество оперативной памяти можно задействовать не зависит от 32/64-битности операционной системы - операционная система не играет здесь решающей роли.


Бред, тяжелый и липкий как ночные кошмары.


>>Ибо Photoshop CS2 пока еще не 64-битная программа.

Ну и что?


>>А 32-битная программа для доступа к более чем 2 Г оперативной памяти может использовать упомянутые мною выше 3 метода.

Так Вы про них не знаете нихрена.


>>Другими словами, если бы у вас стояла бы 32-битная операционная система, то Photoshop видел бы и жевал бы столько же оперативной памяти, сколько и сейчас

Лабуду пишете дорогой - вот для таких как ты даже код программы привожу

http://forum.ixbt.com/topic.cgi?id=79:271-41#1070

Вот Вам еще на закуску - просвещайтесь -

http://blogs.adobe.com/scottbyer/2006/12/64_bitswhen.html

P.S. Дома у меня 4GB, а на работе до 24GB доходит, я тут знаю чуток.

Цитата:

от: лучше выпить пива литр
2Дык
Вы категорически не понимаете суть проблемы. О каком незапуске компьютера Вы говорите, при резервировании железом адресного пространства.

1. Если не понятно, то поясняю - железо памяти в этом диапазоне (2-4 Г) никогда не резервирует. Ибо это не соответствует стандартам.

2. Вы путаете то что адресуется программой (процессом) и то что реально доступно.
Если процессор работает не в реальном, а в защищенном режим (который включается при загрузке любой современной операционной системы и никогда вплоть до выключения компьютера не выключается), то знать куда обращаеться физически при записи/чтении данных процесс не может. Именно на этом принципе и построена работа виртуальной памяти. И на этом же принципе построено изоляция программ друг от друга.
То есть, если программа № 1 обращается по адресу (условно) 256256, а спустя долю секунды другая программа № 2 обращается к тому же адресу 256256, она получит совсем другие данные. Ибо физически для программы № 1 процессор смапировал адрес 256256 на физическую оперативную память под адресом (условно) 128128128, а для программы № 2 процессор вообще выкинул адрес 256256 из оперативной памяти в файл подкачки и в момент обращения к адресу 256256 считает данные из файла и поместит в произвольное свободное место в реальной оперативной памяти, например, по адресу 161616.
Вот и получается, что программа № 1 адресует 2 Г.
Программа № 2 адресует те же 2 Г, но физически расположенные в другой месте оперативной памяти (а частично в файле подкачке)
И программа № 3 адресует те же 2 Г, но физически расположенные еще где то
И программа № 4 адресует те же 2 Г, но физически расположенные хрен знает где.

Если мы вернемся к вопросу о видеокарте, то пользовательскому процессу (программе) абсолютно пофиг, какое железо чего там зарезервировало. Оно (пользовательское программное обеспечение) этого в принципе знать не должно - это дело операционной системы и ее драйверов.
Ибо в семействе Windows NT (которое включает в себя Win NT, Win 2000, Win XP, Win 2003, Win Vista) пользовательские программы специально и серьезно изолированы от аппаратного обеспечения.
То есть если видеокарта, как вы написала, зарезервировала от 2 до 4 Г, то с точки зрения того же Photoshop в этом месте находится совсем другая фигня. Но никак не данные связанные с видеокартой.
Цитата:

от: лучше выпить пива литр

Поучите пожалуйста матчать, а то скучно. Нахватались вершков, пае, 3Gb, а в чем суть не понимаете.

Вам я привожу подробные технические обоснования.
А от вас слышу только "будет так и все тут". Без технических обоснований.
Цитата:

от:лучше выпить пива литр

Сатурн совершенно верно написал, что на вин64 у него 32битный фотошоп видит 3,7 Гб, что на вин 32 не возможно в принципе, а конкретно на моей кофигурации тем более, потому как под вин32 у меня видно чуть более 2ГБ, в отличие от вин64, где видно все 4Гб.

Подробнее

Кому видно? Photoshop'у? 32-битному Photoshop'у? Видно линейно?
Уверяю вас - это не так.
Линейно один процесс в Win32 API не способен адресовать память по записи более 2 Г (или 3 Г в режиме 3GB). Там выше расположены user-mode библиотеки и таблицы. Они конечно не 2 Г занимают, но по стандартам Win32 - это пространство все выделено под них.

Не линейно - пожалуйста. С этим я и не спорю.

Но не линейно - это под любой операционной системы (что 32 что 64-битной) доступно может быть то же количество оперативной памяти.

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

При использовании 32-битных программ для этих 32-битных программ ничего не меняется - они даже не подозревают о том, что запущены под 64-битной операционной системой. То есть как имели 2 Г линейно адресуемого пространства, так и имеют.

Некоторые 32-битные программы могут использовать и больше адресуемого пространства.
Если их разработчики-программисты об этом позаботились: сделали доступ к дополнительной памяти через PAE API или создают несколько процессов (каждый из которых получает 2
Г). Полностью 4 Г и более 32-битный один процесс простым образом получить не может, так как:

а) напрямую адресовать более 4 Г он не способен. Только через ухищрения
б) из 4 Г следует отнять место, занимаемое сервисными user-mode структурами операционной системы.

Цитата:

от: лучше выпить пива литр

Сходите в знания майкрософт.

Без конкретной ссылки ваши утверждения голословны.

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

Цитата:

от: Saturn
Цитата:

от:Дык

>>Я писал про то, что в том, какое количество оперативной памяти можно задействовать не зависит от 32/64-битности операционной системы - операционная система не играет здесь решающей роли.


Бред, тяжелый и липкий как ночные кошмары.

Подробнее

Литературно красиво, но не по делу.
Ибо не приведено техническое обоснование вашей точки зрения.
Цитата:

от: Saturn


>>Ибо Photoshop CS2 пока еще не 64-битная программа.

Ну и что?

Это значит:
1) пользуется для работы не 64-битными, а 32-битными указателями. То есть физически неспособно адресовать более "2 в степени 32 = 4 Г" адресного пространства.
2) пользует Win 32 API, а не Win 64 API со всеми присущими ему ограничениями (самое существенное из которых - половина - 2 Г - адресного пространства одного процесса занято user-mode структурами операционной системы Windows; ну в режиме 3GB - структурами операционной системы занято 1 Г).
Цитата:

от: Saturn


>>А 32-битная программа для доступа к более чем 2 Г оперативной памяти может использовать упомянутые мною выше 3 метода.

Так Вы про них не знаете нихрена.

Хе. хе.
Не технический ответ.
Цитата:

от:Saturn


>>Другими словами, если бы у вас стояла бы 32-битная операционная система, то Photoshop видел бы и жевал бы столько же оперативной памяти, сколько и сейчас

Лабуду пишете дорогой - вот для таких как ты даже код программы привожу

http://forum.ixbt.com/topic.cgi?id=79:271-41#1070

Подробнее

Хе. хе.
Ну тогда добавьте в эту программу
"Забить все 4 Г числом 0", кроме самой программы и стека, разумеется. И скомпилируйте под Win 32 API.

При запуске этой программы - операционная система скажет "Программа допустила нисправимую ошибку и будет закрыта".
Ничего не получится, потому как туева хуча (около 2 Г) адресного пространства 32-битного процесса занята user-mode структурами операционной системы. И при попытке записать в них - операционная система надает вам по рукам.

Цитата:

от: Saturn


Вот Вам еще на закуску - просвещайтесь -

http://blogs.adobe.com/scottbyer/2006/12/64_bitswhen.html

P.S. Дома у меня 4GB, а на работе до 24GB доходит, я тут знаю чуток.

Я не утверждаю, если вы внимательно читали, что все так плохо.

Я говорю вам, только то, что переход на 64-битную операционную систему не помогает 32-битной программе иметь доступа к 4 Г оперативной памяти, если эта же 32-битная программа не умела пользовать более 2 Г под 32-битной операционной системой.

И наоборот, если программисты позаботились об этом, то под 32-битной операционной системой 32-битная программа может получить доступ хоть к, скажем, 10 Г оперативной памяти. Главное чтобы сама операционная система это поддерживала (это, правда, потребует операционной системы не Win XP 2002, а к примеру Win 2003 Advanced Edition, но такой же 32-битной)

Цитата:

от:BlackRed
Мдя... по моей ссылке только мелкосовтовским эксплорерор можно попасть
Вот универсальная: RAMDisk "Enterprise" для Windows 2000 / Windows XP / Server 2003

Подробнее

Спасибо.

Несколько лет назад пользовался ее аналогом для переваривания большого массива данных - реально ускоряет в дофига раз (многочасовая обычно процедура, после помещения всех данных на этот диска заняла - я не сразу поверил - всего несколько минут)

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

Придется провести маленький ликбез.

Терминология:
Словом "код" далее называется "программный код" (исполняемый код программы или исходный код программы).

1) С точки зрения поддержки 64-битного процессора процессора

1.а) Программа создается разработчиками программного обеспечения под определенные условия работы. В частности машинные (процессорные) команды для работы с указателями на участки памяти, определяется на этапе компиляции программы. Помимо других машинных (процессорных) кодов следует учитывать то, что и места в оперативной памяти 64-битные указатели занимают в 2 раза больше.

Указатели эти в свою очередь, используются для адресации участков данных, участков кода программы и обращения к API операционной системы. То есть, постоянно.

Таким образом для поддержки разных режимов работы прежде всего нужно скомпилировать программу 2 раза с разными параметрами - отдельно для работы с 32-битными и отдельно для работы с 64-битными указателями. И получить, соответственно, 2 набора exe-файлов, dll-файлов и т.д.

1.б) Кроме разницы в адресации имеется еще разница в арифметических и тому подобных функциях. Здесь проще. Можно вставить в программу ветвление - одна ветка будет пользовать одни функции, другая - другие.

Такие вещи делаются уже очень давно - еще с тех пор как появилась технология MMX, SSE, 3DNow, SSE2, 32/64-битные операции и тому подобное. На одном процессоре в программе задействуются одни участки кода, на другом процессоре - другие участки кода.

Данная фенечка дает возможность использовать те или иные особенности конкретного процессора, но не дает возможности использовать адресацию более 4 Г. Что нужно для адресации - описано в пункте 1.а).

2) С точки зрения поддержки операционной системы.

2.а)
Пункта 1) было бы достаточно, если бы программа самостоятельно работала на компьютере. Но современные программы (за исключение особых случаев, когда ни Windows ни MacOS ни *nix не используются) работают только в тесном сотрудничестве с операционной системой.
Любое изменение изображения на экране, любое обращение жесткому диску, часть манипуляций с оперативной памятью (выделение памяти, освобождение памяти, обращение к памяти если вдруг данный конкретный участок вытеснен с реальной оперативной памяти в своп-файл) происходят только через операционную систему.

Посему программа должна знать как общаться с операционной системой. Правила этого общения называется API операционной системы.

Для 32-битных программ используются Win32 API, а для 64-битных используются Win 64 API.
Почему 32-битная программа не может работать с Win64 API? Потому что указатели в Win64 API имеют длину 64-бита (8 байт). А при компиляции программы предусмотрено, что указатели будут иметь длину 32-бита (4 байта).

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

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

Но нам достаточно уже того вывода, что программы 32-битные внутри устроены по другому и общаются с операционной системой на другом языке. Не так как 64-битные программы.

2.б) Как общается с операционной системой прикладное программное обеспечение.

Существует 2 метода:
Использование прерываний,
Адресация в определенные участки памяти.

Из соображений производительности и гибкости разработчики Windows предпочли второй вариант.

И второй вариант дополнительно ускорили.
Дело в том, что операционная система и все программы изолированы в Windows с использование специального режима работы процессора - защищенного. То есть программа не может прочитать системную информацию. Если программа просканирует всю доступную ей область памяти - она просто не найдет никакой системной информации.

Для того, чтобы увидеть системную информацию, процессор должен переключиться в привилегированный режим работы.
Но такие переключения снижают производительность работы процессора (по крайней мере, значительно снижали производительность тех процессоров, которые существовали на этапе начала разработки Win 32 API).

Здесь разработчики Win 32 API сделали "финт ушами". Часть системных данных, которые относятся к данному конкретному процессу и часть системного программного кода, который должен обслуживать данный конкретный процесс и часть несистемного программного кода, который должен обслуживать данный процесс не скрыт в привилегированном режиме. Все равно все эти данные и весь этот код обслуживают исключительно этот процесс и ничего секретного общесистемного или данных других процессов (других запущенных программ) там нет.

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

И именно под этот "финт ушами", под эти обслуживающие конкретный процесс данные и код в спецификации Win 32 API и зарезервировано 2 Г. Остальные 2 Г отданы самому процессу (программе).

На тот момент, когда разрабатывалось Win 32 API посчитали, что этого хватит за глаза. Точно так же и в 1981 г. Билл Гейтс сказал: "640 килобайт оперативной памяти хватит всем". Так и в году разработки Win NT/Win 95 решили что 2 Г программа - это дофига.

Таким образом, ограничение 2 Г неотъемлимое свойство Win 32 API и если запустить 32-битную программу и отдать ей все 4 Г доступного ей адресного пространства, она просто не сможет работать, так как не сможет взаимодействовать с операционной системой.

Ибо взаимодействие с операционной системой происходит так:
программа передает управление (вызывает) какой-то системный код, расположенный в верхней половине 4 Г адресного пространства доступного 32-битной программе программе.

Причем для каждого отдельного процесса (для каждой отдельной программы) ситуация повторяется.
То есть, если у вас 15 процессов одновременно запущено, то каждому из 15 процессов операционная система может выделить 2 Г оперативной памяти. То есть всего 30 Г.

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

2.б) Как 32-битная программа задействует очень много оперативной памяти.

Сразу замечу, что какую именно - реальную оперативную память пользует программа или происходит постоянная подкачка с диска из своп-файла - прикладной программе неизвестно. Это все решает операционная система.

Хотя, при желании, прикладная программа может попросить операционную систему не своповать данные принадлежащие этой прикладной программе. Тогда, закономерно, данные принадлежащие другим прикладным программам, запущенным в данный момент будут своповаться интенсивнее.

Итак, как было описано в пункте 1.а) 32-битная программа адресует 4 Г, а как было описано в пункте 2.а) 32-битная программа не может использовать под свои нужны все 4 Г.

2.б.1) Решение от Adobe.

Фирма Adobe не стала дожидаться, когда фирмы Microsoft и Apple предложат оптимальное решение и уже очень давно (еще до появления первой 32-битной Windows) встроила в свою программу Фотошоп возможность подкачки в обход операционной системы.

Данный механизм называется "scratch-диски". Фактически это те же своп-файлы (файлы подкачки), только не системные, а управляемые самим Фотошоп. Управляется весьма эффективно, так что даже при небольшом объеме оперативной памяти и даже при отключенной подкачке (при отключенных своп-файлах) в Windows можно довольно таки комфортабельно работать с большими объемами графических данных.

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

Таким образом, большое количество оперативной памяти Фотошопу стало не обязательно. Просто при наличии скажем 12 Г оперативной памяти 2 Г (с учетом ограничений, накладываемых на 32-битные программы за счет "финта ушами") пользует сам Фотошоп, а оставшиеся 10 Г используются для кэширования "scratch-файлов". Причем это кэширование производится операционной системой незаметным для Photoshop способом. Таким образом, сколько там реально оперативной памяти Фотошопу, с появлением технологии "scratch-дисков",стало до лампочки.

2.б.2) Режим 3GB.

Тут все прост. Смотрим пункт 2.а)
Там описано разделение 4 Г адресного пространства на 2 Г под пользовательский процесс и 2 Г под системные и несистемные обслуживающие данный процесс структуры.

В режиме 3GB (который включается только после перезагрузки Windows если в файле "boot.ini", расположенном в корне системного диска напротив название операционной системы в конце строки добавить /3GB) - разделение адресного пространство идет 3 Г под пользовательский процесс и 1 Г под обслугу этого процесса.

Разумеется, если реальной оперативной памяти у нас 2 Г, то порядка 40% оперативной памяти будут постоянно своповаться. Но сама программа об этом не узнает.

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

2.б.3) Режим PAE

Включается так же как и 3GB, только в конце строки нужно добавить не /3GB, а /PAE.

Тогда в адресном пространстве нашего процесса по просьбе нашей программы Windows переводит некий участок в специальный режим.

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

То есть если мы выделили 8 Г оперативной памяти в этот участок, то весь сразу процесс его видеть не может (напоминаю про ограничение 4 Г вообще и еще минус 2 Г под обслугу процесса). Мы смотрим на эти 8 Г как бы через маленькое окно, которое операционная передвигает по 8 Г по просьбе нашего процесса.
Этот режим также называется "окнонным режимом адресации оперативной памяти" (AWE-режим).

Прикладная программа часть данных адресует обычным способом, а часть - через окно.

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

2.б.4) Несколько процессов.

Так как все ограничения накладываются только на 32-битный процесс, ряд программ, которые хотят пользовать много оперативной памяти без окон (так как использование оконного режима адресации оперативной памяти требует перевода операционной системы в режим PAE, в котором некоторые другие программы могут отказаться работать),
можно создать программу, состояющую из нескольких отдельно запускаемых процессов.

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

3.б) Как работают 32-битные программы под 64-битной операционной системой.

Так же как и под 32-битной операционной системой.

Более того, при разработке 64-битной операционной системы разработчики постарались сделать так, чтобы старая 32-битная программа, рассчитанная на работу с Win32 API, а не с Win64 API, не прочухала различий. Иначе бы куча 32-битный программ просто бы не смогла бы работать под 64-битной операционной системой.

И именно по этой причине - под 64-битной системой существует нагромождение фактически являющееся эмулятором 32-битной операционной системы внутри 64-х битной.

Это нагромождение включает в себя обслуживающие процесс структуры данных и системный и несистемных код, располагающийся так же как и на 32-битных операционных системах, внутри 4 Г адресного пространства, доступного нашему 32-битному процессу. И также отнимает от процесса немалую часть этого 4 Г адресного пространства.

И именно поэтому тот системный код, который располагает в адресном пространстве пользовательских процессов существует в 64-битных версия Windows в 2-х экземплярах - в виде 32-битных DLL-файлов и в виде 64-битных DLL-файлов.

И именно по этому механизмы работы с оперативной памятью у 32-битных приложений под 64-битными операционными системами - одинаковы.

То есть если под 32-битной операционной системой прикладная программа более 2 Г использовать не может, то оно не сможет этого и под 64-битной системой. Ибо ограничения заложены в саму эту программу и в Win 32 API, которое полностью эмулируется под 64-битной операционной системой.

И наоборот, если 32-битная прикладная программа может использовать более 8 Г под 64-битной операционной системой, то она то же сможет и под 32-битной операционной системой.

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

В 32-битных операционных системах семейства Windows по маркетинговым соображениям в дешевые версии (Windows XP 2002) внесены ограничения. При использовании дорогих версий Windows 2003 Advanced Edition - можно пользовать больше оперативной памяти.

Цитата:

от:Дык
Я говорю вам, только то, что переход на 64-битную операционную систему не помогает 32-битной программе иметь доступа к 4 Г оперативной памяти, если эта же 32-битная программа не умела пользовать более 2 Г под 32-битной операционной системой.

Подробнее

Так фотошописты озаботились - только результат разный - на 32-бит Win можно выжать то 2.7 GB где-то, на 64-бит Win фотошоп захватывает 3.7 GB.

В полном соответствии с обещаниями Microsoft о том как ведут себя исполняемые файлы с /LARGEADDRESSAWARE - код я привел.

Много простыней Вы тут написали.

Практика - критерий истины. Поставьте даже WinXP на систему с 4GB и попробуйте сколько захватит фотошоп, и попробуйте тот же комп с WinXP 64-бит, а про защищенные режимы можно уже не бредить - как оно это делается в реале прикладных разработчиков давно не иппетт...

Цитата:

от:Saturn
Так фотошописты озаботились - только результат разный - на 32-бит Win можно выжать то 2.7 GB где-то, на 64-бит Win фотошоп захватывает 3.7 GB.

В полном соответствии с обещаниями Microsoft о том как ведут себя исполняемые файлы с /LARGEADDRESSAWARE - код я привел.

Много простыней Вы тут написали.

Практика - критерий истины. Поставьте даже WinXP на систему с 4GB и попробуйте сколько захватит фотошоп, и попробуйте тот же комп с WinXP 64-бит, а про защищенные режимы можно уже не бредить - как оно это делается в реале прикладных разработчиков давно не иппетт...

Подробнее

+1 О чем в принципе и пытался втолковать.

2Дык выпейте йаду, и попробуйте чуть-чуть практики и матчасти.

Кому места не хватает? Радикальное решение: 5х3.5" диски в клетке 3х5.25" http://blogs.zdnet.com/Ou/?p=481&page=2 (на первой странице лирическая водица)