В то время как жесткие диски развиваются и предлагают все больше и больше места в меньшем пространстве, почему мы «придерживаемся» 32-разрядных или 64-разрядных?
Почему не может быть, например: 128-битный процессор?
(Это не моя домашняя работа, я просто студент, интересующийся не только тем, чему нас учат в информатике)
Поскольку разница между 32-разрядной и 64-разрядной версиями астрономическая — на самом деле это разница между 232 (десятизначное число в миллиардах) и 2. 64 (двадцатизначное число в сквиллионах :-).
64 бит будет более чем достаточно на десятилетия вперед.
В этом очень мало необходимости, когда вы имеете дело с такими большими числами? Текущее адресуемое пространство памяти, доступное для 64-разрядных систем, намного превышает то, что любая машина может обрабатывать по крайней мере в течение нескольких лет ... и, кроме того, это, вероятно, больше, чем любой настольный компьютер будет вмещать в течение достаточно долгого времени.
Да, объем памяти рабочего стола будет увеличиваться, но в 4 миллиарда раз больше, чем сейчас? Это займет некоторое время... конечно, мы доберемся до 128-бит, если вся текущая модель не будет выброшена до этого, что я считаю столь же вероятным.
Кроме того, стоит отметить, что обновление чего-либо с 32-разрядной до 64-разрядной системы сразу же приводит к снижению производительности в большинстве сценариев (это основная причина, по которой Visual Studio 2010 остается только 32-разрядной). То же самое произойдет с 64-битной на 128-битную. Чем больше у вас мелких объектов, тем больше указателей, которые теперь вдвое больше, это больше данных для передачи, чтобы делать то же самое, особенно если вам не нужно столько адресуемой памяти.
Когда мы говорим об n-битной архитектуре, мы часто смешиваем две довольно разные вещи:
(1) n-битная адресация, например. ЦП с 32-битными адресными регистрами и 32-битной адресной шиной может адресовать 4 ГБ физической памяти.
(2) размер внутренних путей данных ЦП и регистров общего назначения, например. ЦП с 32-битной внутренней архитектурой имеет 32-битные регистры, 32-битные целочисленные АЛУ, 32-битные внутренние пути данных и т. д.
Во многих случаях (1) и (2) совпадают, но существует множество исключений, и это может стать все более частым явлением, например. нам может не понадобиться более 64-битной адресации в обозримом будущем, но нам может понадобиться > 64-битная адресация для регистров и путей данных (это уже относится ко многим процессорам с поддержкой SIMD).
Короче говоря, вам нужно быть осторожным, когда вы говорите, например. "64-битный процессор" - это может означать разные вещи в разных контекстах.
Расходы. Кроме того, как вы думаете, что даст вам 128-битная архитектура? Адресация памяти и тому подобное, но для эффективной работы с ней вам нужны шины с более высокой пропускной способностью и, в основном, некоторые новые языки инструкций, которые ее обрабатывают. 64-разрядных более чем достаточно для адресации (18446744073709551616 байт).
Жестким дискам все еще есть место, чтобы догнать оперативную память и тому подобное. Я думаю, они все еще будут узким местом ввода-вывода. Кроме того, новые чипы просто поддерживают больше ядер, а не вносят серьезные изменения в язык.
Так получилось, что я профессиональный компьютерный архитектор (вероятно, мои изобретения находятся на компьютере, на котором вы это читаете), и хотя мне еще не платили за работу на каком-либо процессоре с более чем 64-битным адресом, я знаю некоторые из них. мои друзья, которые были.
И я играл со 128-битной архитектурой для удовольствия в течение нескольких десятилетий.
т.е. это уже происходит.
На самом деле, это уже произошло в ограниченной степени. Архитектура HP Precision, Intel Itanium и высшие версии линейки IBM Power имеют то, что я называю свернутой виртуальной памятью. Я описал их в другом месте, например. в сообщениях comp.arch с некоторыми подробностями, http://groups.google.com/group/comp.arch/browse_thread/thread/53a7396f56860e17/f62404dd5782f309?lnk=gst&q=folded+virtual+memory#f62404dd5782f309
Мне нужно создать вики-пост comp-arch.net для них.
Но вы можете получить руководства для этих процессоров и прочитать их самостоятельно.
Например. вы можете начать с 64-битного виртуального адреса пользователя. Старшие 8 бит могут использоваться для индексации таблицы регионов, которая возвращает старшие 24 бита, которые объединяются с оставшимися 64-8=56 битами для создания 80-битного расширенного виртуального адреса. Который затем, как обычно, транслируется с помощью TLB, таблиц страниц и хеш-поиска на любой ваш физический адрес.
Зачем переходить с 64->80?
Одна из причин — общие библиотеки. Вы можете захотеть, чтобы общие библиотеки оставались на одном и том же расширенном виртуальном адресе во всех процессорах, чтобы вы могли совместно использовать записи TLB. Но ваши языковые средства могут потребовать от вас переместить их на другие виртуальные адреса пользователей. Свернутые виртуальные адреса позволяют это.
Свернутые виртуальные адреса не соответствуют действительности > 64-битные виртуальные адреса, используемые пользователем.
Если на то пошло, есть много предложений для > 64-битных указателей: например. Я работал над одним, где указатель состоял из 64-битного адреса, 64-битной нижней и верхней границ и метаданных, всего 128 бит. Проверка границ. Но, несмотря на то, что они имеют > 64-битные указатели или возможности, на самом деле они не являются > 64-битными виртуальными адресами.
Линус публикует информацию о 128-битных виртуальных адресах на странице http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=103574&threadid=103545&roomid=2
Я также хотел бы предложить точку зрения компьютерного архитектора на то, почему 128-битная технология непрактична в данный момент:
Стоимость энергии. Посмотрите презентации Билла Далли о том, как сегодня большая часть энергии в процессорах тратится на перемещение данных (рассеивается по проводам). Однако, поскольку наиболее значащие биты 128-битного вычисления должны мало изменяться, это должно смягчить эту проблему.
Большинство арифметических операций имеют нелинейную стоимость относительно размера операнда:
а. Множитель дерева имеет пространственную сложность n ^ 2, w.r.t. количество бит.
б. Задержка иерархического сумматора с опережением переноса составляет Log[n] относительно количества битов (я думаю). Таким образом, 128-битный сумматор будет медленнее, чем 64-битный. Кто-нибудь может дать точные цифры (Log [n] кажется очень дешевым)?
Немногие программы используют 128-битные целые числа или четырехкратную точность с плавающей запятой, и когда они это делают, существуют эффективные способы их составления из 32- или 64-битных операций.
Следующей большой вещью в архитектуре процессоров станут квантовые вычисления. Вместо того, чтобы быть просто 0 или 1, кубит имеет вероятность быть 0 или 1.
Это приведет к значительному улучшению производительности алгоритма (например, будет очень легко взломать любой закрытый/открытый ключ RSA).
Посетите http://en.wikipedia.org/wiki/Quantum_computer для получения дополнительной информации и до встречи. через 15 лет ;-)
Основная потребность в 64-битном процессоре заключается в том, чтобы адресовать больше памяти, и это является движущей силой перехода на 64-битный процессор. В 32-битных системах вы действительно можете адресовать только 4 ГБ ОЗУ, по крайней мере, для каждого процесса. 4Гб это не много.
64 бита дают вам адресное пространство в несколько петабайт (хотя многие современные 64-битные аппаратные средства могут адресовать «только» 48 бит - этого все же достаточно для поддержки 256 терабайт оперативной памяти).
Однако увеличение естественных целых чисел для процессора автоматически не делает его «лучше». Есть компромиссы. При 128-битной версии вам потребуется в два раза больше места для хранения (регистры/оперативная память/кеши/и т. д.) по сравнению с 64-битной для обычных типов данных — со всеми возможными недостатками — больше оперативной памяти требуется для хранения данных, больше данных для передачи = медленнее. , более широкие шины могут потребовать больше физического пространства/возможно, большей мощности и т. д.
