1. Введение

Всем нам известна проблема курицы и яйца: работодатели не хотят брать на работу выпускников без опыта работы, но где же в таком случае выпускникам получить опыт работы? В микроэлектронике эта проблема стоит особо остро ввиду требуемого огромного количества специфического опыта. Наши ВУЗы с советских времен знамениты широчайшей теоретической подготовкой, которая должна помочь выпускнику в любой сложной ситуации в жизни. Однако, современная индустрия требует практического опыта. Добавим сюда еще отсутствие мотивации, приводящее к тому, что по специальности работает процентов 15% выпускников, и получим жесточайший кадровый голод в отрасли, которая очень требовательна к качеству кадров. А ведь если бы каждый студент мог "поморгать лампочкой" со своего собственного кристалла ситуация могла бы развиваться совсем иначе.

Рисунок 1. КДПВ

Что же мешает таким грандам подготовки кадров отечественной микроэлектроники, как, например, МИФИ и МИЭТ, поступать аналогично своим зарубежным коллегам (например, MIT или UZH), а именно — давать возможность студентами-дипломникам выпускать свои собственные кристаллы? Можно, конечно, предположить, что выпуск собственного кристалла занятие крайне долгое, сложное и дорогое, а потому для института — дорого, а для студента — непосильно. Однако, это не так. Давайте же взглянем на одну из доступных технологий на отечественном рынке микроэлектроники, знакомство с которой позволит студенту стать значительно более привлекательным в плане будущего трудоустройства, а предложение которой для студента — позволит университету значительно поднять свой рейтинг в глазах абитуриентов и работодателей.

Часто приходится видеть, как новички пробуют Common Lisp и потом жалуются, что с ним невозможно нормально работать. Как правило, это происходит из-за того, что они не понимают как настроить себе процесс, обеспечивающий тот самый "быстрый отклик" от среды разработки, когда ты поменял функцию, скомпилировал её и изменения тут же начали использоваться внутри уже "бегущей" прогрммы без её перезапуска.

Понять, как это выглядит, можно посмотрев какой-нибудь ролик на youtube, где демонстрируется интерактивная разработка на Common Lisp.

Intro

Этот пост написан под впечатлением от вот этого отличного поста с Хабра, в котором автор наглядно, при помощи двумерных моделек, которые рисует его программа, объясняет как работает Специальная Теория Относительности.

Я работаю в IT, а по образованию – физик-теоретик. Уже долгое время увлекаюсь популяризацией науки, и теоретической физики в частности. Постараюсь аналогично вышеупомянутому посту о специальной теории относительности объяснить на специально подготовленном примере как работает квантовая механика.

Модель, которую я рассматриваю – отнюдь не нова. Более полугода назад Chris Cantwell разместил на YouTube анонс новой настольной игры: квантовых шахмат (многим, возможно, известно об этом из вот этого вирусного ролика).

Недавно игра вышла в Steam, она стоит 249 руб. Есть ещё другая реализация – бесплатное приложение для iOS (не знаю, есть ли оно в Google Play). Однако в процессе игр с друзьями я экспериментально выяснил, что она неправильная с точки зрения квантовой механики. Такую реализацию скорее можно назвать статистическими шахматами, а не квантовыми.

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

Почти все разработчики знают, что кэш процессора — это такая маленькая, но быстрая память, в которой хранятся данные из недавно посещённых областей памяти — определение краткое и довольно точное. Тем не менее, знание «скучных» подробностей относительно механизмов работы кэша необходимо для понимания факторов влияющих на производительность кода.

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

Хочу поговорить об устройстве управления памятью (Memory Management Unit, MMU). Как вы, разумеется, знаете, основной функцией MMU является аппаратная поддержка виртуальной памяти. Словарь по кибернетике под редакцией академика Глушкова говорит нам, что виртуальная память — это воображаемая память, выделяемая операционной системой для размещения пользовательской программы, ее рабочих полей и информационных массивов.

У систем с виртуальной памятью четыре основных свойства:

1. Пользовательские процессы изолированы друг от друга и, умирая, не тянут за собой всю систему
2. Пользовательские процессы изолированы от физической памяти, то есть знать не знают, сколько у вас на самом деле оперативки и по каким адресам она находится.
3. Операционная система гораздо сложнее, чем в системах без виртуальной памяти
4. Никогда нельзя знать заранее, сколько времени займет выполнение следующей команды процессора

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

К сожалению, по какой-то причине все вышеперечисленные товарищи недостаточно почтительно относятся к MMU, а их знакомство с виртуальной памятью обычно начинается и заканчивается изучением страничной организации памяти и буфера ассоциативной трансляции (Translation Lookaside Buffer, TLB). Самое интересное при этом остается за кадром.

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

Кэш память процессора используется для уменьшения времени простоя процессора при обращении к RAM.

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

Логически кэш-память представляет собой набор кэш-линий. Каждая кэш-линия хранит блок данных определенного размера и дополнительную информацию. Под размером кэш-линии понимают обычно размер блока данных, который в ней хранится. Для архитектуры x86 размер кэш линии составляет 64 байта.



Так вот суть кэширования состоит в разбиении RAM на кэш-линии и отображении их на кэш-линии кэш-памяти. Возможно несколько вариантов такого отображения.

Занимаясь программированием рендеринга графики, мы живём в мире, в котором обязательны низкоуровневые оптимизации, чтобы добиться GPU-фреймов длиной 30 мс. Для этого мы используем различные методики и разработанные с нуля новые проходы рендеринга с повышенной производительностью (атрибуты геометрии, текстурный кеш, экспорт и так далее), GPR-сжатие, скрывание задержки (latency hiding), ROP…

В сфере повышения производительности CPU в своё время применялись разные трюки, и примечательно то, что сегодня они используются для современных видеокарт ради ускорения вычислений ALU (Низкоуровневая оптимизация для AMD GCN, Быстрый обратный квадратный корень в Quake).


Быстрый обратный квадратный корень в Quake

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

Эта статья — не исчерпывающее хардкорное руководство по железу. Это всего лишь введение, напоминание, свод базовых принципов написания эффективного кода для CPU. Я хочу «показать, что низкоуровневое мышление сегодня всё ещё полезно», даже если речь пойдёт о процессорах, которые я мог бы добавить.

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

Так как карьера программиста тесно связана с процессором, неплохо бы знать как он работает.

Что происходит внутри процессора? Сколько времени уходит на исполнение одной инструкции? Что значит, когда новый процессор имеет 12, или 18, или даже 31-уровневый конвейер?

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

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

Эта статья рассказывает, как устроен вычислительный конвейер x86 процессора.