Готофобия – это боязнь использовать инструкции goto. Обычно возникает из-за непонимания и незнания контекста этой проблемы, а также из-за историй о незапамятных временах в истории программировании. Разработчики, страдающие готофобией, готовы жертвовать удобочитаемостью своего кода, только бы не прибегать к goto.

Ещё в мае 2022 года я переориентировал пару команд в Google на разработку полностью гомоморфного шифрования (вот объявление об этом в рассылке). С тех пор я участвовал в работе над многими проектами в этой области, в частности, руководил поддержкой на github.com/google/fully-homomorphic-encryption – это опенсорсный ПГШ-компилятор для C++. В этой статье даётся вводная информация о том, как при помощи этого инструмента компилировать программы с расчётом на ПГШ. Также пробежимся по тому, из чего этот компилятор состоит.

Весь минувший месяц я глаз не мог оторвать от языка программирования Rust, ведь его конёк – создание современных программ, обеспечивающих безопасную работу с памятью. За прошедшие годы появилось несколько языков, которые позиционировались как «инструмент что надо» для написания надёжного бекенд-софта. Постепенно маятник качнулся от Java/C++ к Go и Rust, выстроенных на многолетних разработках по теории языков программирования. Суть – в создании инструментов, которые были бы эффективны именно в наш век.

В сообществе игры «Жизнь», изобретённой Джоном Конвеем, отмечали знаковое достижение, совершённое 9 ноября 2022 года. Идея, на воплощение которой ушли годы – проект «обратный шестометатель» — наконец дошла до той стадии, когда в наличии имелись все компоненты для этой сущности, позволявшие достичь заявленной цели.  

Цель проста. Выбираем любой шаблон, который можно собрать в «Жизни» - например, Тихоходку. Начинаем с небольшого количества шаблонов (пока 15), так, чтобы в пустой вселенной для «Game of Life» присутствовали только они. С течением времени из этих глайдеров должен собраться данный шаблон. Никакого остаточного мусора, разбросанной основы – только чистый синтез того, что вы выберете. Данный пост рассказывает, как устроен этот механизм, как мы до него дошли, и почему это так круто.

Привет всем, в эфире Асахи Лина!✨

marcan попросил меня написать статью о M1 GPU, и вот она готова ~! Это был долгий проект, растянувшийся на несколько месяцев, и было о чём поведать, так что, надеюсь, вам понравится!

Такая история всегда начинается одинаково. Вам показывают демку, в которой набор проблем, ранее казавшийся сложным, решается на раз — достаточно запустить некий Волшебный Инструмент. Зачастую такой инструмент рекомендуют Большие Тузы из отрасли, либо не только рекомендуют, но и сами поддерживают. У вас в организации отыскиваются коллеги, ратующие за то, чтобы немедленно взять эту технологию на вооружение. Буквально наутро этот новый инструмент приравнивается к «решению всех наших проблем».

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

К тому моменту, как его обсуждение доходит до руководителей высшего звена, инструмент уже раскручен в пресс-релизах. Вы видите статьи в духе «Технология X морально устарела, время обзаводиться Волшебным Инструментом». Те из вас, кто не так давно работает в технической отрасли, могут предположить, что, пожалуй, была сделана какая-то добросовестная оценка, призванная проверить, в самом ли деле Волшебный Инструмент так хорош, или безопасен, или уместен именно в вашем бизнесе. Нет, вы ошибаетесь. 

Часто приходится слышать, что важность отличий между наборами инструкций на современных компьютерах преувеличена и, в самом деле, сложно не согласиться с таким наблюдением. Поскольку стандартная программа на 90 % состоит из простейших инструкций для АЛУ, загрузки и сохранения, а также инструкций ветвления, а также с учётом, что на таком базовом уровне разбежки между различными наборами команд очень невелики, такой вывод просто напрашивается.

Но RPCS3, эмулятор приставки Sony PlayStation-3 - не просто обычная программа. Даже если вам не доводилось работать с самим эмулятором, вам наверняка приводили RPCS3 в пример как образец потребительского ПО, в котором используются сильные стороны AVX-512. В этой статье я расскажу, почему именно новые инструкции и возможности, введённые в семействе AVX-512, так полезны для эмуляции PS3. В некоторых ситуациях использование 512-разрядных инструкций может положительно сказываться на RPCS3, но в этом посте будет рассказано, почему новые инструкции полезны и для 128-разрядных, и для 256-разрядных конфигураций.

Мой мадригал тем инструментам разработки, которые изменили мою жизнь

Программирование стало гораздо более многогранным ремеслом с тех пор, как в середине 1990-х я впервые попробовал AmigaBASIC. В те времена еще можно было купить один большой том о компьютере, на котором вы программируете – и там бы нашлось 99% всей нужной информации. Эта книга, где на множестве страниц уголки загнуты в качестве закладок, обклеенная стикерами, лежала бы у вас под рукой, пока вы вбивали бы команды в монохромный текстовый редактор.

Современная книга по клиентскому веб-фреймворку может быть толще, чем во времена программирования под C64 бывали мануалы, достаточные для создания полноценных игр. С другой стороны, сегодня информация по любым платформам, для которых требуется писать код, находится буквально в одном клике.

Сегодня никто бы больше и не подумал покупать документацию по разработке – и Microsoft, и Apple свободно выкладывают свою документацию в Интернете для всех желающих. А что говорить о проектах с открытым исходным кодом!

Во времена npm, PyPI и GitHub сложно объяснить, насколько неоднозначным решением (которое требовалось всесторонне обдумывать) раньше считалось потребовать хоть какие-нибудь возможности, которые выходили бы за рамки функционала операционной системы. Часто вместе с продуктом приходилось сдавать и все его зависимости.

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

Для предоставления такого колоссального объёма данных эксплуатируется набор кластеров NoSQL-баз данных (на основе ScyllaDB), и каждый из этих кластеров является источником истины для соответствующего множества данных. Поскольку Discord — это платформа для чатов в реальном времени, требуется, чтобы базы данных справлялись с плотным потоком запросов настолько быстро, насколько возможно.

SQL — концептуально странный язык. Вы пишете ваше приложение на одном языке, скажем, на JavaScript, а затем направляете базе данных команды, написанные на совершенно другом языке — SQL. После этого база данных компилирует и оптимизирует эту команду на SQL, выполняет её и возвращает вам данные. Такой метод кажется ужасно неэффективным, но, всё-таки, ваше приложение может проделывать сотни таких операций в секунду. Просто безумие!

Но на самом деле всё ещё страннее.

Как-то раз коллега поделился с автором этой статьи одной байкой со времен поддержки Windows XP. Крупный производитель компьютеров обнаружил, что, если включить композицию “Rhythm Nation” Джанет Джексон, то некоторые модели ноутбуков выходят из строя. Не хотелось бы оказаться в той лаборатории, которую, должно быть, обустроили для исследования этой проблемы. Это вам не художественная критика.

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

А затем выяснилось кое-что крайне причудливое: при воспроизведении этого видео с одного ноутбука можно было сломать ноутбук, стоящий рядом – на котором, однако, эта запись не играла!

Что же там творилось?

Меня все сильнее раздражает, сколько людей готовы записывать в REST API любой интерфейс на основе HTTP. Сегодня приведу в качестве примера SocialSite REST API. Это же вызовы удаленных процедур (RPC). Он просто выкрикивает RPC. Связность между элементами на экране настолько сильная, что это творение заслуживает рейтинга X.

Взявшись исследовать некоторые непонятки с производительностью в Chrome, я обнаружил, что Microsoft распараллелили обнуление памяти, и иногда работа из-за этого сильно замедляется. В Windows 11 такое замедление можно частично побороть, но в последних версиях Windows Server — где этот фактор наиболее важен — баг живее всех живых.

Но есть и хорошие новости: по-видимому, проблема актуальна только на тех машинах, где много процессоров. Под «много» я понимаю «96 или более». Поэтому вашего ноутбука проблема не касается. И даже 96-процессорные машины могут сталкиваться с ней не так часто. Но я нашел и другие факторы, из-за которых может быть спровоцирована такая неэффективность, если сложится подходящая ситуация — и обомлел. Вы бы посмотрели, как разбазаривается мощность ЦП. 

Окей – давайте перейдем к деталям.

За два года с тех пор, как я опубликовал статью I want off Mr Golang's Wild Ride, она вновь и вновь всплывала на Reddit, Lobste.rs, на HackerNews и в других местах.

Всякий раз дискуссия выходит к одним и тем же ответам:

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

Конкурентность сложно как следует наладить, как минимум, тем из нас, кому не повезло писать на языках, непосредственно открывающих нутро конкурентного аппаратного обеспечения: речь о потоках и разделяемой памяти. Не менее сложно организовать конкурентность так, чтобы она работала и правильно, и быстро. Все, что вы знаете об оптимизации однопоточного кода, зачастую вам не поможет. На микроуровне (отдельные инструкции) просто невозможно применить обычные правила, актуальные для μ-операций, цепочек зависимостей, пределов пропускной способности и т.д. При конкурентности правила другие.

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

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

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

Как вы могли заметить, я давно работаю с процессором STM32 ARM при помощи Mbed. Были времена, когда Mbed был весьма прост, но многое изменилось с тех пор, как он превратился в Mbed OS. К сожалению, это означает, что многие примеры и библиотеки, которые вы могли бы найти, с относительно новой системой работать не будут.

Мне нужен был поворотный энкодер — и я вытянул дешевый экземпляр из одного набора «49 плат для Arduino», какие продаются повсюду. Уверен, это не самый филигранный поворотный шифратор из имеющихся в природе, но для поставленной задачи его должно было хватить. К сожалению, в Mbed OS нет драйвера для такого датчика, а первые несколько сторонних библиотек, которые я нашел, либо работали по принципу опроса, либо не компилировались под последнюю версию Mbed. Разумеется, для чтения поворотного энкодера никакой магии не требуется. Но насколько сложно самостоятельно написать для него код? В самом деле, довольно сложно. Подумал, поделюсь моим кодом и расскажу, как к этому коду пришел.

Много воды утекло с тех пор, как я в последний раз участвовал в собеседовании по программированию как соискатель. Но до сих пор помню особенно полюбившийся мне вопрос с такого собеседования. Дело было в MemSQL, году так в 2013. (Они даже успели переименоваться, поэтому, полагаю, конкретно этот вопрос они на собеседовании уже не задают. Не чувствую вины за то, что выдаю его. Это отличная история, которая также кажется мне поучительной; просто раньше я о ней никогда не писал).

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

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

А вы знали, что бывает такая атака на компилятор через бэкдор, защититься от которой невозможно? В этом посте я покажу вам, как реализовать такую атаку менее чем в 100 строках кода. Кен Томпсон, создатель операционной системы Unix, рассказывал о такой атаке еще в 1984 году в своей лекции по поводу присуждения Премии Тьюринга. Такая атака по-настоящему опасна и сегодня, причем, не известно решений, которые обеспечивали бы полную неуязвимость от нее. Вирус  XcodeGhost, открытый в 2015 году, проводит атаку через бэкдор по методу, предложенному именно Томпсоном. Я покажу здесь атаку Томпсона на языке   C++, но этот пример легко адаптировать для любого другого языка. Дочитав эту статью, вы крепко задумаетесь, а осталось ли у вас вообще какое-то доверие компилятору.

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

Встречайте, вот и Go 1.18, а с ней – первый релиз долгожданной реализации дженериков, наконец-то готовых к реальному использованию в продакшене. Дженерики – это весьма востребованная возможность, давно вызывающая жаркие споры в сообществе Go. С одной стороны, самые голосистые беспокоятся по поводу сложности, которую привносят дженерики. Их страшит неизбежная эволюция Go, которая доведет его либо до многословия как в энтерпрайз-версии Java, со своими обобщенными фабриками, либо, самое страшное, превратит Go в вырожденный HaskellScript, где if-ы придется заменить монадами. Положа руку на сердце, оба этих опасения могут быть преувеличенными. С другой стороны, поборники дженериков считают, что дженерики критически важны для масштабного внедрения чистого кода, пригодного для многоразового использования.

Автор этой статьи не принимает ни одну из сторон в данных дебатах и не дает рекомендаций, где и в каких случаях использовать дженерики в Go. Напротив, эта статья призвана осветить запутанный случай с дженериками в Go с третьей стороны: с точки зрения системных программистов, которые воодушевлены не дженериками как таковыми, а мономорфизацией и тем, как она может сказаться на производительности. Нас таких десятки. Десятки! И мы все имеем изъявить некоторое серьезное разочарование.