История изменений
Исправление gremlin_the_red, (текущая версия) :
Зачем что-то выкидывать?
Потому что всё очень сильно завязано на степени двойки. В этом плане переход с 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, :
Зачем что-то выкидывать?
Потому что всё очень сильно завязано на степени двойки. В этом плане переход с 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, :
Зачем что-то выкидывать?
Потому что всё очень сильно завязано на степени двойки. В этом плане переход с 32-бит на 64 был фактически незаметным — шина памяти ещё со времён Pentium была 64-битной, кэш уже тогда использовался только линиями по 64-128 байт, то есть он просто стал содержат меньше строк. Размер страницы памяти DRAM уже был не меньше 512 байт и т.д. и т.п. А ты теперь это всё предлагаешь либо выкинуть на помойку, либо смириться с потерей 25% (я тут рассматриваю только вариант с 48битностью, как простой для расчётов) кэша, памяти и I/O.
старый софт тоже
У меня в проекте 1999го года уже использовалась int64 арифметика, потому что в int32 уже не помещалось. Без тщательного анализа кода я не поручусь, что она станет работать с заменой int64 на int48. То есть, далеко не факт, что после перекомпиляции на int48 она не станет падать в рандомных местах. А чтобы эта прога заведомо заработала без перекомпиляции, твой 48битный проц должен работать с int64 арифметикой, как с int96, а так как он сам внутри 48-битный, то это выливается в дикий оверхед по количеству инструкций, забиванию кэша и т.д.