История изменений

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

Замечательно. 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, но ты считаешь, что этого уже мало. Наверное с тобой ещё не посоветовались.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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