Рассуждения

При упоминании словосочетания «контейнерная виртуализация», многим на ум сразу же приходят Virtuozzo и OpenVZ, а также Docker. Ассоциируется же это все, в первую очередь, с хостингом, VPS и другими подобными вещами.

Дома, на личных компьютерах многие используют виртуальные машины: в основном, пожалуй, Virtualbox. Как правило, для того, чтобы работая под Linux, иметь под рукой Windows или наоборот. Однако, при наличии множества родственных Linux-операционок, я стал замечать, что использование виртуальных машин — это, мягко говоря, нерационально.

В обычной жизни мы обычно пользуемся позиционной системой счисления. В позиционной системе счисления значение каждого числового знака (цифры) в записи числа зависит от его позиции (разряда) [1]. Однако существуют и так называемые «непозиционные системы счисления», к одной из которых относится «система остаточных классов» (СОК) (или в оригинале Residue Number System (RNS)), являющаяся основой модулярной арифметики. Модулярная арифметика базируется на «Китайской теореме об остатках» [2], которая для нашего случая звучит следующим образом:

Для любой системы взаимно простых чисел p₁, … p_n, любое число X из диапазона [0; M), где M = p₁*p₂*…*p_n взаимооднозначно представимо в виде вектора (a₁, a₂, …, a_n), где a_i = X%p_i (здесь и далее «%» — операция взятия остатка от целочисленного деления X на p_i).
p₁, … p_n – модули системы
a₁, a₂, …, a_n – остатки (вычеты) числа по заданной системе модулей

Приветствую, коллеги. За последние несколько лет Stack Overflow стал полезнейшим инструментом для разработчиков. Множество вопросов, заданных Гуглу и Яндексу, в первых же ссылках ведут на понятные и исчерпывающие ответы на этом ресурсе. Большинство разработчиков используют сайт Stack Overflow именно как базу знаний программистов, возможность быстро получить нужный ответ. Под катом я расскажу про несколько интересных кейсов подводной части айсберга: спрятанные ответы, награды, прокачивание кармы и многое другое, скрытое от поверхностного взгляда.

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

Ранее мы познакомились с тем, как ядро управляет виртуальной памятью процесса, однако работу с файлами и ввод/вывод мы опустили. В этой статье рассмотрим важный и часто вызывающий заблуждения вопрос о том, какая существует связь между оперативной памятью и файловыми операциями, и как она влияет на производительность системы.

Quotient filter — это вероятностная структура данных, позволяющая проверить принадлежность элемента множеству. Она описана в 2011 г. как замена фильтру Блума. Ответ может быть:
— элемент точно не принадлежит множеству;
— элемент возможно принадлежит множеству.

Мне периодически приходится объяснять разным людям некоторые аспекты архитектуры Intel® IA-32, в том числе замысловатость системы адресации данных в памяти, которая, похоже, реализовала почти все когда-то придуманные идеи. Я решил оформить развёрнутый ответ в этой статье. Надеюсь, что он будет полезен ещё кому-нибудь.
При исполнении машинных инструкций считываются и записываются данные, которые могут находиться в нескольких местах: в регистрах самого процессора, в виде констант, закодированных в инструкции, а также в оперативной памяти. Если данные находятся в памяти, то их положение определяется некоторым числом — адресом. По ряду причин, которые, я надеюсь, станут понятными в процессе чтения этой статьи, исходный адрес, закодированный в инструкции, проходит через несколько преобразований.



На рисунке — сегментация и страничное преобразование адреса, как они выглядели 27 лет назад. Иллюстрация из Intel 80386 Programmers's Reference Manual 1986 года. Забавно, что в описании рисунка есть аж две опечатки: «80306 Addressing Machanism». В наше время адрес подвергается более сложным преобразованиям, а иллюстрации больше не делают в псевдографике.

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

Персептрон

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

Когда мы 19 сентября разбирали iPhone 6, предоставленный одним смелым интернет-магазином, его владелец Игорь рассказывал нам удивительные истории о мошенничествах, связанных с этим популярным гаджетом. Истории были насколько увлекательными, настолько и печальными. После того, как эпопея с разбором и сбором закончилась, я попросил Игоря рассказать все известные ему способы жульничества, коих набралось аж двадцать штук. Большинство из них касается покупателей iPhone, но некоторые относятся и к продавцам, которых тоже пытаются обмануть с нерадующей регулярностью.



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

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

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

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

В последнее время я довольно часто натыкаюсь на данную теорему. Она довольно давно доказана и про нее много чего написано. Однако каждый раз когда я натыкаюсь на распределенную систему, претендующую в описании на CA в терминах данной теоремы, т.е. систему в которой жертвуют Partition Tolerance в угоду Consistency и Avalability, я зависаю, так как хоть убейте не могу себе представить такого зверя. После долгих раздумий я все же пришел к выводу, что такая система бессмысленна, о чем и хочу порассуждать в данном топике.

Как только я заинтересовался lock-free алгоритмами, меня стал мучить вопрос – а откуда взялась необходимость в барьерах памяти, в «наведении порядка» в коде?
Конечно, прочитав несколько тысяч страниц руководств по конкретной архитектуре, мы найдем ответ. Но этот ответ будет годен для этой конкретной архитектуры. Есть ли общий? В конце концов, мы же хотим, чтобы наш код был портабелен. Да и модель памяти C++11 не заточена под конкретный процессор.
Наиболее приемлемый общий ответ дал мне мистер Paul McKenney в своей статье 2010 года Memory Barriers: a Hardware View of Software Hackers. Ценность его статьи – в общности: он построил некоторую упрощенную абстрактную архитектуру, на примере которой и разбирает, что такое барьер памяти и зачем он был введен.
Вообще, Paul McKenney – известная личность. Он является разработчиком и активным пропагандистом технологии RCU, которая активно используется в ядре Linux, а также реализована в последней версии libcds в качестве ещё одного подхода к безопасному освобождению памяти (вообще, о RCU я хотел бы рассказать отдельно). Также принимал участие в работе над моделью памяти C++11.
Статья большая, я даю перевод только первой половины. Я позволил себе добавить некоторые комментарии, [которые выделены в тексте так].

В предыдущей статье мы заглянули внутрь процессора, пусть и гипотетического. Мы выяснили, что для корректного выполнения параллельного кода процессору необходимо подсказывать, до каких пределов ему разрешено проводить свои внутренние оптимизации чтения/записи. Эти подсказки – барьеры памяти. Барьеры памяти позволяют в той или иной мере упорядочить обращения к памяти (точнее, кэшу, — процессор взаимодействует с внешним миром только через кэш). “Тяжесть” такого упорядочения может быть разной, — каждая архитектура может предоставлять целый набор барьеров “на выбор”. Используя те или иные барьеры памяти, мы можем построить разные модели памяти — набор гарантий, которые будут выполняться для наших программ.

В этой статье мы рассмотрим модель памяти C++11.