64-битный Linux
Операционные системы семейства *nix и особенно их разновидности с открытым исходным кодом никогда не испытывали затруднений с портированием на самые разные архитектуры. Unix вообще задумывалась как портируемая операционная система[Недаром же стандарт на Unix-системы называется POSIX - Portable Operation System Interface for computer environments], а множество добровольных помощников - неплохой способ сократить время отладки и тестирования новой разновидности "операционки" и драйверов для нее.
Именно это и позволило юниксоидам в полной мере использовать 64-битные x86-процессоры сразу же после того, как появились первые компиляторы, поддерживающие 64-битные инструкции x86-64. Благо что при желании собрать свой "64-битный" дистрибутив может любой человек, обладающий достаточными познаниями в программировании, организации и администрировании *nix-систем; а перекомпилировать "обычную" программу для того, чтобы она получила поддержку x86-64, в большинстве случаев может и обычный пользователь. В мире Unix-систем, в отличие от Microsoft Windows, поддержка технологии x86-64 происходит гораздо естественнее - если приложение (или драйвер) распространяется в "исходниках", то в большинстве случаев его достаточно "пересобрать" (заново откомпилировать программу); а если в "бинарниках" (в заранее откомпилированном виде) - то почти всегда этот бинарник представлен в целом ряде вариантов под разные версии *nix-систем, среди которых наверняка найдется подходящая версия под вашу конкретную операционную систему. Поскольку все вышесказанное относится и к драйверам (которые могут считаться пусть и не самостоятельными, но программами), то проблем с ними тоже, как правило, не возникает[Для некоторых устройств unix-драйверов попросту не существует - ни для 32-битных, ни для 64-битных версий операционных систем. Но эту ситуацию уже никак, естественно, не исправишь].
Мы попробовали установить один из современных дистрибутивов с поддержкой x86-64 - Linux Corporate Server 3.0 от компании Mandrake. С инсталляцией и опознанием оборудования трудностей не было (разве что аудиокодек не распознался); с компиляцией тестовых приложений - тоже. В отличие от своих Windows-собратьев, скомпилированные наиболее распространенным компилятором GCC эти приложения выиграли в производительности куда больше (до 40–50%). Дело в том, что GCC - кроссплатформный компилятор, способный генерировать машинный код для двух десятков разных процессорных архитектур, а потому код для каждой из архитектур он генерирует по более простым алгоритмам, нежели "заточенные" под IA-32 компиляторы, и потому от "подводных камней" x86 страдает больше. К примеру, в x86 рекордно мало регистров общего назначения и регистров SSE по сравнению с другими процессорами, на которые GCC рассчитан. Поэтому переход к удвоенному числу регистров общего назначения так сильно упрощает GCC работу, что он перестает "по-глупому" спотыкаться - и возникает большая "дельта" между результатами одной и той же программы в 32-битном и 64-битном режиме. Разумеется, это справедливо не для всех приложений, но для очень многих, так что если ваш процессор поддерживает технологию x86-64 и вы намерены установить на него операционную UNIX-систему - лучше заранее купите 64-битный дистрибутив.
Как пересобрать *nix-приложение для поддержки x86-64
Большинство используемых в обычной жизни вариантов Linux ориентированы на работу с бинарными пакетами, и пересобирать программы в них приходится нечасто. Если вы хотите насладиться преимуществами 64-битной архитектуры, убедитесь, что заветные цифры "64" содержатся в номере версии вашего "дистро" - большинство крупных сборщиков поставляют специальные билды для этих целей. Впрочем, использовать или не использовать "продвинутые" дистрибутивы - вопрос открытый: Linux состоит из множества пакетов, и может статься, что нужная программа не собрана под 64-битную архитектуру в вашем репозитарии. Тогда можно попробовать собрать ее из исходников самостоятельно. Скорее всего, архитектура должна определиться автоматически (например, на этапе выполнения скрипта configure или при подготовке пакета из src.rpm-файла), и все нужные опции компилятора включатся без вашего участия. В особо запущенных случаях потребуется ручная правка Makefile. Здесь надо действовать по ситуации - но чаще всего будет достаточно добавить ключ –march <имя-архитектуры> при запуске gcc или g++[Например, –march k8 для сборки под AMD64 (полный перечень опций можно найти в документации gcс на www.gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html)].
Автор: Илья Щуров Voyager
Источник: www.computerra.ru
|
