Comments 41
UFO just landed and posted this here
Жесть. Почему просто не поставить 64-битную Windows?
Возможно, потому что 64-битная Vista или Windows 7 будут занимать намного больше места как на диске, так и в оперативке, а 64-ю Windows XP надо ещё поискать, а потом заставить работать :)
У меня другой вопрос: какой же софт в виртуальной машине требует больше 3 ГБ опертивки? Может, для фотошопа проще наоборот, Windows 7 64 bit, а в ней Ubuntu? :)
У меня другой вопрос: какой же софт в виртуальной машине требует больше 3 ГБ опертивки? Может, для фотошопа проще наоборот, Windows 7 64 bit, а в ней Ubuntu? :)
В моем случае, виртуальная машина — мое рабочее место, на переносном USB 3 жестком диске. Я часто работаю в трех разных городах, и мне удобно возить с собой именно такой девайс. Windows XP — это потому что, пока мы не перешли на Windows 7, ибо лицензирование. А память как ни странно жрет Chrome, корпоративная почта, антивирус и что-то еще, но главный пожиратель — это все же Chrome.
странно… вставляете в ноут/комп 8Гб (вместо 2 или 4) и при этом поставить 64битную версию винды нельзя, будет больше памяти есть
тогда зачем она(память) вам нужна??
тогда зачем она(память) вам нужна??
Что бы написать пост на хабре и получить инвайт.
Ну полно вам. Человек ведь красиво решил свою проблему. Мне например понравилась его идея.
UFO just landed and posted this here
а потом заставить работать :)
Хм, XP x64 прекрасно работала с момента выхода. Даже постабильнее, чем обычная Windows XP — ядро же посвежее.
Думаю правильней так: если есть возможность, нужно поставить 64-битную систему.
Но статья как раз для другого случая. Вы не считаете?
Но статья как раз для другого случая. Вы не считаете?
Еще можно заявить, что на компьютере с жестким диском возможно достижение скорости работы ссд, если в гостевой ос замапить вообще все на рам-диски.
Хм, начала поста не соответствует действительности — 32х битные системы не могут адресовать больше 4Гб памяти, при этом на эти 4Гб мапится адресация портов и видео встроенное. Поэтому доступно меньше 4Гб. Например на WinXP из 4х доступно 3-3,5Гб.
Извините, если не очень в тему, но это просто уточнение вопроса.
Извините, если не очень в тему, но это просто уточнение вопроса.
Спасибо большое! Поправил.
Могут. У меня 8гб на win xp 32bit. верхние 4,5гб как рам диск висят. Если может работать рамдиск значит система может адресовать. Но не использовать, конечно.
Интересный вывод. И как же вы в 4 байта запихнете адресацию больше чем на 4Гб? Ведь софт то 32-х битный, и приложение использует именно 4-х байтовые указатели
Хм, а не подкините мануальчик с подробностями реализации?
Вот тут мануальчик, который заключается только в добавлении /pae в boot.ini, а вообще чтобы pae работал он должен поддерживаться процессором.
Проблема 32-х битных систем не в том что они вообще поддерживают не более 4 Гб виртуальной памяти памяти (32-битные Windows Server 2000 Advanced без проблем поддерживает и больше, да и обычная XP c файлом подкачки я думаю тоже), а в том что адресное пространство процесса ограничено 4Гб и часть его съедает ядро.
Хотя и для преодоления этого ограничения есть всяких хитрости, типа PAE. Но это костыли, а костыли это потеря скорости и более сложный процесс разработки. 64-битному процессу доступно куда большее адресное пространство без всяких ухищрений.
Хотя и для преодоления этого ограничения есть всяких хитрости, типа PAE. Но это костыли, а костыли это потеря скорости и более сложный процесс разработки. 64-битному процессу доступно куда большее адресное пространство без всяких ухищрений.
Адресное простанство процесса ограничено двумя гигабайтами.
Для адресации 2 Гб 32 бита ни к чему, достаточно 31 бит. Вот тут все вполне лаконично описано:
The virtual address space for 32-bit Windows is 4 gigabytes (GB) in size...
Есть еще и костыль в виде /3gb, однако требуется:
To enable an application to use the larger address space, set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header. The linker included with Microsoft Visual C++ supports the /LARGEADDRESSAWARE switch to set this flag
msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx
To enable an application to use the larger address space, set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header. The linker included with Microsoft Visual C++ supports the /LARGEADDRESSAWARE switch to set this flag
msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx
А я говорю — два гигабайта на процесс. blogs.msdn.com/b/tom/archive/2008/04/10/chat-question-memory-limits-for-32-bit-and-64-bit-processes.aspx
И костыль до трех есть, но я изначально про то, что не 4.
И костыль до трех есть, но я изначально про то, что не 4.
Адресное пространство каждого процесса — ровно 4 Гб.
Просто один или два гигабайта из этих четырёх используются для интерфейсов ОС-приложение (хранения общих библиотек и т. п.), и недоступны для прикладных данных. Однако, все эти интерфейсы и библиотеки, тем не менее, доступны для нашего приложения именно в рамках его адресного пространства. Вы можете в своей программе получить адрес такой-то функции из разделяемой библиотеки, хотя она находится в «недоступной» памяти, а потом вызвать эту функцию по адресу. Таковой адрес в приложении существует — значит, находится в пространстве адресов приложения.
Причём, этот адрес в принципе может быть разным для разных приложений: в одном приложении библиотека маппится на одни адреса, в другом — на другие. А физически в памяти она вообще хранится один раз.
Ещё раз: то, что какая-то область недоступна для приложений, никак не исключает эту область из адресного пространства.
В IBM PC был процессор 8086. Разрядность его адресной шины — 20 бит, т.е. 1024 Кбайт. А в компьютере могло быть до 640 Кбайт ОЗУ. Остальное адресное пространство (384 Кбайт) отводилось для memory-mapped устройств: видеопамяти, ПЗУ и прочего. Это не означало, что «адресное пространство 640 Кбайт», это означало, что «размер ОЗУ 640 Кбайт», а простраство — 1 мегабайт, как положено.
Просто один или два гигабайта из этих четырёх используются для интерфейсов ОС-приложение (хранения общих библиотек и т. п.), и недоступны для прикладных данных. Однако, все эти интерфейсы и библиотеки, тем не менее, доступны для нашего приложения именно в рамках его адресного пространства. Вы можете в своей программе получить адрес такой-то функции из разделяемой библиотеки, хотя она находится в «недоступной» памяти, а потом вызвать эту функцию по адресу. Таковой адрес в приложении существует — значит, находится в пространстве адресов приложения.
Причём, этот адрес в принципе может быть разным для разных приложений: в одном приложении библиотека маппится на одни адреса, в другом — на другие. А физически в памяти она вообще хранится один раз.
Ещё раз: то, что какая-то область недоступна для приложений, никак не исключает эту область из адресного пространства.
В IBM PC был процессор 8086. Разрядность его адресной шины — 20 бит, т.е. 1024 Кбайт. А в компьютере могло быть до 640 Кбайт ОЗУ. Остальное адресное пространство (384 Кбайт) отводилось для memory-mapped устройств: видеопамяти, ПЗУ и прочего. Это не означало, что «адресное пространство 640 Кбайт», это означало, что «размер ОЗУ 640 Кбайт», а простраство — 1 мегабайт, как положено.
Хех, пока искал пруфы, тут уже развернутый ответ накатали :)
Не соглашусь. Можно сколько угодно придираться к словам, и тыкать циферками, но на 32 битной системе процесс не может адресовать больше 2х гигов без включенного флага large address aware.
Технически, 32 битный процесс способен адресовать 4Гб, с этим я не спорю. Но 32 система(без флага /3GB) его ограничивает 2 гигабайтами, хоть ты трести.
А вот если 32 битный процесс запустить на 64 битной системе, тогда он как положено сможет адресовать 4Гб.
Технически, 32 битный процесс способен адресовать 4Гб, с этим я не спорю. Но 32 система(без флага /3GB) его ограничивает 2 гигабайтами, хоть ты трести.
А вот если 32 битный процесс запустить на 64 битной системе, тогда он как положено сможет адресовать 4Гб.
А для 32-битного процесса разве не эмулируется 32-битное окружение, с shared-библиотеками «вверху памяти» и т.п.? остаются все те-же 2гб минус занятое библиотеками место, откуда 4?
Забыл добавить: нужно не забывать разницу между понятиями «может адресовать» и «может использовать»
Марк пишет что
Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory.
blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory.
blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
И все таки 4Гб на процесс, но верхний диапазон адресов: 0x80000000-0xFFFFFFFF не доступен из user mode.
Пруф ищите текст: Если говорить совсем точно, то раздел для ваших данных в случае 32-х бит имеет диапазон $0000FFFF-$7FFEFFFF
Пруф ищите текст: Если говорить совсем точно, то раздел для ваших данных в случае 32-х бит имеет диапазон $0000FFFF-$7FFEFFFF
А я читал Руссиновича, а не Алексеева. Сходу, одной строчкой:
blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx
Even if the thread had no code or data and the entire address space could be used for stacks, a 32-bit process with the default 2GB address space could create at most 2,048 threads.
blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx
Even if the thread had no code or data and the entire address space could be used for stacks, a 32-bit process with the default 2GB address space could create at most 2,048 threads.
Нет там потерь. Собственно PAE выполняет блок MMU в процессоре, полностью аппаратно, да ещё и с использованием TLB (буфер трансляций).
С точки зрения разработки приложения вообще никакой разницы: как писалось под 4 Гбайт, так и пишется.
С точки зрения разработки приложения вообще никакой разницы: как писалось под 4 Гбайт, так и пишется.
идея стара как мир. можно создать рамдиск и поставить на него гостевую систему целиком ))
В общем, проблема с 4 Гбайтами памяти в XP — проблема не XP. Процессор-то умеет, ОС в принципе тоже умеет, но вот некоторые драйверы (были) уверены, что 32 бит достаточно. А ещё в этом (было) уверено некоторое оборудование, которое имеет доступ к памяти помимо процессора, т.е. DMA, а также контроллеры PCI.
Совместимость, блин. Уже в Windows 98 или в Windows NT 4 можно было сделать доступными более 4 Гбайт, но не делали из-за проблем с совместимостью устройств.
А вообще проблемы, описанной в топике не существует. У меня есть 32-битная машина с линуксом и 12 гбайт ОЗУ, и вся эта память отлично видна и используется ОС и приложениями (каждому из них, правда, достаётся по-прежнему не более 4 Гбайт — адресация в MMU 32-битная, никуда не денешься). В десктопной винде это просто намеренно отключено.
Совместимость, блин. Уже в Windows 98 или в Windows NT 4 можно было сделать доступными более 4 Гбайт, но не делали из-за проблем с совместимостью устройств.
А вообще проблемы, описанной в топике не существует. У меня есть 32-битная машина с линуксом и 12 гбайт ОЗУ, и вся эта память отлично видна и используется ОС и приложениями (каждому из них, правда, достаётся по-прежнему не более 4 Гбайт — адресация в MMU 32-битная, никуда не денешься). В десктопной винде это просто намеренно отключено.
Sign up to leave a comment.
Использование более 4Гб оперативной памяти в 32 битных гостевых операционных системах