Потери при выравнивании.

[Aether]

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

Заметил вот какую вещь: некоторые виды данных, как бы недоиспользуют вычислительные ресурсы. Например, видеоданные, в большинстве случаев представляются массивами RGB, где каждый цветовой компонент представлен восемью битами. Таким образом, в сумме это представляется как 24бита, но ближайший размер регистра (условно), способный поглотить этот объём - 32бита. Отсюда, делаю вывод: либо усложнять алгоритм упаковки, то есть первым заходом считываю RGB первого пикселя плюс R от второго, потом, вторым заходом считываю GB второго и RG третьего. Либо просто храню данные в выровненном по границе двойного слова виде, заполняя старшие 8бит - нулями. В обоих случаях не выходит оптимума: первое ведёт к потери во времени, второе к потери в объёме затрачиваемой памяти.

Подобные рассуждения касаются не только видео, но и других типов информации: работая с оцифровкой аналоговых данных, часто 8бит - мало, а 16бит - много. В общем случае, имело бы смысл задуматься о том, что разрядность архитектуры для плотной компоновки должна иметь численно наибольшее число делителей нацело. Отсюда, непонятно: почему, исторически было выбрано развитие в линейке 4-8-16-32-64 бит? Не было бы более логичным, например, предложить 48бит архитектуру?

[RXL]

Не было бы более логичным, например, предложить 48бит архитектуру?

Значение двойки в степени. В цифровой электронике проще оперировать именно такими числами. Например, в гипотетической 48-битной системе адрес n-го элемента в списке находится умножением, а в нормальной системе - статическим сдвигом.
48 не подходит, но можно 2-битную замутить.

[Aether]

Если так, то как быть, например, с 286, если мне память не изменяет, то адреса там 24бит. Ну и про пень тоже стоит вспомнить - адреса 36бит. Производить вычисления сдвигом можно в любой двоичной системе.

Добавлено через 5 минут и 20 секунд:
А 2 битную то зачем??? Увеличение разрядности ША позволяет адресоваться к большему объёму памяти/портов... Увеличение ШД позволяет увеличить объём вычислений за 1 такт - тоже понятно.

[Sla]

Потому что 48 бит плохо сдвигаются.
Нужен "байтовый" сдвиг, в том числе и адресном пространстве.
Добавление только одного "домена" это умножение на 2
8 бит мало, а 16 - уже на уровне помех
Потому и ЦАП/АЦП многоразрядные(от 16) - это сверхточные , прецизионные схемы.

[Aether]

Можно привести пример?

Возможно, непонимание происходит от того, что Вы исходите: адрес соответствует байту, как в х86. То есть:
mov al, byte ptr [500] - считать в al значение из адреса 500.
mov ax, word ptr [500] - считать в al значение из 500, в ah - значение из 501.
mov eax, dword... - считать в al... верх eax слово из 502, 503.
...

А при 48 бит и таком подходе кратного деления самих регистров не будет?

[Sla]

byte
dword - какая размерность?

Я начинал "программировать" еще на "чемоданах" построенных на процессорной серии 1804 (4 битные) , и у них что пространство данных, что адресное пространство определялось байтом в 4 бита, и было наборным, т.е. 48 битные данные можно было достаточно легко собрать
Но на процессорах с 8битным байтом, увы... вы получите избыточность.

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

[Aether]

byte = 8 бит
word = 16 бит
dword = 32 бит

Я так понял смысл задачи, которая вызывает затруднения при адрессации:
у нас есть массив из данных по 32бита на значение (long int), нужно адресоваться к произвольному его элементу, получается:
требуемый адрес = базовый адрес таблицы + 4*(номер элемента), но в данном случае умножение на 4 можно заменить более быстрым сдвигом влево на 2.

В случае массива из 48 бит с адрессацией по 8бит (по байту) получается:
требуемый адрес = базовый адрес таблицы + 6*(номер элемента), и
замены умножения на сдвиг не получится.

Но, давайте взглянем с другой стороны:
1) Представление x86: 8бит х 4 = 32бит. Того же можно добиться имея 6бит х 8 = 48бит и используйте сдвиг на здоровье, правда это не очень прогрессивно.
2) Зачем делить 48бит на мелкие части при адрессации?

Кстати, у обычного х86 при массиве состоящем из структур те же проблемы, например, есть массив из структуры short int (8) + float (80) итого 11байт, тогда доступ к произвольному элементу будет идти через умножение на 11. Так что сдвиг не везде возможен.

[darkelf]

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

Например, Вам надо прочитать 16-ти разрядное слово по выравненному адресу, тогда процессор выставляет запрос на шину данных, насколько я помню, она сейчас там 64-х битная, т.е. за раз, можно считать двойное слово и адрес соответственно на чтение выставляется кратный 8. Если данных для указанного адреса нет в кеше, то при этом выдаётся запрос на чтение из ОЗУ в кеш, но чтение выполняется уже не 8-ми байт, а 32-х (это так называемая строка кеша), а уже потом из кеша уже вычитывается нужное слово. Всё происходит за минимальное число тактов (если данные были в кеше или медленнее, если данных в кеше не было).

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

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

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

Это всё очень упрощенно, если интересно более подробно и точно есть очень неплохая статья про всё это: http://rus-linux.net/MyLDP/hard/memory/memory.html

PS: не совсем уверен, что это подходящая тема.

[Aether]

Нет, Вы уже в аппаратную часть переходите. Пока речь о более простом:

Например, нужно создать bitmap под 24бит цвет, размер 1024х1024 пикселей. Вопрос: сколько будет весить файл и сколько будет весить буфер?

С файлом всё просто: 1024х1024х24/8 = 3Мб.

А буфер? Если выделить массив, исходя из соображения упростить вычисления, то выделить придётся 1 dword / 1 pixel. То есть, 4Мб. Как видно, 1Мб испарится ввиде нулей. Теперь представим, что такой подход будет с большими объёмами - на 4Гб будут потери в (25%) 1Гб, что уже не так мало!

В 64бит счетверённое слово можно запихнуть два пикселя, то есть 48бит, но станется недоиспользовано 16бит (25%), то есть в этом плане даже более совершенная 64бит архитектура не экономит ресурсы.

[darkelf]

насколько я могу судить разработчики для видео пошли другим путём - просто придумали 10 бит на компоненту цвета, соответственно на каждый пиксель теряется 2 бита.

а по поводу 64-х битных систем - они более расточительные по памяти чем 32-х битные. Взять вызов  подпрограммы - при вызове в 32-х битном режиме процессора 386 и выше надо сохранить регистры eax, ebx, ecx, edx, esi, edi, ebp и eip - т.е. 8*4=32 байта. А для x86_64 во первых все регистры уже станут 64-х разрядными, т.е. rax, rbx, rcx, rdx, rsi, rdi, rbp, rip, а кроме того, ещё появятся регистры r8-r15, т.е. уже 16*8=128 байт.

На самом деле, конечно, не всё так печально, например для C при использовании cdecl сохраняются не все регистры, но тем не менее, при тех-же переключениях контекстов задач или потоков в ОС уже нужно больше памяти. Да и на другие процессоро-зависимые служебные структуры..

Да что там, даже обычные указатели уже становятся 64-битными и если у Вас есть структура, например, элемента двунаправленного списка, то для 32-х разрядной системы один элемент будет три 32-х разрядных слова (указатель на предыдущий элемент, на следующий элемент и на данные элемента) - 12 байт, а для 64-разрядной уже три 64-х разрядных слова - 24 байта. Кстати в Linux даже попытались обойти такие ограничения, правда только для прикладных задач придумав x32 abi, в котором есть все возможности 64-х битного режима - куча 64-х битных регистров и т.д. но при этом указатели всё-равно 32-х битные.

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

[Aether]

10 бит на канал проблему не совсем решает. Дело в том, что у любой информации есть физическая сущность. Применительно к графике я проводил лет 8 назад небольшое исследование: взял исходную картинку фото качества в формате BMP24, создал программу, которая работает по следующему алгоритму:
- переключает видеоадаптер в режим родного разрешения монитора и 24 бит цветности,
- обрезает исходную картинку в габарит разрешения монитора,
- <3> выводит картинку на монитор,
- обрабатывает события клавиш вверх/вниз,
- с нажатием вверх у каждого пикселя изображения в каждом канале срезается 1 бит снизу (в 0) по-очереди, с каждым нажатием вниз биты восстанавливается от исходного изображения.
- переход на <3>.
Таким образом, можно моделировать, как выглядело бы изображение будь оно 1, 2, 3...8 бит на канал. В итоге, один человек не смог различить контраст перехода при цветности в 6 бит на канал, затем у значительного числа людей не проглядывалась разница в двух соседних тонах при цветности в 7 бит, 8 бит - перекрывает возможности глаза гарантировано. 10 бит в канале можно создать, если пытаться вести вычисления с повышением точности, например, сглаживание, но в этом случае лучше не мудрить, а раскладывать каждый канал в 16 бит и считать, а потом нормировать в положенные 8 бит - на х86 это проще. Другое дело: возможности монитора и видеоадаптера - пока не встречал моделей способных выдать 10 бит качества.

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

Кстати, интересно было бы провести подобный эксперимент со звуком, но я с ним никогда не работал.( Интересно было бы послушать не 16, а, например, 12 бит звук. 8 - не надо))) Уже слышал.

[Джон]

В итоге, один человек не смог различить контраст перехода при цветности в 6 бит на канал, затем у значительного числа людей не проглядывалась разница в двух соседних тонах при цветности в 7 бит, 8 бит - перекрывает возможности глаза гарантировано.

Непоказательно. Какой монитор использовался?

[darkelf]

Aether, простым людям, возможно, 8-ми бит на канал хватает за глаза, но для полиграфии, думаю, всё не так однозначно - кому-то и специальные мониторы покупают и разные CMyK-и придумывают.. Да и сейчас лишние мегабайты, а иногда даже и гигабайты никого не волнуют вон для UHDTV - 7680 на 4320 - 33.18 мегапикселя - 128Мбайт памяти на картинку если 4 байта на пиксель.. при штатных 8-ми гигабайтах ОЗУ на ПЭВМ - не очень и большой размер. плюс ко всему - для этого есть выделенная память видеокарты, так-что основную память оно вроде как не сильно загружает.

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

[Aether]

Непоказательно. Какой монитор использовался?

ЭЛТ 19" Я подрабатывал рисуя в Lightwave, поэтому в конторе стояли мониторы нормальные. Фирму-производителя, естественно, забыл, впрочем, эксперимент можно повторить, и даже сделать его проще.

Да и сейчас лишние мегабайты, а иногда даже и гигабайты никого не волнуют вон для UHDTV - 7680 на 4320 - 33.18 мегапикселя - 128Мбайт памяти на картинку если 4 байта на пиксель.. при штатных 8-ми гигабайтах ОЗУ на ПЭВМ - не очень и большой размер.

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

Добавлено через 3 минуты и 46 секунд:

CMyK-и придумывают.

Кстати, это формат не для монитора а для вывода на печать, изначально хотели сделать его CMY, так как в теории при полном смешении должно выйти чёрное, но из-за свойств краски на деле вышло тёмно-коричневое, поэтому добавили чёрный - так сказать, для гарантии. Получилось CMYK (32бит).

[darkelf]

Да и сейчас лишние мегабайты, а иногда даже и гигабайты никого не волнуют вон для UHDTV - 7680 на 4320 - 33.18 мегапикселя - 128Мбайт памяти на картинку если 4 байта на пиксель.. при штатных 8-ми гигабайтах ОЗУ на ПЭВМ - не очень и большой размер.

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

Да, но выбора-то нет. Возьмём очередную революцию в мобильном секторе - внедрение 64-х битных ARMv8. Кому в телефонах нужны 64-х битные вычисления? Там памяти обычно 1G, может 2G, не больше. Но ведь нет, внедряют вовсю.

Кстати, это формат не для монитора а для вывода на печать, изначально хотели сделать его CMY, так как в теории при полном смешении должно выйти чёрное, но из-за свойств краски на деле вышло тёмно-коричневое, поэтому добавили чёрный - так сказать, для гарантии. Получилось CMYK (32бит).

да, я знаю. я про то, что задачи бывают разные, и под задачу уже могут придумывать и технологии, и 32-х битный цвет. В wikipedia читал, что для каких-то рабочих станций и 48-ми битный цвет придумывали.

[Джон]

Aether, простым людям, возможно, 8-ми бит на канал хватает за глаза, но для полиграфии, думаю, всё не так однозначно - кому-то и специальные мониторы покупают и разные CMyK-и придумывают.

Абсолютно верно. darkelf только немного "оговорился" , не "CMyK-и придумывают" (CMYK действительно для печати, там ещё больше заморочек, например, краска, бумага),  а "придумывают" sRGB, Adobe RGB. На сегодняшний момент 16 бит - это минимум де факто. Да и алгоритмы всяких а ля Фотошопов работают тем качественней, чем инфы больше.

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

[RXL]

Если так, то как быть, например, с 286, если мне память не изменяет, то адреса там 24бит. Ну и про пень тоже стоит вспомнить - адреса 36бит. Производить вычисления сдвигом можно в любой двоичной системе.

Размер адресуемой памяти вообще не к месту. Регистры все равно 16 и 32 бита для 286 и 386 соотв.

[Ochkarik]

нюансик: 8 бит на цвет/10 бит может и не заметно. а контраст?

[Aether]

Кому в телефонах нужны 64-х битные вычисления? Но ведь нет, внедряют вовсю.

Да! И поэтому я иной раз матерюсь.))) У каждого нового телефона зарядки хватает на всё и всё меньше, а 90% его функций мне не нужны.

Субъективная оценка, в принципе, не показательна.
А если ещё и на мониторе... Если ЭЛТ, то его надо, как минимум 2 часа "прогревать". Плюс внешнее освещение. Плюс калибровка, создание профилей. И это, при прочих равных условиях, ещз и качество самого монитора должно быть на ооочень большой высоте.

Субъективно? Если в плане эксперимента, то я организовывал, стараясь исключить ложь. То есть, пациент отворачивается - меняю картинку, смотрит - говорит видит или не видит разницу. Иногда, показывал одну и ту же. Если же субъективно в плане - все мы люди разные, то да. Тем не менее, стоит понимать, что как тяжелоатлет не тренируется - тонну не поднимет, поэтому у всего есть предел. Ну и, естественно, автомобиль, например, рассчитывают не под атлета-гиппопотама, а под среднее значение в выборке с запасом на пару среднеквадратичных отклонений.

Второе: если качество монитора на недостаточно большой высоте уже не влазит в 8 бит, то о 10 бит и речи быть не может, так как это в 4 раза круче. А про ЖК можно, вообще, промолчать, так как долгий срок было оно на уровне 6 бит чистыми и всё.

нюансик: 8 бит на цвет/10 бит может и не заметно. а контраст?

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

В целом, вопрос, фундаментальный, возможно, кто-то предложит способ лучше определить границу восприятия? Может, капать в стакан с дистиллированной водой краситель по каплям, и попробовать понять разницу между 178 и 179 каплями в разных стаканах, но тут будет мешать нелинейность процесса окрашивания от концентрации?(

[Dale]

Не было бы более логичным, например, предложить 48бит архитектуру?

Уже было, причем было классикой, учите матчасть. И благополучно сплыло. Ибо:

Что было в прошлом, то и теперь,
               И что делалось прежде, то происходит и ныне.
                             Ничего под солнцем нового нет.

Иногда говорят: Смотри, что-то новое!
               Но это уже было давным давно,
                             В веках, минувших задолго до нас.

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

[Aether]

Я разьве говорю о новом? Всегда можно покопаться и найти что-то уже сделанное, и применённое, но, тем не менее, нужно вместе с этим приводить и контекст. В 70-х годах вычислительная техника претерпевала период поиска решения. До этих лет элементная база была скудна, но с появлением возможностей каждый пытался лепить горбатого сам. Эволюция, политика, экономика многих этих горбатых отправили в утиль, и осталась классика - х86. Вопрос исходный был примерно таков: чем х86, х86-64 лучше х48? Почему сейчас, тот же ARM, не ищет решение, а клепает ветку 16-32-64?

Ещё, не стоит забывать, что в те годы речь о ПК не шла, также эти машины использовались для сугубо математических вычислений, то есть решение диффур, нахождение интегралов, итерационные методы, ряды Фурье... О просмотре видеофильмов, аудио воспроизведении, ЧПУ машиностроении и многом другом речь не шла. Бесспорно, что х64 архитектура будет превосходить по пиковой производительности вычислений и 16 и 32 и 48 бит системы, но то, что ресурсы просаживаются на типовых каждодневных задачах как бы факт. Кстати, такие меры, как конвейеры, кэш... - каждая добавляет быстродействию по нескольку процентов или десятков процентов, но в сумме выходит неплохо, а здесь теряется до четверти ресурсов сразу.

[RXL]

Уже было, причем было классикой, учите матчасть. И благополучно сплыло. Ибо:

Гардвардская архитектура допускает такое. Пожалуйста: PIC12: машинное слово - 12 бит, слово данных - 8 бит. Но для универсальных процессоров лучше архитектура фон Неймана, и здесь снова 48 бит не удобно.

[Dale]

чем х86, х86-64 лучше х48?

Принципиально - ничем. Всего лишь более "круглое" с точки зрения двоичной арифметики число.

Вопрос из той же категории, что и "чем метрическая система мер лучше, чем дюймы-футы-ярды-мили..."? Да ничем принципиально. Равно как и 12 пенсов в шиллинге или 20 шиллингов в фунте никого не свели с ума.

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

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

Видимо, потому, что оно им и даром не нужно, технических сложностей здесь нет. Это "решение" реально не решает насущных проблем. А если даже какие-то и решит, то породит другие.

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

И сейчас x86 используются для тех же целей, и длина слова не является непреодолимым препятствием для этого.

Бесспорно, что х64 архитектура будет превосходить по пиковой производительности вычислений и 16 и 32 и 48 бит системы

И что с того? А x96 или X192 превзойдет еще больше.

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

Добавлено через 8 минут и 3 секунды:

Гардвардская архитектура допускает такое.

Абсолютно без разницы. Различие между этими архитектурами заключается отнюдь не в числе двоичных разрядов для кодирования команд или данных.

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

Опять же, не факт. Знаменитая PDP-10 имела архитектуру фон Неймана при длине слова 36 бит, и никому это неразрешимых проблем не создавало. По крайней мере, в MITе и Стенфордском университете это была одна из базовых исследовательских платформ в свое время.

[RXL]

Если ячейка памяти нужной размерности, то проблемы нет.
Гарвардскую архитектуру я привел именно в этом контексте: разрядность ячеек памяти данных не зависит от разрядности ячеек кода.

[Dale]

Кстати, забавный сайт для староверов в тему: http://www.inwap.com/pdp10/

[Aether]

Вопрос из той же категории, что и "чем метрическая система мер лучше, чем дюймы-футы-ярды-мили..."? Да ничем принципиально. Равно как и 12 пенсов в шиллинге или 20 шиллингов в фунте никого не свели с ума.
Кто к чему привык, тому то и лучше. Просто десятичная метрическая система выглядит логичнее. Но измерить расстояние можно в любой одинаково точно.

Измерять физические величины и вести их счёт, естественно, можно в любой системе мер и счислений. Если угодно, можно даже мерить лопатами #Г, причём как массу, так и габарит. Но, представьте, велосипед - без человека он бессмысленен, что есть - что нет. А человеку, обладателю, он даёт определённые преимущества в передвижении. С системами счёта тоже не так всё просто, говорите логичнее? А логика в чём? Человеческая память, увы, тоже имеет нюансы, Вы обращали внимание: сколько может бегло запомнить цифр человек? Обычно, это 5-6, иногда 7 цифр. Поэтому считать в системах малого основания для человека сложновато - мал объём, например 6 цифр в двоичной будет иметь объём лишь до 64 единиц, а десятичная уже до миллиона. С другой стороны, слишком большое основание, например, шестнадцатеричное - увеличивает нагрузку на долговременную память. Таблица умножения будет иметь уже 256 вариаций. Довольно большая численность людей в среде рабочих и не только, надо сказать, и десятичную таблицу умножения знает посредственно - реалии жизни.
Исторически, между собой конкурировали системы вблизи "золотой середины" - восьмеричная, десятичная и двенадцатеричная. Так логика получается в том, что среднего примата оказалось проще научить считать на пальцах хотя бы до десяти?
Дюймовая система мер и вложенная в неё двенадцатеричная система счёта - большая тема, кто работал на ручных станках с дюймами, тот поймёт без лишних слов.
Рекомендую, также провести небольшой опыт: взять листок формата А4, нарисовать отрезок произвольной длины и при помощи циркуля (без линейки) разделить его на 10 равных частей. Это даст возможность оценить трудности десятичной метрологии.

[Aether]

[И что с того? А x96 или X192 превзойдет еще больше.

А с того вот что: более сложная архитектура содержит большее число элементов, соответственно, дороже стоит и потребляет больше энергии. Поэтому общая задача, я полагаю, состоит в том, чтобы обеспечить практические потребности людей при минимальных затратах ресурсов. Запас х32 - уже исчерпан возможностями современной технологии, запас х64 - гигантский. Так, возможно, между ними есть некая середина? В плане этого х96 и далее - лишены смысла.

Аргумент, который приводил я: возможность плотной упаковки данных внутри слова максимального размера. Для различных архитектур они следующие:

х86:
32бит х1, 16х2, 8х4, 4х8, 2х16, 1х32 - 6 комбинаций,

х64:
64х1, 32х2, 16х4, 8х8, 4х16, 2х32, 1х64 - 7 комбинаций,

х48:
48х1, 24х2, 16х3, 12х4, 8х6, 6х8, 4х12, 3х16, 2х24, 1х48 - 10 комбинаций.

[zubr]

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

[Aether]

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

[Finch]

Слор перетек в, что круче мозг или тело, которое его окружает. Как одно не может жить без второго, так и "программы" не могут жить без железа, которое их окружает. В принципе железо может жить само по себе. И даже приносить какой то результат работы.

Насчет 286 машинок, Хотя адрессная шина и была 24 битная, Но процессор все равно оперировал с 16 битами. Было лва адресных регистра. по 16 бит. Например CS:IP.  

Архитектурно, 48 битную структуру сложнее делать. Да и она не нужна в системвх обшего назначения. Скорее всего ее будут применять и применяют в каких либо графических процессорах. Там это дейтсвительно оправдано, и приносит ошутимое увеличение производительности.