32 бита, 64 бита, а почему не между ними?

Что именно я потеряю? Пямять, производительность?

Всё, абсолютно. Потому что абсолютно всё сейчас привязано к степеням двойки.

Ну так ты ровно о таких потерях, но в железе и говоришь

Нет. Это будут потери сверху. Не вместо, а вместе. Ну и главное, что бОльшая часть данных либо выравнена автоматически (указатели, int64 переменные, и т.д.), либо выравнивание занимает там мизерную часть (размер структуры 255, выравнивается на 256, потеря 0.25%). А теперь представим, что значительная часть полей структуры — 64битная, для твоего проца все эти поля надо будет выравнивать на 96бит, потеря 50%. Всё становится ещё веселее, если вспомнить про аппаратную потерю, что твой int96 храниться и передаваться будет, как инт 128. Вот они и есть, потери 50% памяти.

Кроме какого-то совсем уж системного софта никто ничего руками не подгоняет

Да ладно, там сям есть зарезервированные поля, во-первых, мало ли пригодиться, во-вторых, заодно и выровнено будет.

Просто перешли на IBM 360

Просто выкинули старое железо и переписали весь софт. Я об этом с самого начала и твержу, что твоё предложение именно к этому и сводится.

Интересно послушать мнение зрительного зала обо всём этом.

Ты агитируешь за модернизацию «битных древностей», в то время, когда новые технологии и архитектуры «шагают семимильными шагами», например, уже сотворили чип из двумерного MoS2 толщиной в три атома, объединяющий процессор и память в одной архитектуре «logic in memory» ©.

Статья первоисточник (PDF). Ежели оно «взлетит», то фон Нейман будет низвергнут в тартарары и битность можно будет программировать «лёгким движением руки».

а уровне контроллера оперативки в процессоре 64-битной адресации тоже не, например, i7-5820K поддерживает не больше 64 Гб оперативы (36 бит). Как раз из-за вопросов кэша.

Поправлю, что скорее из-за контролера памяти или даже настроек биоса. Так как в некоторых материнках он и 128 Гб поддерживает.

Ещё неизвестно кто из нас сынок

В моей деревне не было ни одного программируемого калькулятора, куда уж там спектрумы всякие. Но выпуски «науки и жизни» с статьями по программированию на калькуляторе и бейсиках храню до сих пор.

Зависит, сколько адресных линий физически разведено на материнке. Правда, не знаю, насколько это релевантно к интелам и вообще новым процам. Но все АМД поколения К10.5 имело (включая атлоны и семпроны)) тот же контроллёр памяти, что и оптероны. То есть, в зависимости от материнки, твой дешёвский семпрон мог поддерживать как 4, так и 64 гига оперативы, сколько производитель решит сделать максимумом. Ну и бонусом шла поддержка ЕСС абсолютно во всех моделях.

У меня для более старой материнки с lga2011 на X79 процессоры поддерживали 64Гб максимум. В 2014-м вышел биос (последний, новее уже не было), который стал поддерживать 128Гб. Но для 128 Гб нужны 16Гб модули DDR3. Таких в 2011-м году вроде еще не было.

Задумайтесь, как часто ваши программы работают с числами больше одного триллиона? А больше 281 триллиона? Однако ненужные биты, старше 40-го или 48-го, обычно не несущие никакой полезной информации, обрабатываются во всех арифметико-логических операциях.

Что-то мне подсказывает, что такие программы крутятся непрерывно, хотя и не занимают большого процента всех вычислений. Шифрование же ж всего и вся. Если проц (и шина памяти, кстати да!) будет 40-48 бит, то лишними окажутся эти 8-16 бит, тк блоки шифрования обычно 32-64-128 битные.

64 бита должно хватать всем. Кому не хватает, использует специализированные сопроцессоры, например GPU.

Кому не хватает 64 бита на адрес, где они?

<можно всякую фигню> сократить на треть или на четверть

Дай угадаю, тебе всегда было непонятно, почему спички такие длинные делают?

Интересно послушать мнение зрительного зала обо всём этом.

Учиться тебе надо барин, потом писать.

Инкремент, сдвиг влево на три бита и прибавление адреса внутри блока смещения врядли будет более эффективно, чем просто прибавить 8 или 6 соответственно.

ЯННП, что ты написал. Сдвиг влево на три бита и прибавление адреса вообще не занимают времени, это просто провода.

А теперь представь, что в твоей системе несколько тысяч ядер. Лет через 10 - 15 так и будет. Представь, что 25% процентов каждого ядра обычно простаивает или занято бесполезной работой.

Во первых на массовых ПК.так не будет.

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

Я думаю что в универсальных CPU будет оптимизироваться не столько вычислительная, сколько управляющая часть, например пользователям разрешат делать свои микропрограммы для cisk процессоров, управляющая часть умеющих в это ядер будет иметь упращённую управляющую часть что бы она ссответствовала тем микропрограммам, выполнением которых она будет управлять.

Экономия на спичках не нужна, тем более, что 64 бит прекрасно работает. Уже. Работает.

Погуглите разницу между логическим и физическим. Современные процессоры хрен там прожуют 18 экзабайт оперативки. И дело даже не в контроллере памяти, там шина адреса не 64-битная. Так же было и в 32-битные времена, самые ранние 32-бит процессоры не способны были 4 гб адресовать, у них шина адреса 23 бита была. А до этого тоже самое было в 8088, знаменитое ограничение в мегабайт формировалось 20-битной шиной.

Так что то, что вы хотите - применяется чуть ли не с начала времён.

Регистры удобнее было делать кратными предыдущим.

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

Потому что число бит в машинных словах должны удваиваться для эффективной упаковки и если ты хочешь двовйное машинное слово в 48 бит то одинарное машинное слово должно быть 24 бит, что в общем случае довольно мало.

один терабайт адресного пространства

Серверы с терабайтом только памяти - уже обыденность.

Этого точно должно хватить всем

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

Если этого мало, то битность может быть 48 бит - такая же, как битность LBA адресов у дисков

Ну полка на 24 16Tb дисков - тоже обыденность, и обычное дело замаппить всё это в память.

Т.е. 48 бит адресного пространства УЖЕ мало.

Задумайтесь, как часто ваши программы работают с числами больше одного триллиона? А больше 281 триллиона?

Мои - работают. Ещё они работают с double и копируют память simd’ом.

Преимуществом будет значительное упрощение схемы ядра

Не будет. Умножить на 64 - это один сдвиг, умножить на 48 это два сдвига и сложение. Всё что высчитывает адреса и смещение значительно усложнится. Я даже не говорю о такой чуши как 40 бит.

которого станет либо автоматически больше (в пересчёте на машинные слова по 40 или 48 бит),

При переходе с 32 на 64 была, реально размер кода вырос не больше чем на 15%. Ты предлагаешь сэкономить лишь часть от этого (при этом намного меньше половины, потому что из-за выравнивания упаковать смешанные 32 и 48битные значения эффективно не получится), т.е. около 5%, ценой создания полностью новой архитектуры, которая на данный момент уже устарела бы и всё равно бы потребовала перехода на 64бита. Молодец. Даже у сраных капиталистов которым это было бы ну просто не пересказать как выгодно, этот трюк провернуть не получилось, настолько он очевидно неэффективный.

Даже производительность базовых арифметических операций, то есть производительность блока АЛУ процессора, должна повысится, за счёт упрощения самих этих операций

Нет. Они в железе и так выполняются за один тик, ничего там не изменится. К слову, ЕМНИП в железе для адресной шины используется не 64 проводника, а меньше - столько, сколько нужно для поддерживаемого платформой объёма памяти. Так что там где это на самом деле рационально, на этом вполне себе экономят.

Дядя, amd64 это не только адресное пространство

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

Дядя, amd64 это не только адресное пространство

Тётя, речь не только об адресном пространстве.

При обработке потокового аудио-видео очень давно не хватало 32 бит и сначала появились 64-разрядные регистры ММХ, затем всякие SSE 128, затем 256, сейчас уже оперируют 512 битами одной командой. Так что сейчас очень многим и 64 бит не хватает!
Автор полностью забыл про 80-битные FPU.
И даже, если хватает 32 бит для кодирования величины, то на 64 разрядном проце их можно обрабатывать по 2 значения одной командой. Т.е. число-дробилка может работать почти в 2 раза быстрее при той же тактовой.

Серверы с терабайтом только памяти - уже обыденность.

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

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

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

Ну полка на 24 16Tb дисков - тоже обыденность, и обычное дело замаппить всё это в память.

Зачем кому-то может понадобится мапить всё это в одно адресное пространство?

Т.е. 48 бит адресного пространства УЖЕ мало.

И как тут уже выяснили это уже предел адресного пространства виртуальной памяти существующих x64 Intel процессоров. То есть опять же, до сих пор нет реальной необходимости его расширят. Иначе давно бы уже расширили.

Мои - работают. Ещё они работают с double и копируют память simd’ом.

double находится в FPU и он 80 бит, то есть вообще не относится к разговору, как и simd. Расскажи лучше для чего тебе больше 48 бит в long long.

Не будет. Умножить на 64 - это один сдвиг, умножить на 48 это два сдвига и сложение. Всё что высчитывает адреса и смещение значительно усложнится.

Арифметику выравнивания адресов с шагом в 6 байт вместо 8 байт легко оптимизировать в железе - фактически оптимизировать инструкцию LEA.

При переходе с 32 на 64 была, реально размер кода вырос не больше чем на 15%. Ты предлагаешь сэкономить лишь часть от этого (при этом намного меньше половины, потому что из-за выравнивания упаковать смешанные 32 и 48битные значения эффективно не получится), т.е. около 5%, ценой создания полностью новой архитектуры, которая на данный момент уже устарела бы и всё равно бы потребовала перехода на 64бита. Молодец. Даже у сраных капиталистов которым это было бы ну просто не пересказать как выгодно, этот трюк провернуть не получилось, настолько он очевидно неэффективный.

Речь шла вовсе не о размере кода, а о размере кеша. Ты занимаешься подменой тезиса, то есть демагогией.

Даже производительность базовых арифметических операций, то есть производительность блока АЛУ процессора, должна повысится, за счёт упрощения самих этих операций

Нет. Они в железе и так выполняются за один тик, ничего там не изменится.

Они выполняются не моментально и поэтому могут влиять на то, как часто эти тики могут происходить.

К слову, ЕМНИП в железе для адресной шины используется не 64 проводника, а меньше - столько, сколько нужно для поддерживаемого платформой объёма памяти. Так что там где это на самом деле рационально, на этом вполне себе экономят.

Да, 48, но ты считаешь, что этого уже мало. Наверное с тобой ещё не посоветовались.

При обработке потокового аудио-видео очень давно не хватало 32 бит и сначала появились 64-разрядные регистры ММХ, затем всякие SSE 128, затем 256, сейчас уже оперируют 512 битами одной командой. Так что сейчас очень многим и 64 бит не хватает!

Это всё относится к SIMD, то есть к обработке нескольких значений из потока при помощи одной инструкции, а не к величене отдельного значения. К слову про 512 бит: «I hope Intel's AVX-512 'dies a painful death'». Помнишь, кто это сказал?

Автор полностью забыл про 80-битные FPU.

Совсем не забыл. Автор так же не забыл, что речь вовсе не об FPU и не о числах с плавающей точкой.

И даже, если хватает 32 бит для кодирования величины, то на 64 разрядном проце их можно обрабатывать по 2 значения одной командой. Т.е. число-дробилка может работать почти в 2 раза быстрее при той же тактовой.

Только беззнаковые и только, если ты гарантируешь невозможность переполнения. Почти весь кровавый энтерпрайз сидит на Java, где беззнаковых целых нет в принципе, ну кроме char, который для арифметики всё равно не используется.

double находится в FPU и он 80 бит

Удивительная комбинация самомнения и невероятных провалов в знаниях.

И вновь переход на личности, то есть ничего удивительного.

Непонятно, чего ты хочешь. Тебе накидали вариантов, почему 64, а не 48, а ты вместо того, чтобы подумать и предметно погуглить, начал спорить. Поспорь с разработчиками архитектуры, чего уж.

Арифметику выравнивания адресов с шагом в 6 байт вместо 8 байт легко оптимизировать в железе

Пробовал, или теоретик?

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

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

Так твоя манера обсуждения больше похожа на метание какашек в оппонента, сам виноват.

Это не моя манера обсуждения, а манера обсуждения тех, кому я вынужден тут отвечать. Вот и тебе я вынужден отвечать на выпады в сторону моей личности. Уймись уже.

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

Уймись уже.

Вот опять. Изи, чувак!

— У тебя зияющие провалы в базовых знаниях в области, в которой ты пытаешься создать «инновации».
— Ты переходишь на личности! Ой, всё! Я обиделся.

В какую из твоих тем не загляну, везде твои собеседники якобы переходят на личности. Конечно, я не заглядывал во все темы. Может, остальные не такие. Это, кажется, третья, в которую я заглядывал. И во всех тебя обижают. Выглядит это примерно так. Ты что-то вилами на воде пишешь, тебе указывают на несостоятельность доводов, ты обижаешься.

Возможно, ты настолько предельно корректный и тактичный человек, что любой шаг в сторону ты уже воспринимаешь как личное оскорбление. То есть, существует «правильное» поведение, и поведение всех остальных. Ну так вот. Представим ситуацию. Некий индивид приходит на форум и создаёт тему со своими фантазиями на тему развития микропроцессорной техники. Он предлагает уменьшить ширину машинного слова, намекая на какие-то преимущества. В процессе обсуждения выясняется, что часть базовых знаний в области у него отсутствует, а часть вызывающе ошибочна. Как в такой ситуации правильно сообщить такому индивиду, что его компетентность в области слишком низкая, и что его суждения в ней не стоят и ломанного гроша?

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

Они из вариантов? А их много? Их всего три - 40, 48 и 56. 40 мало для физической памяти, остаётся два. 56 с ещё большими проблемами с выравниванием и вообще невидимой глазу экономией ты серьёзно рассматриваешь? Значит вариант всего один - 48 бит.

Ну если это твой главный аргумент

Как можешь видеть, это не главный аргумент. Давно подмеченная особенность русскоязычных IT форумов - люди без какого бы то ни было понимания темы и вообще умения логически мыслить вместо того чтобы задать вопрос, получить ответ и стать умнее считают что имеют право вступать в споры, а потом ещё прикрываться аргументом про переход на личности.

Зачем кому-то может понадобится мапить всё это в одно адресное пространство?

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

И как тут уже выяснили это уже предел адресного пространства виртуальной памяти существующих x64 Intel процессоров. То есть опять же, до сих пор нет реальной необходимости его расширят. Иначе давно бы уже расширили.

Во-первых, мир не ограничен ни существующими, ни intel процессорами. Во-вторых нет такого предела, читай: https://en.wikipedia.org/wiki/Intel_5-level_paging и плюнь в рожу тому кто тебе наврал. Я не из головы выдумал mmap огромных файлов - я видел хранилище которое так и делает, причём максимально дёшево и эффективно. Пятиуровневая адресация, большие страницы, полпетабайта места на обычных HDD, совсем немного, на самом деле, RAM и максимально простой форкающийся код, и всё это кормит сумасшедший поток вычислительным нодам, потому что они часто запрашивают одно и то же, а оно уже есть в памяти и хранится там ровно один раз, а новые запросы хранилище умеет хорошо предугадывать и madvise’ом поднимать с дисков.

double находится в FPU и он 80 бит, то есть вообще не относится к разговору, как и simd.

В FPU double обрабатывается, а хранится в памяти. Как 64 бита. 80 бит - это long double, и ему твои 48 бит тоже никак не помогут. Simd используется для быстрого копирования памяти, и копировать по 48 бит на четверть медленнее чем по 64 бита, так что отношение имеет прямое.

Расскажи лучше для чего тебе больше 48 бит в long long.

У тебя фантазии не хватает? Только навскидку - fixed point вычисления, битовые маски, хэши, состояние rng, счётчики трафика, epoch time в микросекундах, ipv6 из двух половинок, криптография.

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

Арифметику выравнивания адресов с шагом в 6 байт вместо 8 байт легко оптимизировать в железе - фактически оптимизировать инструкцию LEA.

Что ты собрался оптимизировать, при чём тут LEA? 6 вместо 8 это всегда 2 сдвига + сложение вместо одного сдвига. Всегда и везде. Адреса вычисляются не только в LEA, а вообще на каждый чих, иногда по несколько раз.

Речь шла вовсе не о размере кода, а о размере кеша.

Размер кэша не меняется, меняется размер данных, потому то 48 бит меньше 64. Но в чистом виде эту разницу можно увидеть только на числодробилках и там если данные влезают в 48 бит, то да - на 48битной платформе выиграем четверть памяти и пропускной способности шины/кэша. Если не влезают, то в полтора раза проиграем. Причём, если уж мы упираемся именно в память/шину, то и на 64 платформе мы можем упаковать значения в 48 бит почти без потери производительности, так что 48 даже в этом вырожденном случае ничего сильно не экономят.

Но такие числодробилки это именно что вырожденные случаи, а в среднем, как уже было сказано, не будет от 48бит вместо 64 выигрыша больше 5% ни по какому параметру.

Они выполняются не моментально и поэтому могут влиять на то, как часто эти тики могут происходить.

Читай чем ограничена частота в современных процессорах.

Да, 48, но ты считаешь, что этого уже мало. Наверное с тобой ещё не посоветовались.

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

Тебе выше все уже разжевали.