Подобные планы имелись у разработчиков Федоры 11. На сегодняшний день страница http://fedoraproject.org/wiki/Features/ArchitectureSupport утеряла все упоминания о дефолтном 64-битном ядре для 32-битной системы. Почему -- можно покопать в истории изменения страницы (я детально не разбирался).
Ты немного не в теме. 64-битное только ядро. Все система --32 бита.
Преимущества? Корректная работа NX-бита, линейное адресное пространство для всех процессов (4 Гб на каждый процесс), доступ к большему числу регистров для ядра, упрощенное управление памятью -- нет ограничений на объем установленной памяти и проблем с зарезервированными адресами для устройств.
cпасибо, мало там что то... с одной стороны интересно что они хотели это использовать как ядро по умолчанию, с другой стороны что же их остановило в пользу PAE варианта
Вот ключевая фраза: "Installing an x86_64 kernel for a 32bit distribution may cause issues, if users try to install third-party kernel modules - JSchmitt"
а разве в 32 битах он работает хуже? о_О
Можно пруфлинк?
>4 Гб на каждый процесс
ну там я и говорю, для моделирования ядерных взрывов :)
Пока что не видел десктопных приложений, которым столько памяти надо. Разве что игры, но настолько толстых линуксовых тоже не знаю
из того что удалось нагуглить
это задержки перехода из long mode <-> legacy mode
но судя по всему используется не это а long mode + compatability mode где задержек нет, еще Intel Conroe /Core2/ ругали за некоторое снижение производительности в 64 bit режиме, про то как с этим обстоят дела у Penryn Core2 найти не удалось
У всей линейки core2 есть небольшая особенность работы в 64-битном режиме. Так что-то с декодером инструкций и пакетной обработкой, за счет чего снижается темп декодирования инструкций (на практике же это не должно особо сильно приводить к снижению темпа исполнения инструкций, так как конвейер и так никогда на полную мощь не работает). В общем снижения нет, просто такого прироста производительности от перехода от 32х к 64х битам (в %) как у к8 (и новее) нет. Это починили только в Nehalem.
А не проще собрать pure 64 систему? Автоматически и вся программная проприетарщина куда-то улетучивается...
> а разве в 32 битах он работает хуже? о_О
> Можно пруфлинк?
За что купил, за то продал. Это цитата с той же странице о Федоре 11. А так, мое ядро пишет вот такие строки при загрузке:
Using x86 segment limits to approximate NX protection
Т.е. NX защита осуществляется посегментно, что не всегда достаточно, как я понимаю. Если интересно -- гуглите по этим строкам
> ну там я и говорю, для моделирования ядерных взрывов :)
> Пока что не видел десктопных приложений, которым столько памяти надо. Разве что игры, но настолько толстых линуксовых тоже не знаю
Это не за горами, учитывая то, что реально на 32-битной системе в винде доступно только 2 Гб памяти на процесс, а в линуксе без спец. патчей -- 3 Гб. Да и даже в этом случае работа с памятью далеко не прямая: man high memory/low memory.
проще говоря, имеете ввиду то что не работает разрекламированая фишка Интел - Macrofusion, когда процессор за такт ухитряется обработать сразу несколько инструкций.
pure64 не интересна и бессмысленна для меня, все равно придется много 32 битного ставить, да и с ноутбуком не будет бинарной совместимости
>Это не за горами, учитывая то, что реально на 32-битной системе в винде доступно только 2 Гб памяти на процесс, а в линуксе без спец. патчей -- 3 Гб. Да и даже в этом случае работа с памятью далеко не прямая: man high memory/low memory.
вот вот..
и "насос" данных по шине явно быстрее в 64 битном режиме качает
> В общем снижения нет, просто такого прироста производительности от перехода от 32х к 64х битам (в %)
Я сталкивался с тем, что на очень специализированном числодробильном софте увеличение производительности составляло до 5ти раз. С чем это было связано подробно разбираться не стал, может быть позже разберусь в кто так тормозит на 32х битах. Проявлялось на компиляторах -- gcc 4.2(3), icc 10.1,11, msvc 2005(8) и в двух осях -- linux и венда.
нвидиавские дрова не хотят ставятся в такой ситуации. Хотят либо чисто 32 либо чисто 64. Судя по поиску, даже если сделать симлинки с lib на lib64, то проблем можно ещё потом отгрести.
> какие плюсы и минусы данного решения, по сравнению с 32 bit kernel + 32 bit userland ?
* иксы-то придется тоже 64 битные делать (по крайней мере у меня 32 битные не запускались)
* а с 64-бит иксами и 32-бит все остальное opengl-ные проги не работают
разрядность не зависит, зато всё тот же 3DMark2003 , который больше тестирует графическую карту, показывает заметный прирост производительности, причем смешно то что показывает он его на 2 ГГц процессора, а если увеличить до 3 то уже почти без разницы. Под "насосом" имею ввиду прокачку данных до видеокарты,
вот оно как раз заметно быстрее.
думаю что _поставить_ действительно будет сложно, если пользоваться инсталлером, отчасти поэтому в федоре наверное и отказались от 64 битного ядра, из за того что нужно вручную разбираться с ситуацией и модуль (блоб) брать из пакета для 64 бит, а userland библиотеки из 32 бит. Если сделать установку и сборку модуля вручную - все отлично работает, даже быстрее.
плюс )
возможность запуска как 32 так и 64 бит приложений, мне конечно не хочется ставить всю систему на 64, но отдельные маленькие прожорливые программы можно
lzma 64 bit (-march=nocona)
real 6m49.235s
user 6m48.147s
sys 0m0.743s
против конкурента - lzma 32 bit (ICC 10.1 , Core2, PGO)
тот же lzma 32 bit ICC,Core2,PGO, но уже на 32 битном ядре, чуть чуть медленнее работает он на 64 битном, но что интересно что 32 битный вариант даже с такой оптимизацией не дотягивает до 64 битного , который просто собран GCC практически с флагами по умолчанию.
PS: мне интересно было проверить замедление в обработке 32 бит , да оно есть, но не сильно существено (core2 penryn)