Разное
Некоторое время назад я разговаривал с одним жителем Самары. Ситуация располагала к сложному и даже неприятному для меня разговору, но мой собеседник вёл себя вполне доброжелательно, и мы, можно сказать, поладили. В ходе этого разговора прозвучал вопрос, на который я, насколько позволяла обстановка, ответил, однако этот вопрос засел у меня в памяти. Потом, как полагается, всплыл, и я подумал, что смогу дать на него более развёрнутый ответ. Тем более, что спрашивал он вполне искренне, к тому же это наверняка интересует не его одного.
Вопрос звучал так: а что «они» там все зациклились на Бандере? Коротким моим ответом в разговоре было, что зациклились совсем не «они», а те, кто старательно выстраивает ассоциацию Львов=Бандера. А на самом деле Львов богат на самые разные имена, и мне захотелось назвать имена людей, которым поставлены памятники, которыми названы улицы и прочие львовские объекты. Про каждого такого человека рассказать по возможности кратко, только главное – и постараться заинтересовать, чтобы дальше россияне уже искали информацию сами.
Не скрою, что меня давно беспокоит отсутствие профессионалов в руководстве различными областями (предприятиями, организациями, институциями). Конечно, и в СССР продвижение по карьерной лестнице часто было через комсомол и Партию, однако тогда соблюдались хотя бы какие-то приличия, да и сами такие выдвиженцы умели держать язык за зубами, когда дело касалось профессиональных вопросов.
Галопом по вычислительным Европам. Часть 5. Память.
Выводы и кое-что о путях дальнейшего роста производительности
Хорошо, сделали мы быстрое ядро, продумали иерархию кэширования и архитектуру памяти, накормили процессор данными, как теперь работать будем? Надо бы побыстрее, конечно — вопрос в том, какими еще путями можно этого добиться. Про конвейер и несколько конвейеров параллельно мы уже знаем, а что еще можно сделать, имея в виду невозможность бесконечного ускорения отдельно взятого вычислителя по причинам чисто физическим (подробнее о проблеме см. в Приложении 2)?
Во-первых, можно (и даже нужно) разгрузить процессор от рутинных вспомогательных задач, которые — и это очень существенно — имеют унифицированную логику, не зависящую ни от логики главной задачи, ни даже от используемой операционной системы и конкретного оборудования.
Галопом по вычислительным Европам. Часть 4. Как накормить процессор.
Итак, ее величество оперативная память
Когда-то давным-давно, когда компьютеры были большими — никакой другой памяти, кроме оперативной, у компьютеров не было. Всё, что им надо было знать, загружалось после включения с перфокарт в память, там обрабатывалось, результаты выводились на печать — и всё, компьютер можно было выключать. Спустя годы появились внутренние долговременные носители, которыми можно уже было управлять, получая доступ к нужным данным по мере работы программ. И вот тут уже есть тонкость. Какая? В принципе, ничто не мешает напрямую считывать каждый элемент данных с накопителя прямо в процессор, почему нет? Но скорость-то…? Скорость работы всех энергонезависимых накопителей до сих пор настолько ниже скоростей обработки в процессорах (так было и 60+ лет назад, задолго до появления у процессоров приставки «микро»), что такая схема убивает всю идею быстрых вычислений на корню. Поэтому очень быстро сложилась практика предварительной загрузки данных с медленных носителей в быструю оперативную память с тем, что чтобы потом уже в ней производить обработку.
Никогда не думал, что примерю на себя роль кинокритика (тем более, фильма, связанного с культурой и классической музыкой), но уж очень захотелось написать о том, что увидел в фильме, чего и близко не увидел ни в одной рецензии.
Начинается фильм действительно с исполнения 5-й симфонии Бетховена, оркестром дирижирует великий Вильгельм Фуртвенглер (1886 - 1954). Но главное в этой сцене не музыка (сейчас её можно скачать в десятках исполнений), а обстановка, в которой эта музыка исполняется...
Галопом по вычислительным Европам. Часть 3. Оптимизация.
Сага о голодных птенцах, или Наличные наше всё
Нет, дедушка еще не сошел с ума, просто состояние ядер современных высокопроизводительных процессоров в отношении данных больше всего напоминает состояние вечно голодных птенцов, а наличные — всего лишь буквальный перевод слова cash (cache). Собственно, о кэшировании я и хочу поговорить. Когда компьютеры только появились — все было хорошо. Процессоры (и микро- и еще до того, как они стали микро) работали на одной частоте с памятью и росли они в быстродействии совершенно параллельно. Пока процессор внутри себя десятки и сотни тактов пережевывал команды (помните про IPC/CPI i8086?) — недорогая динамическая PM/FPM память вполне успевала регенерировать заряд в ячейках и была готова к следующему запросу на чтение или запись.
Галопом по вычислительным Европам. Часть 2. Пути повышения IPC.
Статическая оптимизация и «бег в ширину»
Другой вариант оптимизации исполнения называется «явный параллелизм» или «статическая оптимизация». Предполагается, что на этапе компиляции будут заранее выявлены все возможности распараллеливания и сформирован абсолютно идеальный код, заполняющий все функциональные устройства процессора в каждом такте. Никакого динамического анализа кода не нужно (соответственно, не нужно сложной схемотехники организации спекулятивного исполнения, занимающей заметную часто кристалла), все заранее готово и можно не глядя запускать на исполнение готовые «упаковки» команд, заполняющие все ФУ. Красиво? Безусловно. Универсально? Нет, конечно. Во-первых — см. выше про последовательную природу большинства алгоритмов. Во-вторых — не все зависимости хорошо ложатся на конкретные архитектуры процессоров.
Галопом по вычислительным Европам. Часть 1. Что такое процессор.
Что еще можно предпринять для увеличения количества обрабатываемой за единицу времени информации? Один из этих путей мы уже видели — это увеличение размера операнда с 8 до уже 64 разрядов. Можно больше? В принципе да, почему нет? Другое дело, что больше 64 разрядов пока не очень нужно, кроме как в некоторых алгоритмах. Заметили слово «некоторых»? Идея в том, чтобы реализовать специальные команды, позволяющие в некоторых алгоритмах (особенно, связанных с обработкой потоковых данных, в первую очередь аудио- и видео) работать с операндами еще большей длины.
Материал нисколько не претендует на роль учебника, и не преследует никаких других целей, кроме как дать желающим общее представление о работе современных компьютеров, с рассказом о том, откуда что пошло, и почему всё сформировалось в том виде, в котором мы его сегодня наблюдаем.
Понимая, что читать сей опус будут люди с разным уровнем специальных знаний с одной стороны и с разной степенью заинтересованности в деталях и подробностях с другой — я сознательно оставляю в тексте только минимальное популярное изложение, убирая все тонкости и детали в сноски и давая ссылки на внешние материалы (нет смысла переписывать Википедию). Кому нужно больше, чем в основном тексте — добро пожаловать в сноски и по ссылкам. Но это не обязательно.
Первую часть, про которую ещё не знал, что она будет частью чего-то, я написал в 2006 году, вторую в 2014, третью пишу в 2022. Как видите, у меня сложилась уже традиция раз в 8 лет писать юзерам о самом главном: как не потерять свои данные. Первым поводом на этот раз послужила целая эпопея восстановления данных клиента из разных источников, что стоило много сил мне и много крови владельцу этих данных. И хотя на этот раз всё получилось, тут кроме всего прочего присутствовал и элемент везения, без которого энд был бы совсем не хэппи.