Разница х86 - 64х линукс

Ну, в том, что половина, она права =)

А уж половина от чего (от количества регистров YMM0-YMM7, или от их разрядности), уже не так важно =)

ЛОР стал таким же как Хабр. Всем плевать что тут ложь распространяют. С меня хватит.

То что у чуваков адресация памяти равна разрядности ядер это обычное месиво в мозгах. Ты слишком на многое надеялся в среде линуксоидов. Они будут обсуждать Mesa 26, но старательно забудут что выпущен FSR Redstone и что он может работать на RDNA3 картах, причем только в линуксе.

AVX и будет работать в 128 бит, потому что AVX 1-й версии именно 128 бит имеет. AVX2 это 256 бит, AVX512 - ну ты понял да?

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

32-битные Linux имеют смысл только на очень старом 32-битном железе

Вообще-то и на новом (~5 лет) всё вполне работает. Разница - только в том что 32-битный софт кушает поменьше памяти. Удобно то, что без каких-либо проблем и правок компилируются всякие любительские исходники, написанные чаще всего из расчета того что int это 32 бита и указатель это тоже 32 бита. Если кто не знает - для переносимости на 64 бита надо даже банальный printf макросами обмазывать. Не говоря о каких-нибудь прошивальщиках всяких железок (типа раций например) где при переносе на другую разрядность «поедут» все объявления структур данных, в железку передающихся, и возникает хороший такой шанс её окирпичить из-за неправильной прошивки. Тоже самое с конверторами/распаковщиками/запаковщиками файлов прошивок.

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

Переход с 32 на 64 был оправдан хотя бы тем, что уперлись в потолок памяти.

32-битный x86 с включенным PAE технически способен адресовать 128 Гб памяти. Оно конечно потолок - для каких-нибудь спецприменений, но точно не для массовых компов, которым и сейчас до этой цифры далеко. И не очень понятно надо ли им это. Потому что чем больше объемы перевариваемых компом данных - тем выше энергопотребление так как больше вентилей переключаться должны. А резервы сокращения потребления энергии логическими вентилями почти исчерпаны - меньше их уже особо не сделать так как уперлись в размеры атомов.

и там теперь тоже отвечает ИИшница.

И здесь теперь тоже.

А смотрят на это все Глазунья из Рязани?

32-битных дистров уже практически не осталось

Это ложное утверждение.

ТС надо почитать новости

В новостях например Дебиана еще несколько лет назад писали что у них сильный дефицит сопровождающих пакеты и поэтому они вынуждены отказываться от всего от чего хоть как-то отказаться могут. При этом они НЕ смогли отказаться от сборки под ARMv7, он же armhf, который, внимание, тоже 32-битный. Соответственно весь софт который собирается под него - соберется и под x86-32. А следовательно все дистрибутивы которые пользуются дебиановской пакетной базой - имеют возможность продолжать собирать пакеты.

Есть более интересный вопрос: как продолжать собирать и использовать 32-битный софт в 64-битном линуксе? Чтобы можно было совместить преимущества 64-битности для того софта которому они нужны (нейросети например) и возможность использования того софта который без переписывания и хуже того - повторной отладки - собраться и работать на 64-битном линуксе не способен. А такого софта много. Просто он не «на слуху» у тех кто с ним не имеет дела.

скоро будет апокалипсис всего старья на 32 бита, которое не обновлялось с прошлого тысячелетия. Всего-лишь надо дождаться 2038 года.

Да, это будет проблема намного серьезнее 2000 года. Особенно учитывая накопленные объемы софта. В том числе такого, чьи авторы давно отошли от дел, а фирмы, осуществлявшие поддержку, прекратили свое существование.

32-битный ARM, которого пока заметно больше чем AArch64

А больше его еще и по причине лучше энергоэффективности. Что весьма актуально во всяких embedded-применениях. Особенно тех где особо высокая вычислительная производительность не требуется.

Знаете, истина где-то посередине, вполне возможно все что актуально и перекочевало в 64 там и будет жить и развиваться, а остальное перепишут под какие-нибудь арм.

Очевидно что не везде нужна паравиртуализация, но ради этого избыточно оберегать,- вполне может быть такой забавный выход. Иначе еще и спецификации языков дуть придётся, а так как с MMX и SSE: ваши компы не умеют, а под них уже собирать не будем (это про браузеры пример)

«Я работаю в техподдержке, мне и не с такими приходится общаться.»

Это профдеформация.

32 бита позволяют адресовать 4 гигабайта памяти.

Смею напомнить например такой факт (из интернета, сам не пробовал) Windows 2003 R2 Datacenter 32 bit поддерживает 128GB памяти. За счет Physical Address Extension.

А чтоб прям x86_128… Ну а зачем?

Вот у меня такой же вопрос «зачем» про 64 бита если речь не идет о каких-то спецприменения типа нейросетей и прочего подобного что сильно требовательно к памяти. В более обычных применениях - важнее совместимость с уже написанным софтом и особенно драйверами всякого железа, в том числе и редкого и дорогого. И да, софт бывает закрытым, проприетарным и купленным за немалые деньги если посмотреть чуть дальше типично-бытового и даже офисного использования компов.

Из-за нормотивов срабатывания по времени. И новых чипов, которые уже aarch64

Время реакции на внешнее событие (например вызов прерывания) далеко не так очевидно связан с количеством битов в регистрах. При вызове прерывания регистры сохраняются в стек и если они в два раза больше то и действий для их сохранения процессору надо выполнить больше. Способен ли он сделать это быстрее за счет например своей более высокой частоты - требует отдельного изучения. Поэтому утверждение о причинах использования aarch64 связанных с нормативами по времени - является ОЧЕНЬ спорным. Особенно применительно к поездам, а не каким-нибудь особо быстро протекающим физическим процессам. Зная российскую бюрократию - тут куда больше похоже на «освоение капиталовложений» на закупках более дорогой электроники.

Даже во времена 16-битных DOS систем, 64 Кб «окно» памяти позволяло делать многие вещи

А пределом объема памяти для DOS-экстендеров на 80286 было аж 16 мегабайтов памяти, для тех времен цифра почти не достижимая из-за цены самой памяти и редкости и цены железа куда ее вообще можно было воткнуть..

и в какой прикладной задаче требуется постоянно использовать 128битное пространство чисел ??

А так ли много задач где постоянно надо использовать 64-битное пространство? Если конечно не раздувать целенаправленно софт используя всякий electron и ему подобные гадости.

Время сохранения контекста на стеке - десятки наносекунд, при этом разница при сохранении большего количества регистров - 2-3 цикла на регистр, ну или проще говоря мы говорим о 10 наносекундах плюс-минус. При необходимости ответа обработки в микросекунду, доступ к стеку вряд ли является существенной величиной. Я думаю есть места где нужно беспокоиться побольше чем про регистры на стек.

32-битный x86 с включенным PAE технически способен адресовать 128 Гб памяти. Оно конечно потолок…

Это очень теоретический потолок. На практике гораздо меньше.

Лет 20 назд мне доводилось видеть DL585 с 64-битными AMD Opteron-ами и 32 гигами памяти, но на который зачем-то взгромоздили 32-битный Линукс. 32 гига конечно же виделись с PAE, но работало все очень хреново - периодически сыпались ошибки от ядра «page allocation failure».

Т.к. это был Линукс с платной поддержкой, завели кейс. Ответ техподдержки был примерно такой: «Вы придурки? На 32 битах мы не поддерживаем больше 16 гигов памяти. Ибо в 32-битном линуксе сплит адресного пространства 1:3 (kernel:user), и при 32 гигах page tables становятся настолько большими, что с трудом вмещаются в гигабайт адресного пространства ядра, поэтому вы и ловите эти page allocation failures. При 32 гигах юзайте только 64-битную ОС.»

В винде, кстати, сплит 2:2 - там с этим лучше. Ну а при использовани ключика /3GB в boot.ini все те же ограничения в 16GB, что и в Линуксе.

вполне возможно все что актуально и перекочевало в 64 там и будет жить и развиваться

Когда говорят «актуально» - надо всегда уточнять ДЛЯ КОГО. Для хомячков - вполне верю. Они вообще не заморачиваются сколько у них там битов.

а остальное перепишут под какие-нибудь арм.

В том-то и дело что в промышленности и даже в разных серьезных технических хобби за прошедшие три десятка лет понаписано огромное количество софта под 32-битный x86. Переписать это займет не один десяток лет. Особенно судя по тому что там по сей день попадается аж 16-битный софт, который всё еще не переписали. Много софта без исходников, либо закрытого либо исходники утрачены по чисто историческим причинам (авторы умерли, фирмы позакрывались).

под них уже собирать не будем (это про браузеры пример)

Опять же - не на каждом компе, используемом для работы (а не развлечений) нужен браузер, поддерживающий абсолютно все нововведения, добавленные в веб. К примеру чтобы настроить роутер через его веб-интерфейс - хватит весьма простого браузера. А чтобы настроить некоторые охранные видеокамеры - нужен не новый браузер,а internet explorer из старых виндов. В прошлом году купил три штуки таких на Озоне, на печатных платах дата 2018 год. Камеры кстати отличные, на сенсорах аж от Sony. Перешил их в OpenIPC - там IE не нужен.

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

Я думаю есть места где нужно беспокоиться побольше чем про регистры на стек.

Согласен с вами. Я лишь привел наиболее очевидный пример неоднозначности связи разрядности архитектуры и временнЫх параметров. И я таки не верю что для российских поездов потребовалась 64-битная архитектура процов потому что процы якобы чего-то там не успевали. Можно вспомнить про французкие поезда TGV, которые катаются с 1981 года. В Японии тоже высокоскоростные поезда давно есть. А вот в России почему-то битов в процессоре не хватило:-)

(я если что учился в ЛИИЖТе именно что на автоматику и телемеханику на жд транспорте)

Смею напомнить например такой факт (из интернета, сам не пробовал) Windows 2003 R2 Datacenter 32 bit поддерживает 128GB памяти. За счет Physical Address Extension.

Спасибо, кэп. Я, конечно, догадывался, что у кого-то хватит ума об этом напомнить, если самому не сказать. Но от тебя не ожидал. Вот реально, на ЛОРе надо на всё делать inb4-оговорки. Одно предложение по сути и пол-страницы «я знаю про PAE, но» — с казалось бы давно всем очевидными вещами, ограничениями, и т.д.

У меня фотка из шанхая есть на фоне табло «Текущая скорость 424 км/ч» :)

Это очень теоретический потолок. На практике гораздо меньше.

Так это же не железо виновато, а то как написаны существующие версии популярных ОС.

зачем-то взгромоздили 32-битный Линукс.

Очевидно - для совместимости с эксплуатируемым софтом. Но управление памятью в линуксе специально примитивизировано для упрощения переноса ядра на разные архитектуры, отличные от Интела. По всей видимости из-за ограниченности людских ресурсов для поддержки глубоко кастомизированных версий ядра под каждую отдельно взятую архитектуру.

64 бита потребовалось чтобы эффективно работать с памятью большей чем 2^32 ячеек т.е. большей чем 4Гб.
даже сейчас из 64бит адреса лишь 48бит используется для физического адреса, что равно 256 Tib памяти. пока хватает :) понадобится больше еще расширят. электрону в среднем до лампочки на разрядность слова :)

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

Во-первых насчет «много» вы преувеличиваете. Посмотрите на размер пакетной базы Дебиана для ARMv7, он же armhf, который тоже 32-битный. Вот чего именно вам там не хватает?

Во-вторых «делает бессмысленной» только для того кому именно этот софт критически нужен. А вот если критически нужен софт, которого нет в 64-битной версии - то всё оказывается с точностью до наоборот. И такого софта много если чуть отойти от «домашне-офисного» использования компов например поближе к всякому промышленному оборудованию. Например когда приедете на диагностику своего авто - обратите внимание какой комп у мастера. Хорошо если там будет седьмые винды, а не вообще WinXP. Потому что автомобильный диагностический софт чуть ли не весь именно под старые 32-битные винды и даже на 64-битной «семерке» не запускается. Или как вариант - не работает нормально с подключаемыми специфическими железками потому что даже если драйверы пересобрали по 64 бита то не озаботились их тщательно отладить и получили ошибки форматов передаваемых данных. Ну или вообще драйверов нет. Причем это - авторынок, применение достаточно массовое. Про более редкие применения и так понятно.

я знаю про PAE, но» — с казалось бы давно всем очевидными вещами, ограничениями, и т.д.

Так ведь ограничения-то в архитектуре нынешних популярных ОС, а не в железе. Оно вот 128 гигов может. Хотя я допускаю, что когда (если?) на каждом компе будет не 4-8 гигов как сейчас,а 128+ то ситуация изменится. Вопрос лишь в том есть ли смысл в 128 и более гигах на обычном рядовом компе.

не 4-8 гигов как сейчас,а 128+ то ситуация изменится

Конечно нет. Вот когда 16 эксабайт будет, тогда (никогда) изменится.

И сейчас в рядовом компе 16–64 гига. Не путай свои компы с рядовыми.

64 бита потребовалось чтобы эффективно работать с памятью большей чем 2^32 ячеек т.е. большей чем 4Гб.

По факту вон у меня в соседней комнате стоит комп с 16 Гб и прекрасно работает с 32-битным Дебианом. Только вот включаю я его редко потому что шумный и жручий. А пишу это с куда менее мощного компа с 4 Гб памяти и тем же 32-битным Дебианом. При этом показометр показывает 57% занятости памяти. Причем примерно тоже самое будет даже если я KiCAD запущу и начну очередную электронную самоделку рисовать. То есть я даже 4 гига эффективно заюзать не могу кроме разве что как под дисковый кэш.

:~$ free -m
     total   used       free      shared  buff/cache   available
Mem: 3840    985        1639         212        1216        2305
Swap:3978      0        3978

даже сейчас из 64бит адреса лишь 48бит используется для физического адреса, что равно 256 Tib памяти. пока хватает

Всю дорогу люди испытывали проблемы параллельного программирования и придумывали способы расширения простой адресации на многопроцессорные системы. SGI в своё время много сделали для создания концепции разделяемой памяти, проекты GASNet или Global Arrays, кто слышал или помнит про такие. Не счесть им числа. Сегодня USM используется в Nvidia DGX. Идея проста - одно пространство адресации для всей системы. Теперь смотрите - 4 x 192 GB на четыре GPU и 1024 GB на CPU - 1512 GB на узел. Грубо 170 узлов максимум. Всего 170. Это я сеть не считаю.

И сейчас в рядовом компе 16–64 гига.

Я про те компы которые в пользовании у рядовых юзеров,а не у программистов или профессиональных игроманов(пардон,киберспортсменов). Даже 16 и то не часто попадается. Мне тут в провинции часто приходится быть «тыжпрограммистом» почему и вижу чем люди пользуются.

ограничения ч86 есть и аппаратные :) PAE был страничным костылем, в нем прога продолжает работать с 32битным адресом т.е. не может работать с более чем 4Гб памяти одновременно. просто таких прог может быть несколько и в общем памяти используется больше 4Гб.

посоветую использовать free -H (human like)

Или так

:~> free
              total        used        free      shared  buff/cache   available
Mem:     1055199804    17317676  1039538768     6705152    10327976  1037882128
Swap:             0           0           0

Я про те компы которые в пользовании у рядовых юзеров,а не у программистов или профессиональных игроманов(пардон,киберспортсменов).

И я.

Даже 16 и то не часто попадается.

Ты живёшь в параллельной вселенной. Все это давно поняли. Не обязательно это так настойчиво демонстрировать постоянно.

По факту вон у меня в соседней комнате стоит комп с 16 Гб и прекрасно работает с 32-битным Дебианом.

«Прекрасно» для твоих неприхотливых задач. Больше, чем 4 ГБ, один там использовать не сможет, только все вместе.

При этом показометр показывает 57% занятости памяти. Причем примерно тоже самое будет даже если я KiCAD запущу и начну очередную электронную самоделку рисовать. То есть я даже 4 гига эффективно заюзать не могу кроме разве что как под дисковый кэш.

Это никому не интересно.

32-битных дистров уже практически не осталось

Это ложное утверждение.

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

Даже во времена 16-битных DOS систем, 64 Кб «окно» памяти позволяло делать многие вещи

А пределом объема памяти для DOS-экстендеров на 80286 было аж 16 мегабайтов памяти, для тех времен цифра почти не достижимая из-за цены самой памяти и редкости и цены железа куда ее вообще можно было воткнуть..

зато теперь можно оторваться на DOSBox или 86Box или.. ну вообщем понятно


Мне вот как раз нужно было закрыть гештальт по установке TCP/IP под Windows 3.1, в свое время не осилив кривой Trumpet Winsock я сбежала на Slackware 3.3 , Wvdial и Netscape Navigator Gold 3.0
Сейчас правда под MS IE 3.0 открыть можно только несколько сайтов, http:// да и чтобы верстка не свела браузер с ума ;)

люди пользуются понятно чем, купили давно, работает.
Другое дело что никто не станет сейчас брать меньше чем 16, ну разве что цена будет совсем смешная, под какие-то совсем простые вещи.

Да поставят дату на 1978 и будут дальше себе пользоваться, а где это важно — в уме 60 лет отнимать. Хотя в большинстве случаев, где такое железо используется, на дату в принципе пофиг, скорее всего.

Можно поподробнее? т.е. сайт откроется, если поставить 1978 год +х , где х = дата после 2038-х? т.е. 1979=2039 1980=2040 1981=2041 и т.д.?

Другое дело что никто не станет сейчас брать меньше чем 16

Вам будет интересно заглянуть в Hardware раздел. Там каждое второе обсуждение ноутбуков о том, есть ли жизнь на 2GB, и обязательно вылезет какуй-нибудь условный amd, который будет жаловаться, что из 256MB занято только 8.

Похоже у ЛОР скоро будет такая же участь. что такое лор? этот сайт, или другой?

Это от того, что людям жалко выкинуть старье, которое еще работает, вот они и хотят продлить «жизнь» ему

многопроцессорные системы «это другое» к разнице x86-64 vs x86 отношения не имеющая. сейчас там вообще правит numa и в ней память неоднородная даже в пределах одной материнки…
я правильно пноял 170 узлов, каждый со своей физической памятью поверх всего этого барахла интерконнект на чтобы сделать общую для 170 узлов память ?? и какие получаются задержки при использовании интерконнекта ??

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

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

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

Как раз вот, где ИИ в каждой зубочистке, и полно мошенников уже сидевших, изучивших в тюрьме программирование и попавших в айти-банды после отсидки… 32 бита дает хоть какую защиту - у них нет таких знаний, ПО не сработает на 32 битном железе, ИИ из интернета бесплатный врятли сможет пройти с 64 на 32 бита. Я как раз хочу на 10-20 летнем железе использовать интернет, старое ПО, мне достаточно старого опен-офиса, никакая либра не нужна… паинт, калькулятор, музыка, читать в нете что то, даже телека нету с этими кодеками новыми, ну и в целом все спокойно хотя бы… Но предчувствую, что винда заставит подписывать ИИ, и нужно начинать готовится к этой линукс, поэтому вопросы у меня довольно дебильные - уже 10-20 лет прошло, когда я видел этот линукс в последний раз..

для этого вполне можно и фейк дату использовать или что еще закостылить :) от переполнения юникс_тайм так ничего и не произошло.
в системах с высокими требованиями не используется обывательское ПО (обычно).

главное чтобы про такие системы не забыли вообще :)


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

Короче вариантов много и катастрофических сценариев возможных - тоже
Любители фильмов-катастроф далее могут пофантазировать сами :)

Да, правильно. При этом используются стандартные DIMM как у всех нормальных людей. Какие задержки - ну давайте оценим. Single hop latency у стандартного Infiniband роутера порядка 500 ns. Скажем у вас двухуровневая сеть из 64-портовых устройств. Возьмем 220 ns latency для DDR5. Складываем. Меньше 3 us.

Это от того, что людям жалко выкинуть старье, которое еще работает, вот они и хотят продлить «жизнь» ему

И покупают такое тоже. Нет, не потому что жалко. Денег нет у людей.

Мы говорим о x86, причем о десктопном применении. Ответ сразу – Chrome и подобном, в частности мессенджеров на Electron.

Это конечно не все, есть и иное ПО, что только x64.

Ничего спорного. Если бы аrm32 развивались по быстродействию, было бы спорно. А так нет. Развиваются уже 64 разрядные технологии

Можно поподробнее? т.е. сайт откроется, если поставить 1978 год +х , где х = дата после 2038-х? т.е. 1979=2039 1980=2040 1981=2041 и т.д.?

Какой нафиг сайт?

Нет, никаких таких автоматических переводов не будет. Я же сказал «в уме». Просто пользователь будет видеть в углу экрана не ту дату, в логах тоже. И будет понимать, что если написано 1979, это на самом деле 2039, и всё. На десктопе, причём тут какие-то сайты? Сайты на древнем 32-битном потребительском железе обычно не крутят. Ну а кто крутит на подкроватном сервере — может сделать ровно такой же костыль уже и на самом сайте.