Было утверждение, будто IA-32 быстрее — я его опроверг, если у тебя нет противоположных тестов для класса задач. Памяти можно докупить, а вот производительность на ядро топчется на месте.

А совершенно объективные измеряемые параметры потребления памяти — это точно плацебо..

Не, объективно x86_64 потребляет больше памяти. Много ОЗУ и надо чтобы приложения её использовали. Истинное плацебо это «сравнивал работу совершенно идентичных x86 и x86_64 систем на одном железе на примере Lubuntu — вариант x86 был заметно шустрее».

Мне на 8-ми байтах(64 битах) сидится

x86_64

даже сами команды длиннее

Последнее время наблюдается тенденция когда софт 64bit онли. Как по мне давно уже пора перейти на это.

Где длиннее, болезный?

$ gcc -masm=intel -Wa,-adhln -march=native -O2      -x c -<<<'int main(){ volatile int a,b,c; a=b*c; }'
...
  10              	main:
...
  12              		.cfi_startproc
  13 0000 8B5424F8 		mov	edx, DWORD PTR [rsp-8]
  14 0004 8B4424FC 		mov	eax, DWORD PTR [rsp-4]
  15 0008 0FAFC2   		imul	eax, edx
  16 000b 894424F4 		mov	DWORD PTR [rsp-12], eax
  17 000f 31C0     		xor	eax, eax
  18 0011 C3       		ret
  19              		.cfi_endproc

$ gcc -masm=intel -Wa,-adhln -march=native -O2 -m32 -x c -<<<'int main(){ volatile int a,b,c; a=b*c; }'
...
  10              	main:
...
  12              		.cfi_startproc
  13 0000 83EC10   		sub	esp, 16
  14              		.cfi_def_cfa_offset 20
  15 0003 8B542408 		mov	edx, DWORD PTR [esp+8]
  16 0007 8B44240C 		mov	eax, DWORD PTR [esp+12]
  17 000b 0FAFC2   		imul	eax, edx
  18 000e 89442404 		mov	DWORD PTR [esp+4], eax
  19 0012 31C0     		xor	eax, eax
  20 0014 83C410   		add	esp, 16
  21              		.cfi_def_cfa_offset 4
  22 0017 C3       		ret
  23              		.cfi_endproc
...

он тебе про это:
1) add esp, 16 => 0x 83 C4 40
2) add rsp, 16 => 0x 48 83 C4 40
если ты сделаешь п.1 в 64-битном режиме (чего тебе никто, конечно, не запрещает) - старшая часть регистра тупо обнулится

Парочка мест в статье режет взгляд.

/* FIXME: я не уверен насчет проприетарных драйверов для
видеокарт. 64битный модуль ядра сможет дергать 32битные
библиотеки? --Тёма 05-May-2010 17:50 MSD

С каких пор драйвер дёргает библиотеки? С каких пор в статьи вставляют всякий левый трёп?

Нагрузка на процессор будет существенно выше (kernel-
userspace переключает не только контекст, но и режим
процессора long-compat)

На это нужен пруф-линк. Насколько я знаю, медленно происходит только переключение в legacy mode, но никак не в compatibility.

The resulting code should be considerably faster in the
majority of cases and avoid the numerical instability
problems of 387 code ... This is the default choice for the
x86-64 compiler.)

Тут битая ссылка.

Сравнение производительности 32-битной и 64-битной версий
дистрибутивов Fedora 9, openSUSE 11.0, Ubuntu 8.04.1)

Битая ссылка.

Некоторые open source приложения практически не работают в
родном 64-битном режиме, например, wine.

Оторвать бы им руки! До сих пор не спортировались? Позор.

Я на 64 битах уже наверное лет 5, уже нет даже тени мысли что это что-то не готовое или с какими-то особенностями...

Linux 32bit(X86) прекрасно видит и работает с опер.памятью свыше 4 Гб(в отличии от виндовс).

Ухты... Без PAE :)

И вот что сейчас с этой темой делать? Давайте хоть поправим ссылку на вики.

Берёшь 32х битную виндовс, размещаешь своп в озу выше лимита, «в будущем будете иметь значительно меньше проблем с установкой сторонних программ, игр, драйверов для вашего ПК»

Зачем ты лжёшь? Intel opencl sdk нет под 32бит, как и другого софта.

страницу на вики пора удалять, она уже как пару лет не актуальна и является исторической справкой, не более.

Тогда и тему стоит открепить. Тем более, что и тема «как пару лет не актуальна и является исторической справкой, не более».

я не против.

Ссылка то того.

Я разницы между ними по производительности почти не увидел

Конечно же если процессор поддерживает 64 бит то лучше использовать 64 бит.

Может пора уже этот тред закрывать и убирать из топа?

на дворе 16-й год, некоторые дистрибутивы прекратили поддержку 32-битных платформ. Может пора уже отлепить этот топик в историчесикй архив?

все десктопные дистрибутивы Microsoft поддерживают 32bit и гента поддерживает, так что не надо ля-ля

На винфак, быдло.

козябуль, не воняй

Ссылка то того

На вики.
И вообще, оно что еще актуально?!

конечно актуально - сейчас вон всякие мини pc на атомах пошли,
32 там рулит...

наблюдается тенденция когда софт 64bit онли. Как по мне давно уже пора перейти на это

Гуд бай ARM? :)

Это противостояние не так интересно как противостояние обычного и сдвоенного(gangeg mode) доступа в ОЗУ.
Как то он случайно выключился и компьютер заработал значительно быстрее.

Я на 64 битах уже наверное лет 5, уже нет даже тени мысли что это что-то не готовое или с какими-то особенностями...

Я на 64 битах 11+ лет сижу, но считаю, что в ряде случаев отказ от 32-х бит не оправдан.

Гуд бай ARM? :)

арм IP на 64 битные процы изготовил, вылезай из танка

вылезай из танка

Вылезу, когда эти процы будут массовыми и дешёвыми. А речь о том, чтобы отказаться от 32-х бит уже сегодня.

apple их во всю юзает уже, да и не только apple...

apple их во всю юзает уже, да и не только apple...

А что рынку всякого IoT до этого Apple?

Сначала на марс слетай дёшево и массово, а потом будешь рассуждать про отказ.

Калькуляторы и десктопы/рабстанции как бы совсем разные категории.

Кто говорит о калькуляторах? У меня дома два Linux-сервера под ARM. И они — 32 бита. И это сегодня самый массовый ARM.

Сначала на марс слетай дёшево и массово

А в Киеве дядько?

а потом будешь рассуждать про отказ.

То есть все уже перешли на 64 бита ARM? Или ты контекст потерял?

Разве в unix нет ограничения на кол-во доступной оперативной памяти? В 32-разрядных виндах максимум 4 Гб, как известно, что маловато в наши дни, там вопрос не стоит, 100% брать 64х и все. Если у линя такой разницы нет, то тогда бог знает зачем нужна 64х-версия, потому что геморроя с ней больше намного. Колдунство с одним вайном чего стоит, всякие библиотеки дотягивать в зависимости от разрядности и прочее.

арм IP на 64 битные процы изготовил, вылезай из танка

А как там с поддержкой Linux-ом Aarch64?
Все уже запилили и все вылизали, да?

Ты действительно не знаешь, что в 32 разрядной системе больше 4 гигабайт памяти адресовать нельзя (без костылей)? Даю подсказку - 2^32

В linux нет ограничения на кол-во доступной оперативной памяти. В винде есть.

На венде ограничение маркетинговое. И в обеих системах нельзя больше 3-4гигов на процесс и 64гигов (четыре планки ddr4) вообще.

совершенно верно

Всё винда поддерживает! А ещё плиточки можно тягать когда делать нечего!

У меня дома два Linux-сервера под ARM.

Самосборные? Если нет, можно поинтересоваться моделью?

Самосборные? Если нет, можно поинтересоваться моделью?

Один — Orange Pi, второй — из старого планшета Asus TF300T :) Оба — компоненты «умного дома», на обоих обычная Ubuntu ARM.

Есть ещё, правда, роутер под MIPS, но там стоковая прошивка.

Не смогла пройти мимо темы (: Вдогонку в вышесказанным сообщениям (признаюсь, не все я прочитала), соглашусь с некоторыми товарищами, если выбирать линукс между 32 и 64 версией, то на сегодня пока что ответ - 32. Но это только потому что часто имею дело с разработкой в WEB и ANDOID и к сожалению не все библиотеки корректно работают(если работают) под 64. Постоянно какая-то фигня демоническая творится. У всех работает у меня - нет ) и фиг нагуглишь. А 32 версия - все без глюков. Да сообщество линуксоидов идет вперед семимильными шагами, думаю еще лет 5 и будут достойные стабильные сборки софта и под 64.

НУ ТЫ И ПОЗОРИЩЕ ВСЕ УЖЕ ТОЛЬКО В 64БИТАХ ИГРАЮТ

Чем больше дистрибутивов и программ будут 64bit-only, тем меньше будет 32-битных луддитов.

Необучаемых такие мелочи никогда не останавливают.