LINUX.ORG.RU
ФорумTalks

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

 , , , ,


0

2

Помните, когда-то наши процессоры были 32-х битными и этого в общем-то хватало, хотя иногда не хватало. Затем произошёл переход на 64 бита данных и адресного пространства. Казалось бы, вот она цифровая благодать, 64 бита должно хватать всем. Кому не хватает, использует специализированные сопроцессоры, например GPU. Однако гонка мегагерцев закончилась, скоро закончится и гонка размера транзисторов. Куда расти дальше? А дальше путь лишь один - параллельные вычисления, многоядерность и многопроцессорность. Однако для этого ядро процессора не должно быть избыточным, а 64 бита - явно слишком много. Почему бы не перейти на какой-то промежуточный вариант битности, больший 32, но меньший 64? Пусть битность всё ещё будет кратной восьми, но всё таки не будет степенью двойки. Например она может быть 40 бит, что даёт один терабайт адресного пространства и аналогичный диапазон значений регистров данных. По-моему этого должно хватить почти всем. Если этого мало, то битность может быть 48 бит - такая же, как битность LBA адресов у дисков. Это уже 256 терабайт. Этого точно должно хватить всем. Преимуществом будет значительное упрощение схемы ядра, уменьшение необходимого числа транзисторов и прочих элементов, улучшение кеша, которого станет либо автоматически больше (в пересчёте на машинные слова по 40 или 48 бит), либо его размеры в чипе можно будет сократить на треть или на четверть (при сохранении того же объёма в пересчёте на машинные слова новой битности). За счёт такого упрощения будет легче и дешевли создавать многоядерные и многопроцессорные системы. Даже производительность базовых арифметических операций, то есть производительность блока АЛУ процессора, должна повысится, за счёт упрощения самих этих операций. Задумайтесь, как часто ваши программы работают с числами больше одного триллиона? А больше 281 триллиона? Однако ненужные биты, старше 40-го или 48-го, обычно не несущие никакой полезной информации, обрабатываются во всех арифметико-логических операциях.

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

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

★★★★★

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

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

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

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

anonymous2 ★★★★★ ()
Последнее исправление: anonymous2 (всего исправлений: 1)

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

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

Harald ★★★★★ ()

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

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

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

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

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

 ▲ ~ cat /proc/cpuinfo|grep address\ sizes
address sizes   : 43 bits physical, 48 bits virtual
hateyoufeel ★★★★★ ()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от anonymous2

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от Harald

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

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

bbk123 ★★★★★ ()

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

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

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

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

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

byko3y ★★★★ ()
Ответ на: комментарий от bbk123

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

2^5=32, 2^6=64

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

anonymous2 ★★★★★ ()
Последнее исправление: anonymous2 (всего исправлений: 2)
Ответ на: комментарий от anonymous2

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

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

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

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

n_play ()
Ответ на: комментарий от anonymous2

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

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

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

n_play ()
Последнее исправление: n_play (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

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

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от anonymous2

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

2^5=32, 2^6=64

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


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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

Вот это панч!

reprimand ★★★★★ ()
Ответ на: комментарий от byko3y

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

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

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

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

quickquest ★★★★★ ()
Ответ на: комментарий от quickquest

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

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

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

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

bbk123 ★★★★★ ()

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

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

gremlin_the_red ★★★★ ()
Ответ на: комментарий от hateyoufeel

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

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

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

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

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

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

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

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

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

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

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

bbk123 ★★★★★ ()
Последнее исправление: bbk123 (всего исправлений: 2)

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

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

deep-purple ★★★★★ ()

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

nvidia ()
Последнее исправление: nvidia (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red

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

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


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

bbk123 ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

bbk123 ★★★★★ ()

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

hobbit ★★★★★ ()
Ответ на: комментарий от Puzan

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

gremlin_the_red ★★★★ ()
Последнее исправление: gremlin_the_red (всего исправлений: 2)
Ответ на: комментарий от bbk123

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

Puzan ★★★★★ ()
Последнее исправление: Puzan (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red

Потому что всё очень сильно завязано на степени двойки. В этом плане переход с 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 в этом проекте?

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

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

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

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

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

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

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

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

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

hateyoufeel ★★★★★ ()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от Puzan

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

Puzan ★★★★★ ()
Ответ на: комментарий от hateyoufeel

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

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

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

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

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

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

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

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

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

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

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

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

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

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

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

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

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

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

hateyoufeel ★★★★★ ()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от Puzan

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

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


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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

Любой 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

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

gremlin_the_red ★★★★ ()
Ответ на: комментарий от hateyoufeel

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

Или нет? Потому что она довольно ресурсоёмка и её стоит ускорять в первую очередь. Или ты думаешь 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 вполне может жить в отдельном ядре, как раз потому, что большую часть времени эта функциональность простаивает и тащить её во все ядра никакого смысла нет, от слова вообще.

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

gremlin_the_red ★★★★ ()
Ответ на: комментарий от bbk123

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

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

000
001
010
011
...

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

001 000
001 001
...
001 101
001 110

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

Puzan ★★★★★ ()
Последнее исправление: Puzan (всего исправлений: 1)
Ответ на: комментарий от gremlin_the_red

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

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

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

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

bbk123 ★★★★★ ()

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

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

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

Toxo2 ★★ ()
Ответ на: комментарий от bbk123

Процессор внутри себя полноценно 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 байта (не бита) тридцать лет назад, так и остается.

byko3y ★★★★ ()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от bbk123

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

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

Puzan ★★★★★ ()
Ответ на: комментарий от Puzan

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

bbk123 ★★★★★ ()
Последнее исправление: bbk123 (всего исправлений: 1)
Ответ на: комментарий от bbk123

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

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

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

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

gremlin_the_red ★★★★ ()
Ответ на: комментарий от gremlin_the_red

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

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

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

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

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

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

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

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

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

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

bbk123 ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)