Комментарии 9
Вообще-то, 8086/88, будучи 16-разрядными, могли адресовать 1 Мбайт памяти. А ИБМовская Система 360, будучи 32-разрядной, могла адресовать только 16 Мбайт памяти. А 16-разрядная PDP-11 в зависимости от варианта -- 64 Кбайта, 256 Кбайт или 4 Мбайта. Дело в том, что адрес не обязательно совпадает с разрядностью процессора -- в т.ч. логический (виртуальный) адрес, а о физическом и говорить нечего.
Да, вы правы, спасибо! Решил и вовсе убрать информацию об этом, так как для целей этой статьи она избыточна
Кстати, ещё про разрядность. Одно дело разрядность с точки зрения программиста, и другое -- физическая разрядность. Одно с другим тоже не очень-то связаны. Разрядность с точки зрения программиста определяется архитектурой (скажем, IA-32 -- 32-разрядная, а её расширение до AMD64 дало в результате современную 64-разрядную архитектуру). А вот физическая определяется разработчиками проца исходя из требований к производительности и т.п. Сейчас они если не всегда, то почти всегда совпадают, но это не является безусловно необходимым. Скажем, Система 360 -- 32-разрядная, однако её процессоры внутри были и 8-, и 16-, и 32-, и 64-разрядными в зависимости от производительности конкретной модели.
но не против конструктивной критики.
Возьмем картинки:
на первой картинке кэш L3 находится справа, а ядра - слева. На второй наоборот, что мгновенно сбивает читателя;
на обеих картинках смешан русский и английский язык, а в тексте используются русские слова без перевода, таким образом для читателя это превращается в терминологическую кашу;
на обеих картинках заглавные и строчные буквы в написании слов применяются бессистемно.
Возьмем текст: выделение жирным используется поначалу для описания терминов, далее для описания действий этих терминов, а потом вообще непонятно для чего.
Вследствие совокупной небрежности, воспринимать этот текст сложно, а в вырванных из контекста фразах вообще сложно понять смысл:
Инструкции, которые передаются вместе с данными, попадают в кэш инструкций, а данные оказываются в кэше данных.
А что происходит с инструкциями, которые передаются отдельно о данных? Или так не бывает? И в чем вообще смысл разделять их, инструкции это разве не данные, а что это тогда? И что такое кэш, в который надо "попадать"?
Спасибо за замечения! Смешно получилось с сочетанием языков на картинках, как в меме: "смотря какие details"))))
Ну а вообще, изначально такая асимметрия в картинках из-за более привычного расположения ОЗУ справа от ЦП, но при этом при просмтре строения ядра привычнее читать схему слева направо. С учётом схематичности изображений, а также с разнообразности строения материнских плат, особенно серверных, решил поменять картинки, чтобы всё читалось слева направо.
Быстродействие компьютера определяется тактовой частотой его процессора.
Нет. Быстродействие компьютера определяется множеством факторов. Например, скоростью работы дисковой подсистемы, если вы с файлами работаете. Если же мы хотим упростить быстродействие компьютера до быстродействия процессора, то оно опредляется не только частотой, а ещё и таким показателем как IPC (Instructions per Cycle)
RISC (Reduced Instruction Set Computing)
Преимущества:
Простота инструкций: Инструкции в RISC-архитектуре проще и быстрее выполняются, что позволяет увеличить производительность за счет более быстрого цикла выполнения команд.
Конвейеризация: За счет простоты инструкций конвейеризация (pipelining) становится более эффективной, что позволяет выполнить больше команд за такт.
Энергоэффективность: Меньшее количество транзисторов и простота инструкций обычно приводят к более низкому энергопотреблению, что важно для мобильных и встроенных устройств.
Универсальность: Простые инструкции легко реализуются в аппаратуре, что делает архитектуру более гибкой для различных типов приложений.
В современном мире все приведённые преимущества неверны.
Недостатки:
Сложности компиляции: Компиляторы должны быть более умными, чтобы эффективно использовать простые инструкции для сложных задач.
Скажем так, в современном мире это тоже не так.
CISC (Complex Instruction Set Computing)
Преимущества:
Многофункциональность: Поддержка множества инструкций и режимов работы позволяет процессорам x86-64 быть очень универсальными и адаптивными для разных задач.
Это не так. Современные RISC процессоры ничем в этом аспекте не уступают. Вы же тут сами себе противоречите, где в преимуществах RISC называете универсальность.
Недостатки:
Сложность и энергопотребление: Более сложные инструкции требуют больше транзисторов и более сложной логики, что увеличивает энергопотребление и тепловыделение.
Наследие: Поддержка устаревших инструкций и режимов может накладывать дополнительные ограничения на архитектуру, делая ее менее эффективной по сравнению с RISC.
Это тоже в современном мире неверно. Это вообще странно писать в ситуации, когда самые высокопроизводительные процессоры на текущий момент - CISC процессоры архитектуры x86.
самые высокопроизводительные процессоры на текущий момент - CISC процессоры архитектуры x86
Вообще, от задачи зависит. Скажем, в роли матричной числодробилки даже посредственный графический процессор порвёт любой AMD64. Если всякие там массовые шифрования AES и всё такое прочее, то, вполне возможно, победителем будет проц z/Architecture, где подобные операции делаются одной командой (и он, есно, CISC, ведущий свою родословную от Системы 360). Но, в любом случае, проблематично назвать "самый-самый", а уж без конкретизации рода задач -- и вовсе невозможно.
Можно придраться ко многим фразам, но, раз уж название "для самых маленьких", то сойдёт.
Однако вывод просто противоречит фактам и мимо него нельзя просто пройти, проигнорировав. Например, в том, что достигнув производительности десктопных х86, arm по tdp и энергоэффективности сравнялись с x86. С другой стороны, Intel выпустила линейку процессоров Lunar Lake, спроектированную под тонкие, лёгкие и автономноые ультрабуки. И это у них получилось. Lunar Lake по производительности выступают на равных или быстрее соответствующих чипов Qualcomm и Apple, превосходя их по энергоэффективности.
Рано хоронить х86.
Мои заметки про процессоры для cовсем маленьких