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

зачем об этом думать? какая разница младшие или старшие биты регистров использует чаще твоя программа?

Почему бы не перейти на какой-то промежуточный вариант битности, больший 32, но меньший 64?

потому что в уже детском саде знают, что 48бит это 6 проводов и 64бит это тоже 6 проводов… получаем максимум за теже деньги

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

Для криптографии чем больше битность, тем лучше

39 бит ептыть

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

Много для кого?

Почему бы не перейти на какой-то промежуточный вариант битности, больший 32, но меньший 64?

А зачем? Для ALU 64 бита – вполне ок.

Да, к слову, в процессорах адреса на самом деле не совсем 64-битные. У первых AMD64 адреса вообще 36 бит были, если память не изменяет.

 ▲ ~ cat /proc/cpuinfo|grep address\ sizes
address sizes   : 43 bits physical, 48 bits virtual

зачем об этом думать? какая разница младшие или старшие биты регистров использует чаще твоя программа?

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

потому что в уже детском саде знают, что 48бит это 6 проводов и 64бит это тоже 6 проводов… получаем максимум за теже деньги

Как ты получил 6 проводов?

Для криптографии чем больше битность, тем лучше

Криптография на разрядность процессора вовсе не завязана.

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

64 бита есть только на уровне инструкций проца. Но как ты на этом уровне собрался решать, сколько бит нужно, а сколько — не нужно? В FPU есть и 80-бит так-то. А у тех же ARM-ов параллельные АЛУ в одном ядре имеют разные возможности, потому самые сложные операции делаются на главном АЛУ, а более простые параллелятся. Или возьми видеокарточки, где вычисления с половинной точностью выполняются ровно в два раза быстрее вычислений с одинарной — потому что на том же вычислителе запускается два вычисления за такт.

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

На том же x64 никуда не девались операции над одно-, двух-, и четырехбайтными числами. AArch64 дает меньше выбора, у него большая часть операций либо над 32-битами, либо над 64. Есть только отдельные инструкции для работы с байтами, вроде «считать/записать», но арифметика — минимум 32.

Однако, полноценный умножитель для 64 бит весит сотни тысяч транзисторов, а даже в нищесегменте у ARM десятки миллионов транзисторов — то есть, умножитель особо не отсвечивает.

сколько нужно линий данных чтобы передать 48 бит?

2^5=32, 2^6=64

хотя в вашей параллельной вселенной существуют сумматоры на 48 бит, они все равно максимум оперировать будут с 64 битами.

в параллельной вселенной

чтобы передать 48 бит?

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

если последовательно, то 1 провода хватит

не забудь купить тамже последовательный 1битный процессор… аля убийцу кризисов

почитай уже определение в школьном учебнике что такое «бит»

заодно поймешь почему через 6 проводов у тебя 64 бита не передадутся.

странно что не пятизвездчатый, так-то уже пора

Много для кого?

Для типичного пользователя, даже корпоративного.

А зачем? Для ALU 64 бита – вполне ок.

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

Да, к слову, в процессорах адреса на самом деле не совсем 64-битные. У первых AMD64 адреса вообще 36 бит были, если память не изменяет.

Тем не менее все регистры 64-битные, адресация чипов памяти, к слову, тоже. Ну и если в твоём компьютере и так 43/48 бит физического/адресного пространства, то зачем городить огород с 64 битами?

битность может быть 48 бит

БЭСМ-6: 48 бит ©.

а почему не между ними?

Были и 18, 24, 32, 36 битные ©.

мнение зрительного зала

128 bit CPU

сколько нужно линий данных чтобы передать 48 бит?

2^5=32, 2^6=64

хотя в вашей параллельной вселенной существуют сумматоры на 48 бит, они все равно максимум оперировать будут с 64 битами.

В твоей параллельной вселенной произошла явная путаница байтов с битами. 48 бит - это 48 двоичных цифр, каждое из которых может иметь одно из двух значение - 0 или 1. Соответственно для передачи 48 бит параллельно необходимо 48 линий.

> мнение зрительного зала

128 bit CPU

facepalm.gif

В твоей параллельной вселенной произошла явная путаница байтов с битами. 48 бит - это 48 двоичных цифр, каждое из которых может иметь одно из двух значение - 0 или 1. Соответственно для передачи 48 бит параллельно необходимо 48 линий.

Вот это панч!

Уровень материнской платы вообще неинтересен. Процессор внутри себя полноценно 64-х битный. То есть позволяет работать с виртуальными адресами и реальными данными в этом диапазоне значений. Но реально такой диапазон избыточен и не нужен. Так же избыточно использование памяти. При 64-х битах машинное слово занимает 8 байт, при 48-и битах лишь 6 байт, а при 40-а битах лишь 5 байт. Посчитай на сколько неэкономно используется физическая память. Треть или четверть физической памяти фактически не используется.

Однако, полноценный умножитель для 64 бит весит сотни тысяч транзисторов, а даже в нищесегменте у ARM десятки миллионов транзисторов — то есть, умножитель особо не отсвечивает.

Помимо умножителя (наверное ты имел в виду АЛУ?) там есть ущё куча всего, завязанного на битность. И АЛУ у современных процессоров обычно несколько на ядро. И регистры тоже не на радиолампах собраны и линии связи внутри ядра тоже не последовательные. То есть сокращение разрядности должно сильно упростить ядро и кеш, коих обычно несколько.

Для типичного пользователя, даже корпоративного.

Кто тебе такое сказал? В чём выражается это «много»?

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

Я 10-15 лет назад такое слышал. 10 лет назад у меня в компе было 2 ядра, сейчас — 32. А не несколько тысяч.

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

А так и есть. Читай про dark silicon.

Неужели ты не захочешь его упростить и тем самым увеличить количество ядер на четверть или хотя бы на одну пятую?

Мне почему-то кажется, ты вообще нифига про процессоры не знаешь.

сокращение разрядности

В ЭВМ «МИР-1» © действия могли выполняться с числами произвольной разрядности и произвольной длины. Там двоично-десятичная архитектура была реализована аппаратно.

БЭСМ-6: 48 бит ©

А так же CDC 1604 и некоторые следующие его модели, хотя слухи о заимствовании архитектуры CDC 1604 в БЭСМ-6 считаются заблуждением.

Были и 18, 24, 32, 36 битные ©

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

Например изменение битности почти наверняка приведёт к изменению выравнивания адресов, в нашем случае некратному

В переводе на русский — надо будет выкинуть на свалку абсолютно всё существующее железо и переписать 99% софта.

Для типичного пользователя, даже корпоративного.

Кто тебе такое сказал? В чём выражается это «много»?

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

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

Я 10-15 лет назад такое слышал. 10 лет назад у меня в компе было 2 ядра, сейчас — 32. А не несколько тысяч.

Не знаю от кого ты это слышал, но я точно не имею к этому никакого отношения. 10-15 лет назад о смерти закону Мура ещё в серьёз не говорили, размер транзистора был далёк от считанных атомов и от тех расстояний, на которых начинаются квантовые эффекты. Если за 10 лет количество ядер в твоём компьютере увеличилось в 16 раз, почему через следующие 10 лет их количество вновь не увеличится в 16 раз? Почему через 10 лет не начнут устанавливать несколько процессоров на десктопные материнки? Два таких процессора - это уже 1024 ядра.

А так и есть. Читай про dark silicon.

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

Неужели ты не захочешь его упростить и тем самым увеличить количество ядер на четверть или хотя бы на одну пятую?

Мне почему-то кажется, ты вообще нифига про процессоры не знаешь.

А мне почему-то кажется, что ты просто пытаешься перевести разговор на личности. Наверное из-за отсутствия технических аргументов, то есть тех самых знаний, которых у меня якобы нет.

Помните, когда-то наши процессоры были 32-х битными

Пишу тебе привет с 32 битного десктопа, сынок!

В процессорах и так ради simd и прочего multiple issue «ширина» многих блоков по 256-512бит. Экономить на спичках смысла мало.

Например изменение битности почти наверняка приведёт к изменению выравнивания адресов, в нашем случае некратному

В переводе на русский — надо будет выкинуть на свалку абсолютно всё существующее железо и переписать 99% софта.

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

Пишу тебе привет с 32 битного десктопа, сынок!

Ещё неизвестно кто из нас сынок. Я начинал с 8-и битной Yamaha MSX2 на Z80 и программируемого калькулятора. ;-)

Чтобы количество байт было степенью двойки (на самом деле нет).

Троичную логику и «Сетунь» уже вспоминали?

Чтобы количество байт было степенью двойки (на самом деле нет).

Разве есть реальная необходимость в степени двойки размера машинного слова? Пока ещё никто не смог внятно это объяснить.

Зачем что-то выкидывать?

Потому что всё очень сильно завязано на степени двойки. В этом плане переход с 32-бит на 64 был фактически незаметным — шина памяти ещё со времён Pentium была 64-битной, кэш уже тогда использовался только линиями по 64-128 байт, то есть он просто стал содержать вдвое меньше слов в строке. Размер страницы памяти DRAM уже был не меньше 512 байт и т.д. и т.п. А ты теперь это всё предлагаешь либо выкинуть на помойку, либо смириться с потерей 25% (я тут рассматриваю только вариант с 48битностью, как простой для расчётов) кэша, памяти и I/O.

старый софт тоже

У меня в проекте 1999го года уже использовалась int64 арифметика, потому что в int32 уже не помещалось. Без тщательного анализа кода я не поручусь, что она станет работать с заменой int64 на int48. То есть, далеко не факт, что после перекомпиляции на int48 она не станет падать в рандомных местах. А чтобы эта прога заведомо заработала, да ещё и без перекомпиляции, твой 48битный проц должен работать с int64 арифметикой, как с int96, а так как он сам внутри 48-битный, то это выливается в дикий оверхед по количеству инструкций, забиванию кэша и т.д.

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

Потому что всё очень сильно завязано на степени двойки. В этом плане переход с 32-бит на 64 был фактически незаметным — шина памяти ещё со времён Pentium была 64-битной, кэш уже тогда использовался только линиями по 64-128 байт, то есть он просто стал содержат меньше строк. Размер страницы памяти DRAM уже был не меньше 512 байт и т.д. и т.п. А ты теперь это всё предлагаешь либо выкинуть на помойку, либо смириться с потерей 25% (я тут рассматриваю только вариант с 48битностью, как простой для расчётов) кэша, памяти и I/O.

Любой x86 расчитан на работу и в 16-и битном режиме. А 48 бит кратно 16, то есть всё должно работать не хуже. В любом случае софт работает с DRAM не на прямую, а через кеш.

У меня в проекте 1999го года уже использовалась int64 арифметика, потому что в int32 уже не помещалось. Без тщательного анализа кода я не поручусь, что она станет работать с заменой int64 на int48. То есть, далеко не факт, что после перекомпиляции на int48 она не станет падать в рандомных местах. А чтобы эта прога заведомо заработала без перекомпиляции, твой 48битный проц должен работать с int64 арифметикой, как с int96, а так как он сам внутри 48-битный, то это выливается в дикий оверхед по количеству инструкций, забиванию кэша и т.д.

Ну так нужно провести анализ на предмет переполнения int48. Что за данные у тебя хранились в int64 в этом проекте?

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

Кто тебе такую чушь сказал? В любом софте, где есть шифрование (а сейчас это почти везде), такие большие числа используются. И даже более большие.

10-15 лет назад о смерти закону Мура ещё в серьёз не говорили, размер транзистора был далёк от считанных атомов и от тех расстояний, на которых начинаются квантовые эффекты.

Закон Мура – это не закон, это просто эмпирическое наблюдение. И, да, о нём начали говорить как раз 15 лет назад, когда штеуд обосрался с P4.

Если за 10 лет количество ядер в твоём компьютере увеличилось в 16 раз, почему через следующие 10 лет их количество вновь не увеличится в 16 раз?

Потому что есть физические ограничения на размер процессора.

Почему через 10 лет не начнут устанавливать несколько процессоров на десктопные материнки? Два таких процессора - это уже 1024 ядра.

Уже устанавливают. Есть ATX платы с двумя сокетами. У меня такой комп до недавнего времени был, больше не хочу. Почти весь софт работает с NUMA так, что лучше бы вообще не работал.

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

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

А мне почему-то кажется, что ты просто пытаешься перевести разговор на личности. Наверное из-за отсутствия технических аргументов, то есть тех самых знаний, которых у меня якобы нет.

Тебе кажется. Но аргументы у тебя и правда крайне бредовые.

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

48 бит - это ровно 6 байт. Причём тут переполнения и о каких запрещённых значениях речь? При любой битности возможны переполнения.

48 бит - это ровно 6 байт.

Это вовсе не ровно 110 байт. Ровно было бы 1000 (от 000 до 111).

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

Кто тебе такую чушь сказал? В любом софте, где есть шифрование (а сейчас это почти везде), такие большие числа используются. И даже более большие.

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

Закон Мура – это не закон, это просто эмпирическое наблюдение. И, да, о нём начали говорить как раз 15 лет назад, когда штеуд обосрался с P4.

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

Если за 10 лет количество ядер в твоём компьютере увеличилось в 16 раз, почему через следующие 10 лет их количество вновь не увеличится в 16 раз?

Потому что есть физические ограничения на размер процессора.

Тем не менее образцы таких процессоров уже существуют.

Уже устанавливают. Есть ATX платы с двумя сокетами. У меня такой комп до недавнего времени был, больше не хочу. Почти весь софт работает с NUMA так, что лучше бы вообще не работал.

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

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

На что же тратятся транзисторы, если не на разрядность? Особенно, если речь идёт о RISC процессорах, за которыми, судя по всему будущее.

Тебе кажется. Но аргументы у тебя и правда крайне бредовые.

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

И криптография является лишь малой частью функциональности такого софта.

Или нет? Потому что она довольно ресурсоёмка и её стоит ускорять в первую очередь. Или ты думаешь AES-NI просто так впилили?

Тем не менее образцы таких процессоров уже существуют.

Каких таких-то? Напихать как можно больше ядер на кристалл – не проблема. Напихать ядер, которые бы делали что-то полезное и не тупили – уже сложнее.

На что же тратятся транзисторы, если не на разрядность?

Ты не поверишь…

https://en.wikichip.org/wiki/File:AMD_Zen_2_CCD.jpg

Видишь вот эту здоровенную срань в середине кристалла? Знаешь что это? Это кэш! А ALU и всё, что зависит от разрядности, оно в самих ядрах по краям. Много транзисторов ты перейдя с 64 бит на 48 бит не сэкономишь. Скорее всего, выигрыша не будет вообще.

Особенно, если речь идёт о RISC процессорах, за которыми, судя по всему будущее.

Тебя обманули, чувак. Соррян. За ними было будущее 30 лет назад, но это будущее так и не наступило. Если, конечно, не считать доминирования ARM в мобилках.

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

Обсуждать личности – это самое весёлое на ЛОРе! Так вот, твой аргумент выглядит как будто ты хочешь себе треть члена отрезать чтобы ссать меньше хотелось, а на все аргументы что это не так работает отвечаешь, что раз ты ссышь членом, то его и надо резать.

48 бит - это ровно 6 байт.

Это вовсе не ровно 110 байт. Ровно было бы 1000 (от 000 до 111).

Зачем ты перевёл число бит в двоичное число? В двоичных числах хранятся данные или адреса, а не разрядность, выраженная в кличестве байт. В FPU вообще 80 бит и никому это не мешает.

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

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

Любой x86 расчитан на работу и в 16-и битном режиме. А 48 бит кратно 16

Во-первых, ты путаешь сложение и умножение. Важно не то, что 64=16*4, а то, что 64/4=16. Во-вторых, вопрос КАК работает. 16-битный код не работает в long mode, только в 32битном режиме, при этом, естественно, используется только половина кэша, половина ширины регистров, и т.д. Просто для этого кода на современных процессорах скорость не важное, даже с урезанной скоростью он всё равно работает на порядки быстрее, чем в те времена, когда он писался.

В любом случае софт работает с DRAM не на прямую, а через кеш

Софт может работать, как ему хочется, интерфейс DDR{1-4} не предусматривает хранения страниц иначе, чем по 512-1к-2к байт, и не предусматривает посылки данных иначе, чем 64-битными кусками. Которые в кэш попадают группами по 64-128 байт, откуда уже их читает приложение. Твой гипотетический 48-битный проц при работе с существующей памятью сможет использовать только 75% модуля.

Ну так нужно провести анализ на предмет переполнения int48

Я про это и написал. Ты представляешь себе объём работы по полному аудиту всего существующего кода? А того, у которого исходников не существует?

И криптография является лишь малой частью функциональности такого софта.

Или нет? Потому что она довольно ресурсоёмка и её стоит ускорять в первую очередь. Или ты думаешь AES-NI просто так впилили?

Она далеко не самая ресурсоёмкая, поэтому AES-NI - далеко не единственное расширение инструкций x86, которое туда впилили.

Каких таких-то? Напихать как можно больше ядер на кристалл – не проблема. Напихать ядер, которые бы делали что-то полезное и не тупили – уже сложнее.

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

На что же тратятся транзисторы, если не на разрядность?

Ты не поверишь…

https://en.wikichip.org/wiki/File:AMD_Zen_2_CCD.jpg

Видишь вот эту здоровенную срань в середине кристалла? Знаешь что это? Это кэш! А ALU и всё, что зависит от разрядности, оно в самих ядрах по краям. Много транзисторов ты перейдя с 64 бит на 48 бит не сэкономишь. Скорее всего, выигрыша не будет вообще.

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

Особенно, если речь идёт о RISC процессорах, за которыми, судя по всему будущее.

Тебя обманули, чувак. Соррян. За ними было будущее 30 лет назад, но это будущее так и не наступило. Если, конечно, не считать доминирования ARM в мобилках.

ARM теперь нацелен уже далеко не только на мобилки. Полагаю, что связано это как раз с его лучшей масштабируемостью из за RISC архитектуры - то есть возможностью делать многоядерные процессоры. Всякого рода расширения, например упомянутое тобой выше AES-NI вполне может жить в отдельном ядре, как раз потому, что большую часть времени эта функциональность простаивает и тащить её во все ядра никакого смысла нет, от слова вообще.

Обсуждать личности – это самое весёлое на ЛОРе! Так вот, твой аргумент выглядит как будто ты хочешь себе треть члена отрезать чтобы ссать меньше хотелось, а на все аргументы что это не так работает отвечаешь, что раз ты ссышь членом, то его и надо резать.

Пожалуй это самый бредовый твой аргумент до сих пор. Ну что же, буду считать тебя специалистом по членам, раз ты так хочешь продолжать обсуждение личностей. Членовед :-)

Что за данные у тебя хранились в int64 в этом проекте?

Хороший вопрос, рад что ты его задал. Я проводил определённые математические манипуляции с данными, получаемыми из внешнего источника. 20 лет прошло, я не могу сказать, насколько большими они могли быть по ТЗ. Из пары формул могу сказать только, что из 40 бит они выходили 100%.

Зачем ты перевёл число бит в двоичное число? В двоичных числах хранятся данные или адреса, а не разрядность.

Я пытался кратко, но ты не догоняешь. Такой вот пример: ты адресуешь память 48-битными словами:

000
001
010
011
...

Теперь тебе нужно обратиться к байту в слове 001, и ты прибавляешь три бита справа:

001 000
001 001
...
001 101
001 110

Упс, а последнего адреса-то не существует! Что делать будешь?

Софт может работать, как ему хочется, интерфейс DDR{1-4} не предусматривает хранения страниц иначе, чем по 512-1к-2к байт, и не предусматривает посылки данных иначе, чем 64-битными кусками. Которые в кэш попадают группами по 64-128 байт, откуда уже их читает приложение. Твой гипотетический 48-битный проц при работе с существующей памятью сможет использовать только 75% модуля.

Ну а что происходит сейчас, когда твоя программа читает структуры, размер которых не кратен размеру DRAM страницы или двойке в какой-то степени? Кто-то сразу кричит караул и что это неэффективно? По умолчанию C++ компилятор выравнивает адреса полей класса, то есть опять же неэффективно, по объёму, использует память. Кому-то это мешает? Я говорю о переходном периоде. Со временем появится и новая память с другим размером страницы. Новая память, той или иной архитектуры, по любому появится, то есть нет смысла так сильно привязываться к старой памяти.

Я про это и написал. Ты представляешь себе объём работы по полному аудиту всего существующего кода? А того, у которого исходников не существует?

Я представляю себе новую архитектуру, на которую просто будут переползать из-за её более высокой производительности при той же цене. Уменьшения разрядности уже случались, например в IBM 7090 машинное слово было 36 бит, а в более позднем IBM 360 уже лишь 32 бита и дальше к 36 битам уже не возвращались.

Была (есть?) такая СУБД HyTech. Я из неё данные доставал однажды. Прям руками, сам себе «драйвер» и сам себе «угадай структуру». Так вот она хранила целые в 24 битах. Было весело )

Поскольку она родом откуда-то из 80-х (и, кажется, из МИФИ), то вполне возможно изначально она была под аппаратные 24 бита создана. Мне так думается. Но подтверждения не находил. Просто из соображений - а зачем иначе-то?

Сейчас Гугл выдаёт только вот это: https://tyvik.ru/posts/hytech-sonar-plus/ но там ничего не пишет человек про архитектуру.

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

Вопиющее 4.2:

https://en.wikipedia.org/wiki/64-bit_computing#Limits_of_processors

Почти все современные x64 процессоры имеют 48 бит виртуального адреса и четырехуровневую трансляцию адресов. Только отдельные AMD64 имеют пятиуровневую трансляцию и 52 бита.

Размер физического адреса еще меньше, но он сильно плавает от проца к процу.

При 64-х битах машинное слово занимает 8 байт, при 48-и битах лишь 6 байт, а при 40-а битах лишь 5 байт. Посчитай на сколько неэкономно используется физическая память. Треть или четверть физической памяти фактически не используется

На x64 инструкция не занимает 64 бита. Ровно как никто не заставляет тебя хранить данные в 64-битных числах. Тот же PostgreSQL в 32-битной сборке и в 64-битной сборке показывает околонулевую разницу используемой памяти. Потому что большая часть структур данных имеет фиксированный размер, не меняющийся от битности.

С другой стороны, тот же Delphi оч неэффективно использует память на 64-битах, это правда. Там даже не в полтора, а почти в два раза больше размер исполняемого файла и потребляемой оперативы.

Помимо умножителя (наверное ты имел в виду АЛУ?)

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

разрядности должно сильно упростить ядро и кеш, коих обычно несколько

Кэш и вовсе агностичен по отношению к битности. Кэш-линия как была 64 байта (не бита) тридцать лет назад, так и остается.

Ну так говори в чём причина

Кратко: в совместимости. В т.ч. в совместимости с данными.

Пямять адресуют побайтово. Ты просто пытаешься сделать выравнивание по слову. В 64-х битной архитектуре тебе нужно прибавлять 8, а в 48-и битной архитектуре нужно прибавлять 6. Инкремент, сдвиг влево на три бита и прибавление адреса внутри блока смещения врядли будет более эффективно, чем просто прибавить 8 или 6 соответственно.

Ну а что происходит сейчас, когда твоя программа читает структуры, размер которых не кратен размеру DRAM страницы или двойке в какой-то степени?

Ещё раз, для тупых — при чём здесь софт? Ты просто аппаратно потеряешь 25% сходу, и софт с этим ничего поделать не сможет. Добавит дополнительных потерь уже сам софт, который, как ты верно заметил, тоже не особо экономно использует память (что, впрочем, пофигу, потому что потери на выравнивание составляют доли процента). Добавит их куда больше, чем сейчас, потому что подгонять размеры структур под 64 бита программисты уже привыкли, а под новую реальность придётся перепроектировать все структуры и переписать весь код, а пока это не будет сделано, старое выравнивание сожрёт ещё 33% рамы. Итого начинать «конкурировать» твоя архитектура будет с позиции «прям щаз и на следующие несколько десятилетий ты можешь забыть о половине своей памяти, зато потом можно будет сэкономить 1% транзисторов».

Уменьшения разрядности уже случались, например в IBM 7090 машинное слово было 36 бит, а в более позднем IBM 360

Чё как там с аппаратной и программной совместимостью было, не напомнишь? Я ещё маленький был просто.

Ещё раз, для тупых

Фильтруй базар.

Ты просто аппаратно потеряешь 25% сходу, и софт с этим ничего поделать не сможет.

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

потери на выравнивание составляют доли процента

Ну так ты ровно о таких потерях, но в железе и говоришь. Значит доли процента или больше?

потому что подгонять размеры структур под 64 бита программисты уже привыкли, а под новую реальность придётся перепроектировать все структуры и переписать весь код, а пока это не будет сделано, старое выравнивание сожрёт ещё 33% рамы.

Кроме какого-то совсем уж системного софта никто ничего руками не подгоняет. Компилятор выравнивает, а если встретит что-то типа #pragma pack, то и этого делать не будет.

Чё как там с аппаратной и программной совместимостью было, не напомнишь? Я ещё маленький был просто.

Я тоже не на столько стар. Что было? Просто перешли на IBM 360 из-за более высокой производительности. Совместимость интересовала куда как меньше. Или вот более поздний пример, переход Apple на интелловские процессоры и наметевшийся отказ от них в пользу ARM в недалёком будущем.