64 bit linux kernel & 32 bit userland

Подобные планы имелись у разработчиков Федоры 11. На сегодняшний день страница http://fedoraproject.org/wiki/Features/ArchitectureSupport утеряла все упоминания о дефолтном 64-битном ядре для 32-битной системы. Почему -- можно покопать в истории изменения страницы (я детально не разбирался).

плюс - универсальность
минус - срач дублированного кода на диске и в памяти

А зачем тебе понадобились 64 бита? Гигантские базы данных, моделирование и научные расчеты? :)

Ты немного не в теме. 64-битное только ядро. Все система --32 бита. Преимущества? Корректная работа NX-бита, линейное адресное пространство для всех процессов (4 Гб на каждый процесс), доступ к большему числу регистров для ядра, упрощенное управление памятью -- нет ограничений на объем установленной памяти и проблем с зарезервированными адресами для устройств.

Минусы -- задержки на обработку 32-битного кода.

там только про PAE, для истории изменений вароятно требуется логин

Это ж обычная вики, вроде никакого логина не треба :)

http://fedoraproject.org/w/index.php?title=Features%2FArchitectureSupport&...

можно про задержку обработки IA32 кода поподробнее, или ссылочку. на не слишком заумную документацию и/или бенчмарки чтобы можно было сравнить

OpenGL стало быстрее работать (Nvidia 64 bit kernel module + 32 bit userspace), сравить остальное обьективно не чем пока

cпасибо, мало там что то... с одной стороны интересно что они хотели это использовать как ядро по умолчанию, с другой стороны что же их остановило в пользу PAE варианта

> можно про задержку обработки IA32 кода поподробнее, или ссылочку. на не слишком заумную документацию и/или бенчмарки чтобы можно было сравнить

Не можно, ибо нету у меня ссылочки. Посмотри сама, гугл в помощь.

Об этом чуть-чуть написано в http://fedoraproject.org/wiki/Talk:Features/ArchitectureSupport

Вот ключевая фраза: "Installing an x86_64 kernel for a 32bit distribution may cause issues, if users try to install third-party kernel modules - JSchmitt"

>Корректная работа NX-бита

а разве в 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 систему? Автоматически и вся программная проприетарщина куда-то улетучивается...

>Корректная работа NX-бита

> а разве в 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 битном режиме качает

>по шине явно быстрее в 64 битном режиме качает

разве разрядность шины зависит от режима работы камня? :)

> Это не за горами, учитывая то, что реально на 32-битной системе в винде доступно только 2 Гб памяти на процесс

если венду грузить со спец ключем в boot.ini, то тоже будет 3 гига на процесс

> В общем снижения нет, просто такого прироста производительности от перехода от 32х к 64х битам (в %)

Я сталкивался с тем, что на очень специализированном числодробильном софте увеличение производительности составляло до 5ти раз. С чем это было связано подробно разбираться не стал, может быть позже разберусь в кто так тормозит на 32х битах. Проявлялось на компиляторах -- gcc 4.2(3), icc 10.1,11, msvc 2005(8) и в двух осях -- linux и венда.

> Это не за горами, учитывая то, что реально на 32-битной системе в винде доступно только 2 Гб памяти на процесс

> если венду грузить со спец ключем в boot.ini, то тоже будет 3 гига на процесс

Это так, да. Только эти 3 Гб будут доступны не одним куском, т.е., например, в фортрановской программе такой массив использовать невозможно

Не было ли в этом софте много-много целочисленного умножения 64(128)-битных чисел?

нвидиавские дрова не хотят ставятся в такой ситуации. Хотят либо чисто 32 либо чисто 64. Судя по поиску, даже если сделать симлинки с lib на lib64, то проблем можно ещё потом отгрести.

Нет, только double. Я сильно подозреваю, что тормозит вот это:

double ipow(double x, int p)
{
        int i;
        double r = 1.0;
        for (i = 0; i < p; i++) {
                r *= x;
        }
        return r;
}

Тут p <= 5 поэтому решение в лоб тут самое быстрое.

64 бита:

ipow:
.LFB13:
        testl   %edi, %edi
        movapd  %xmm0, %xmm1
        jle     .L9
        movsd   .LC0(%rip), %xmm0
        xorl    %eax, %eax
        .p2align 4,,7
.L5:
        addl    $1, %eax
        mulsd   %xmm1, %xmm0
        cmpl    %edi, %eax
        jne     .L5
        rep ; ret
.L9:
        movsd   .LC0(%rip), %xmm0
        ret


32 бита:

ipow:
        pushl   %ebp
        movl    %esp, %ebp
        movl    16(%ebp), %edx
        fldl    8(%ebp)
        testl   %edx, %edx
        jle     .L9
        xorl    %eax, %eax
        fld1
        .p2align 4,,7
.L5:
        addl    $1, %eax
        cmpl    %edx, %eax
        fmul    %st(1), %st
        jne     .L5
        fstp    %st(1)
        popl    %ebp
        ret
.L9:
        fstp    %st(0)
        popl    %ebp
        fld1
        ret

> какие плюсы и минусы данного решения, по сравнению с 32 bit kernel + 32 bit userland ?

* иксы-то придется тоже 64 битные делать (по крайней мере у меня 32 битные не запускались) * а с 64-бит иксами и 32-бит все остальное opengl-ные проги не работают

разрядность не зависит, зато всё тот же 3DMark2003 , который больше тестирует графическую карту, показывает заметный прирост производительности, причем смешно то что показывает он его на 2 ГГц процессора, а если увеличить до 3 то уже почти без разницы. Под "насосом" имею ввиду прокачку данных до видеокарты,
вот оно как раз заметно быстрее.

думаю что _поставить_ действительно будет сложно, если пользоваться инсталлером, отчасти поэтому в федоре наверное и отказались от 64 битного ядра, из за того что нужно вручную разбираться с ситуацией и модуль (блоб) брать из пакета для 64 бит, а userland библиотеки из 32 бит. Если сделать установку и сборку модуля вручную - все отлично работает, даже быстрее.

>* иксы-то придется тоже 64 битные делать (по крайней мере у меня 32 битные не запускались)

отлично все работает
какая карта? какой драйвер? как ставили?

у меня nvidia , nvidia.ko - 64 bit, все остальное - 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)


real 7m8.091s
user 6m59.046s
sys 0m0.830s

real 6m57.615s
user 6m56.488s
sys 0m0.860s

тот же lzma 32 bit ICC,Core2,PGO, но уже на 32 битном ядре, чуть чуть медленнее работает он на 64 битном, но что интересно что 32 битный вариант даже с такой оптимизацией не дотягивает до 64 битного , который просто собран GCC практически с флагами по умолчанию.

PS: мне интересно было проверить замедление в обработке 32 бит , да оно есть, но не сильно существено (core2 penryn)

из феерических глюков (сейчас пересобираю Qt из за неправильного build-key)

нужно обязательно делать
setarch i386
(входит в пакет util-linux)

при сборке чего-либо, или явно указывать --host --build
но лучше еще и сделать перед этим setarch i386

иначе возможно неверное определение архитектуры при компиляции, со всеми вытекающими...

добавлю еще минус

virtualbox не работает в смешаном варианте, где модуль 64 а сам бокс 32