64-бит или 32-бит ?

[Olej]

Думаю х86_64 будет впереди в основном за счет передачи параметров процедур через регистры

Я вот об этом как раз хотел спросить.
Но вы меня опередили:

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

(не надо было убирать, я только мельком успел почитать).

Так вот:
- в рекламных текстах и в разговорах распальцованных пацанов на форумах я не один раз встречал упоминания о передаче параметров процедур через регистры...
- но или они забрехались ... или я ничего не пойму.
- параметры передаются в С процедуру согласно "С соглашениям о связях", так же как есть "PASCAL соглашения о связях" (много используемые в Win32)... - эти соглашения (и только они в правилах языка!) определяют как передаются параметры и кто и как убирает кадр стека после выполнения.
- параметры в функции С могут передаваться через регистры, то только (я знаю) в 2-х случаях: а). функция явно описана с квалификатором asmlinkage (это многократно встречается в ядре Linux), б). при высоких уровнях оптимизации (-o3 ?) указанных компилятору GCC (это был бы крантец просто с отладкой, если б GCC стал это делать в штатном режиме компиляции!).
- ... и тот и другой предыдущие случаи не зависят и не могут от того, это 32 бит, или 64 ... или сколько угодно.
- единственный случай, когда можно понять рекламистов, это если речь идёт о системных вызовах - sys call(): там в классической 32 бит архитектуре если до 6-ти параметров, то они передаются в регистрах, а если >6, то блоком в стеке.
- но!!! много ли системных вызовов у которых >6 параметров (я не помню, может и нет уже вообще, а если есть, то 1-2 из пару сотен syscall() ... mmap?).

P.S. (дописано позже) - здесь я уже сам себя запутал:
- при >6-ти параметров syscall(), параметры блоком располагаются в произвольном месте в памяти, а адрес этого блока передаётся в регистре ebx - в этом месте выше ошибка.

Так что разговоры о "передаче параметров процедур через регистры" - это, похоже, просто "ля-ля"

[Olej]

x86_64

• можно запустить 32-битный код +
• нормально работает виртуализация +
• wine -
• меньше драйверов ИМХО -
• занимает больше места на диске -
• требуются 32-битные библиотеки -

• за счёт 64-бит операндов памяти - увеличение (бесцельное) размеров программ, библиотек, ядра ОС... - т.е. уменьшение эффективного размера RAM, если у вас 4Gb (для рабочей станции), то вы своими руками делаете из них, скажем, 3Gb - это явно не +
• то же но в отношении кэшей (всех уровней, и дискового в том числе) - уменьшение эффективных размеров, а это уже очень серьёзное снижение производительности - это -
• skype -

[Olej]

Хорошо если 5-10% на синтетических тестах.

Вариант дистрибутива/пакеты x86_64 можно ставить и на интел, и на AMD. Почти все современные процессоры интел и амд, кроме некоторых атомов, будут работать.

Т.е. возвращаемся к самому исходному вопросу:
- на большинстве современных компьютеров (сборки последних 5 лет) можно ставить на выбор: и i686 вариант Linux, и x86_64...
- вопрос в том: всегда ли целесообразно не задумываясь ставить x86_64, как часто и делают?
- я думаю, что это не так.
- но вот и вопрос: в каком случае предпочтительно ставить 32-бит Linux дистрибутив, а в каком 64-бит?
- а если 32-бит с PAE?

Кроме того, сюда вмешается (косвенным образом) ещё и размер отводимый свопу:
- при 4Gb часто советуют (рабочие станции): не отводите свопа вообще - при этом общий объём RAM в управлении не привышает лимит 32-бит даже без PAE.
- но при 2Gb RAM + 6Gb выделенных под своп (для некоторых серверных применений такая комбинация возможна?) общий размер адресуемой логической RAM уже выходит за лимит 4Gb.

[Olej]

Да. (amd64 == x86_64 == i32e == EMT64 ) != ia-64
Вариант дистрибутива/пакеты x86_64 можно ставить и на интел, и на AMD. Почти все современные процессоры интел и амд, кроме некоторых атомов, будут работать.

Итого, мы имеем в рассмотрении, для самой распространённой архитектуры процессоров - Intel x86 и её развитий (остальные процессоры не затрагиваем), 3 принципиально разные архитектуры, с точки зрения того, как их использует Linux:

Тогда ещё интереснее там рядом - http://www.debian.org/ports/index:

amd64 - 64-разрядный ПК (amd64). Впервые официально выпущен в Debian 4.0. Перенос для 64-битных процессоров AMD64. Целью является поддержка как 32-битного, так и 64-битного пользовательского пространства на этой архитектуре. Данный перенос поддерживает 64-битные процессоры Opteron, Athlon и Sempron от AMD, а также процессоры Intel с поддержкой EM64T, включая Pentium D и разнообразные серии Xeon и Core2.

i386 - 32-разрядный ПК (i386). Первая архитектура, на самом деле это даже не перенос. Linux изначально разрабатывался для процессоров Intel 386, отсюда и сокращённое название этой архитектуры. Debian поддерживает все процессоры IA-32, созданные Intel (включая все серии Pentium и последние процессоры Core Duo в 32-битном режиме), AMD (K6, все серии Athlon и Athlon64 в 32-битном режиме), Cyrix и другими производителями.

ia64 - Intel Itanium IA-64. Впервые официально выпущен в Debian 3.0. Это перенос на первую 64-битную архитектуру Intel. Примечание: не путайте с последними 64-разрядными расширениями Intel для процессоров Pentium 4 и Celeron, называющимися EM64T, вместо этого обратитесь к переносу AMD64.

Об этих различиях интересно посмотреть в книжке, которую я приводил, и которую можно свободно скачать:

В апендиксах начиная со стр. 1122 там очень интересные ссылки на область сохранения при системном вызове регистров пользовательского пространства, для разных архитектур (и поэтому отчётливо вылазит разница):

<asm-arch/ptrace.h> provides the pt_regs structure to hold all registers that are placed on the
kernel stack when the process switches from user mode to space mode as a result of a system
call, an interrupt, or any other mechanism. The file also defines the sequence of the registers on
the stack by means of pre-processor constants. This is necessary when tracing a process in order
to read register values from the stack.

A.7.1 IA-32
The IA-32 architecture suffers permanent register shortage, so there is not much to save when kernel
mode is entered, as the following definition of pt_regs shows:
include/asm-x86/ptrace.h
struct pt_regs {
long ebx;
long ecx;
long edx;
long esi;
long edi;
long ebp;
long eax;
int xds;
int xes;
long orig_eax;
long eip;
int xcs;
long eflags;
long esp;
int xss;
};

A.7.2 IA-64
In the design of IA-64, the designated successor of the aging IA-32 architecture, Intel has kept abreast of
the times and has given the processor a much bigger register set (with a more systematic name).
...

- см. стр.1124

A.7.8 AMD64
Even though the AMD64 architecture is very similar to its IA32 predecessor, a number of registers have
been added so that there are some differences as concerns the registers that must be saved during system
calls:
include/asm-x86/ptrace.h
struct pt_regs {
unsigned long r15;
unsigned long r14;
unsigned long r13;
unsigned long r12;
unsigned long rbp;
unsigned long rbx;
/* arguments: non interrupts/non tracing syscalls only save upto here*/
unsigned long r11;
unsigned long r10;
unsigned long r9;
unsigned long r8;
unsigned long rax;
unsigned long rcx;
unsigned long rdx;
unsigned long rsi;
unsigned long rdi;
unsigned long orig_rax;
/* end of arguments */
/* cpu exception frame or undefined */
unsigned long rip;
unsigned long cs;
unsigned long eflags;
unsigned long rsp;
unsigned long ss;
/* top of stack page */
};

- см. стр.1134

Из этих 3-х архитектур широкую Linux-общественность должны интересовать только 2: IA-32 (i386) & AMD64 (x86_64). Так?

[Olej]

Вот ещё мнения ... от программиста, по крайней мере:

http://forum.ubuntu.ru/index.php?topic= ... msg1497437

Переход с 32х бит на 64 нужен там, где требуется много памяти - в первую очередь, в серверах. Вопросы вычислений, их точности и скорости давно и прочно закрыты MMX/SSE технологиями. Никакого эффекта в точности и скорости вычислений при переходе с 32 в 64 бита не будет. Для людей, знакомых с сутью вопроса, это очевидно.
...
Короче. Для программиста 64 бита нужны там, где имеют место операции адресации. Во всех остальных случаях 64 битная целочисленная арифметика БЕСПОЛЕЗНА.

http://forum.ubuntu.ru/index.php?topic= ... msg1497695

Все это очень эффективно обрабатывается SIMD инструкциями (тыц), которые работают с упакованными целочисленными и вещественными данными и были СПЕЦИАЛЬНО разработаны для обработки потоковых аудио и видео. Размер слова MMX - 64 бита. С 1997 года. В Pentium MMX было 8 (ВОСЕМЬ) 64х битных регистров MM0..MM7. Обработка велась FPU, который, к слову 80ти разрядный.

Итак, 64х битная обработка данных у нас есть аж с 1997 года. Т.е., 15 лет. Где же за эти 15 лет она использована?
...
Нетрудно заметить, что всего 8 пакетов из более чем 300 нуждаются в 64бит инструкциях. И. опять же, очевидно, что число пакетов равномерно падает в диапазоне от MMX до SSSE3.

http://forum.ubuntu.ru/index.php?topic= ... msg1497877

ИМХО, x86_64 - для десктопа - все равно, что 10 мегапикселей камера для сотового телефона. Эффект аналогичный. Вроде бы "круто", а результат, скорее, отрицательный.

Вот такие есть мнения.

[Olej]

Интересно:
- присутствовал при установках Windows 7 profesional на новый современный компьютер, последняя линейка AMD-процессоров, с 8Gb RAM...
- 32-бит Windows 7 видит, но пишет "доступно для использования 2.72Gb" - это, нужно думать, для процессов пользовательского пространства;
- 64-бит Windows 7 пишет "доступно для использования 7.71Gb";

Насколько же хуже исполнение управление RAM в Windows 7 выполнено, чем в Linux, где:
- типовая 32-бит инсталляция тоже оставит пользовательским процессам 3Gb ...
- но уже 32-бит PAE инсталляция поддержит 64Gb, при условии, что на один единичный процесс не будет расходоваться больше 4Gb (на самом деле 3Gb);
- ну а 64-бит понятно ... там граница отодвинулась очень существенно.

Или я относительно Windows что-то не так понял?

[Sergey371]

Или я относительно Windows что-то не так понял?

Всё так, несмотря на использование режима PAE в 32-битных операционках от MS для "простых смертных", программно в ядре память ограничена 4GB см. PAE.

В общем когда то было "640K ought to be enough for anybody", а теперь вам и 4GB должно хватать ;)

[dmitriev]

"640K ought to be enough for anybody", а теперь вам и 4GB должно хватать ;)

Просто удивительно!
Что они, не учатся на собственных ошибках, что-ли?

[Sergey371]

Это не ошибки, а продуманное ценовое позиционирование по целевому применению, чистая экономика: если вам нужен комп "для дома для семьи" -- возьмите хомку или профф до 100 USD. Ах вам 4ГБ памяти мало? Извольте взять серверную операционку за бОльшие деньги, да ещё и добавить за CAL-ы и пр...

Это в Linux-е рабочая станция от сервера отличается только оптимизированными параметрами настройки ядра и демонов, и дело админа как это сделать, установкой соотв. дистрибутива или ручной юстировкой. А с коммерческими продуктами можно конечно и поюстировать... но сразу копирайт нарушаешь.