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

86 - 64 = 22

Осталось узнать чему равно x. (=

Какие вопросы после прочтения страниц на Wikipedia по архитектуре x86 и её расширения x64 (x86_64, amd64) у тебя возникли?

Какие выводы ты сделал?

Собственно ответ в чём основная разница ты можешь сделать прочитав статьи.

Да. Значительная.

По правилам математики:

x86 - 64x = x*86 - 64*x = 86*x - 64*x = 22*x = 22x

Т.е. абсолютная разница 22x.

Ты единицу измерения потерял. Правильный ответ: 22x.

это разрядность, если на пальцах это как сравнивать «резину» на автомобиль: большую покрышку на малый диск оденешь, могут потребоваться «проставки» для работы с 64 на 32, наоборот не будет работать.

Это архитектуры процессоров. Подробнее читай в любой энциклопедии.

На практике ставь 64-битные, все ПО сейчас под эту архитектуру пишут, и процессоры в 99% случаев такие. Обратная совместимость с 32 битами – присутствует.

32-битные Linux имеют смысл только на очень старом 32-битном железе, которое устарело еще 16 лет назад минимум.

Точно такая же как и Windows.

Такая же как между живым и мёртвым. x86 мертво, 64x живо. Если ты не некромант, то выбор очевиден 😄

И не лень же тебе отвечать на вопросы людям, которым просто впадлу искать ответы!

А когда появятся 128-битные процессоры? Не пора ещё?

Это уже когда оперативная память подешевеет.

Не пора, переход на 64-бит регистры понадобился лишь из-за роста объёмов ОЗУ в компьютерах. Пока не изобретут способы многократного увеличения объёмов ОЗУ и их доступности - не будет перехода на 128 бит. Диапазона 64-бит достаточно для адресации 16 миллионов терабайт.

Лично я буду считать 128-битным процессором то, что будет иметь целочисленные регистры длинной 128-бит и команды для осуществления базовых арифметических операций на 128-бит.

Некоторые уже сейчас пытаются натянуть какую-то архитектуру на 128-бит. Когда там только SIMD на 128 бит, например. Или команды для использования объединенных базовых регистров. Это всё не по настоящему.

А зачем? 128-ми битные регистры и так есть. Аж с 2000-х годов. Если какие-то огромные числа нужно сложить, можно воспользоваться ими. SSE и AVX расширения процессора. Скажу даже больше. Компиляторы умеют ими пользоваться.

А делать полностью 128 битный процессор – очень дорого. Одних только кэшей сколько. В кэшах используется самая дорогая и быстрая SRAM память, на транзисторах, из двух вентилей «НЕ» на 1 бит. Это очень быстро и очень расточительно, дорого.

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

и 256 есть и 512 AVX

но их использование ограничено 64-битной архитектурой,
на 32-битах ваш AVX будет 128-битной тыквой

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

на 32-битах ваш AVX будет 128-битной тыквой

Обоснуй подобные заявления. Даже AVX512 должен на 32-бит работать (но у меня нет такого железа). AVX точно работает на x86_32 в 256 бит.

Обывательская, домашне-потребительская электроника да, вся уже 64 бита. Промышленная – еще не вся пока, но тоже постепенная замена есть. Я например недавно адаптировал драйвер, который был написан для х64 и использовал внутри себя битовые операции с 64-х разрядными числами. Начальство поставило задачу адаптировать драйвер для 32-х разрядного процессора Vortex, который все еще используется в промышленной автоматике. Он не умеет х64. Ну ниче, доработал, некоторые действия пришлось в 2 захода делать. Ничего страшного.

А когда появятся 128-битные процессоры? Не пора ещё?

http://en.wikipedia.org/wiki/128-bit

почему вы не хотите использовать поиск с ИИ ?

Работать - будет
использовать свои возможности на полную - нет

На 32-битной ОС нет поддержки 256-битности регистров YMM
Это в принципе обьявлялось еще при анонсировании соответствующих регистров и инструкций к ним (AVX2, AVX-512)

https://community.intel.com/t5/Intel-ISA-Extensions/Are-AVX-Intrinsics-suppor...

мне кажется на «обывательскую» и «потребительскую» идут всякие залежавшиеся чипы, ARM в основном, 32-битный ARM, которого пока заметно больше чем AArch64

Ничего, скоро будет апокалипсис всего старья на 32 бита, которое не обновлялось с прошлого тысячелетия. Всего-лишь надо дождаться 2038 года.
(Более нового ПО с 64 битным time_t это не коснется)

А когда появятся 128-битные процессоры?

Процессоры с некоторыми 128-битными регистрами уже есть. А чтоб прям x86_128… Ну а зачем? 64 бита более чем достаточно практически во всех задачах. Переход на 128 почти ничего не даст в прикладных задачах, за какими-то очень редким исключениеми, для которых проще заюзать дополнительный хардварный компонент, чем всю ОС в 128 битах ворочать.

Так что нескоро. Даже 64-битные процессоры для x86 стали реально востребованы только когда стало возможно установить 4+ ГБ оперативы. 32 бита позволяют адресовать 4 гигабайта памяти. 64 бита позволяют адресовать 16 эксабайт, соответственно (напомню, в эксабайте 1024 петабайта, а в петабайте 1024 терабайта). Вот когда столько оперативной памяти возможно будет поставить (никогда, скорее всего), тогда может начать иметь смысл делать x86_128. До того — вряд ли. Толку мало.

Новая электроника уже на китайских рок-чипах, они aarch64.

Еще скорость жизни и движения растет. Старая автоматика уже не везде справляется с ростом скоростей. Новая скоростная железная дорога например, Питер - Москва - НН - Казань. Она потребовала разработки новой отечественной схемотехники, новых плат. Из-за нормотивов срабатывания по времени. И новых чипов, которые уже aarch64

дело даже не в адресации оперативки, PAE вполне себе жизнеспособная вещь для большинства ПО, где не нужна прямая адресация большого пространства памяти.

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

То есть никогда?

для того чтобы справляться с «ростом скоростей» не нужна 128 битная шина данных, сааавсем не нужна :)

В ведре.

4 сегмента по 64 кб, кажется так оно было, насколько помню. Эх ностальгия… Не помню только можно ли было подвинуть сегмент прям на лету в процессе работы? Разве для этого не нужна была переинициализация процессора?

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

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

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

Я так понимаю человек не пользуется ИИ вообще, и наверно поэтому не пользуется гуглом, потому что там отвечает ИИ

Я так понимаю человек не пользуется ИИ вообще, и наверно поэтому не пользуется гуглом, потому что там отвечает ИИ

Можно пользоваться DuckDuckGo, например.

В спецификации EMS в качестве окна для доступа к дополнительной памяти используются 64 килобайта, расположенные по адресам C0000h - EFFFFh.

1 окошко )
работало и на 286,

для XMS памяти использовался защищенный режим (линейная адресация)

для EMS на 386 режим v86, даже в DOS, с менеджерами памяти EMM386 и QEMM и др.

почему вы не хотите использовать поиск с ИИ ?

Я много писал кода на SIMD. Читаю тут бред от дилетанта, что даже близко не знает о чём заявляет.

Работать - будет
использовать свои возможности на полную - нет

Вот эта заява просто лютый бред, он не может работать на 128 бит, он всегда на 256. И если ОС не будет сохранять все 256 бит SIMD регистров, то при наличии двух потоков использующих AVX - их данные могут перемешаться. Или даже если просто на другое ядро поток перескочит. Он или работает - или нет, 128-бит это SSE, AVX не может работать на 128 бит.

На 32-битной ОС нет поддержки 256-битности регистров YMM

Вся поддержка нужная от ОС - это сохранять SIMD регистры при переключении потоков.

Например, Windows 7 32/64-бит поддерживает AVX начиная с SP1. Как и Линукс начиная с 2.6.30 будет поддерживать, битность тут ни при чём вообще. И это ваш ИИ говорит, между прочим. Которым вы другим советуете использовать, а сами пишете чушь про 128-бит AVX.

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

ширина данных узкое место ??
и в какой прикладной задаче требуется постоянно использовать 128битное пространство чисел ?? :)
будет потребность - будет процессор.

Нет, ни в какой. Шина данных точно не лимит сейчас.

Единственный лимит по шине с которым я сталкивался был на шине ISA. Но эта шина ни для чего важного не используется.

хз, но вродеб до сих пор используется как шина датчиков мат.платы.
лимит по шине прекрасно обходится пересылкой данных за два такта :)

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

https://www.securitylab.ru/news/540409.php

это имелось ввиду?

https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit

Я понял что имелось в виду, в 32-бит режиме предусмотрено лишь 8 регистров, в amd64 увеличили количество адресабельных регистров в системе команд до 16. Это касается любых регистров, базовых и SIMD (XMM/YMM/ZMM). Пользователь Sylvia где-то когда-то это прочитал, и так как вообще не разбирался ни в каких SIMD, то и запомнил что «наполовину». А теперь утверждает что AVX будет работать как 128 бит. SSE наверное тогда на 64 бита, MMX на 32 бита, а базовые регистры на 16-бит (в 32-бит режиме). Наверное и float в 32-бит режиме короче.

Я когда-то с Хабра ушел, потому что на нём вместо технически грамотных специалистов - стало больше людей что крутятся в около-IT, но ни разу не специалисты. Эффективные менеджеры и работники отдела кадров. И когда ты возражаешь на их заявления в вопросе в котором они не разбираются - а ты хорошо разбираешься, они начинают тебя минусовать толпой. Похоже у ЛОР скоро будет такая же участь.

Дк это везде… Ну и возраст даёт знать)

Объективно, экспертиза в технических вопросах не стоит, что-то уходит в «архив». Единственное, что все повторяется.

на Эльбрусе можно собирать с -m128, получатся 16байтные указатели

вроде как достаточно в LDT описание сегментов поменять

и там теперь тоже отвечает ИИшница. Остаётся только yandex.md/uz, (те регионы, в которую алису не завезли)

на Эльбрусе можно собирать с -m128, получатся 16байтные указатели

Поэтому некоторые объявляют его 128-битным, но это не так. Это указатель (64-бит) к которому дополнительно указывается размер области памяти (32-бит) и позицию (32-бит) в ней. Адрес остаётся 64-битным, и вся арифметика тоже.

да, я в курсе что адрес там не 128битный. но это один из примеров где sizeof(void*) > 8

sizeof(void*) = 16 sizeof(intptr_t) = 8

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

Разрядность всегда является характеристикой оборудования, и если более точно, то характеристикой размера одного адресуемого слова.

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

Это можно отключить: https://duckduckgo.com/settings#aifeatures

Ну ещё есть SearX. Но не всем он подойдёт.

Пользователь Sylvia где-то когда-то это прочитал, и так как вообще не разбирался

Sylvia - не он, а она, если ты давно на лор, мог бы и знать