Qualcomm — не новичок в мире интегрированной графики. Её линейка Adreno GPU использовалась во многих поколениях SoC Snapdragon для сотовых телефонов. Но компании Qualcomm всегда было тесно в рамках телефонного рынка, она таила амбиции расширить свою мощь и выйти на другой уровень производительности. Сегодня её Snapdragon X Elite выпускается с прицелом на рынок ноутбуков. Adreno тоже переносится на рынок более высокой производительности, на котором есть такие конкуренты, как iGPU Intel Xe-LPG в Meteor Lake и iGPU AMD RDNA 3 в Phoenix.

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

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

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

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

e|-----------------|-----------------|-----------------|-----------------|
B|-----------------|-----------------|-----------------|-----------------|
G|-----3---5-------|---3---6-5-------|-----3---5-----3-|-----------------|
D|-5---3---5-----5-|---3---6-5-------|-5---3---5-----3-|---5-------------|
A|-5-------------5-|-----------------|-5---------------|---5-------------|
E|-----------------|-----------------|-----------------|-----------------| <- верх

Что такое One Million Checkboxes?

В чём состоит проблема​

Из всех последних изменений, которые будут внедрены в ECMAScript, моим любимым с большим отрывом от остальных стало предложение Temporal. Это предложение очень прогрессивное, мы уже можем воспользоваться этим API при помощи полифила, разработанного командой FullCalendar.

Этот API настолько невероятен, что я, наверно, посвящу несколько постов описанию его основных возможностей. Однако в первом посте я расскажу об одном из его главных преимуществ: у нас наконец появился нативный объект, описывающий Zoned Date Time.

Но что же такое Zoned Date Time?

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

«В общем случае, когда исходная строка умещается в конечный буфер, strlcpy будет обходить строку только один раз, а strlen + memcpy будут обходить её дважды».

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

Недавно я получил по почте от Сэма Джонсона этот вопрос. Вот слегка отредактированное письмо Сэма:

«Возьмём для примера этот код в локальной области видимости функции:

int a;

a = 5;

Многие люди считают, что инициализация происходит в строке 1, потому что веб-сайты наподобие cppreference дают такое определение: "Инициализация переменной предоставляет его начальное значение на момент создания".

Однако я убеждён, что инициализация происходит в строке 2, потому что [в разных хороших книгах по C++] инициализация определяется как первое существенное значение, попадающее в переменную.

Можете ли вы сказать, какая строка считается инициализацией?»

Отличный вопрос. На Cppreference написано правильно, и для всех классовых типов ответ прост: объект инициализируется в строке 1 вызовом его стандартного конструктора.

Но (а вы ведь знали, что будет «но») для локального объекта фундаментального встроенного типа наподобие int ответ будет... чуть более сложным. И именно поэтому Сэм задал этот вопрос, ведь он знает, что язык достаточно свободно обращается с инициализацией таких локальных объектов по историческим причинам, имевшим в то время смысл.

Короткий ответ: вполне допустимо говорить, что переменная получает своё исходное значение в строке 2. Но заметьте, что я намеренно не сказал «Объект инициализируется в строке 2», к тому же и код, и этот ответ обходят молчанием более важный вопрос: «Ну ладно, а что, если код между строками 1 и 2 попробует считать значение объекта?»

В декабре 2023 года я выпустил 175 Pixel Font Megapack, за которым вскоре последовали 42 отдельных пака для каждого из семейства шрифтов. Я создал собственный тулчейн для генерации, тестирования и развёртывания этих шрифтов... на Rust! В посте я расскажу об этом процессе.

Примерно полгода назад математическое сообщество услышало новость о том, что исследователи DeepMind создали ИИ-систему, решающую геометрические задачи с Международной математической олимпиады на уровне, близком к золотым медалистам ММО. (Эту новость обсуждали в сабреддите \math, см., например, здесь и здесь.) За этими новостями, как часто бывает с новостями о прогрессе ИИ, последовала волна страха и ужаса, усиленная множеством громких газетных статей с картинками (разумеется, сгенерированными ИИ), на которых искусственные мозги решают ужасно сложные уравнения. По коллективной спине математического сообщества побежали мурашки, снова всплыли на поверхность обычные экзистенциальные вопросы о будущем человеческого интеллекта, а Интернет заполнили мемы о грядущем восстании машин.

Я бы хотел взглянуть на эту тему под новым углом. (Предупреждение: возможно, для вас он не будет новым. Если вы имели дело с евклидовой геометрией, понимаете основы линейной алгебры и внимательно читаете журнал Nature, то могли прийти ко всем этим выводам самостоятельно. Но поскольку некоторые критичные аспекты изложены мелким шрифтом (вероятно, намеренно), я всё равно считаю, что их нужно сделать более очевидными.)

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

Введение

Мы покажем, что система, имеющая лишь команды GNU find и mkdir, полна по Тьюрингу.

Хорошо известно, что команды sed и awk сами по себе полны по Тьюрингу, но мне не удалось найти информации о Тьюринг-полноте find + mkdir.

Доказательство основано на реализации таг-системы.

Мы по порядку рассмотрим реализацию цикла, FizzBuzz и таг-системы.

Отчасти это действенный совет, отчасти — вопрос к читателям.

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

Интересный факт: GPT-4o взимает по 170 токенов за обработку каждого тайла 512x512 , используемого в режиме высокого разрешения. При соотношении примерно 0,75 токенов на слово можно предположить, что картинка стоит примерно 227 слов, что всего в четыре раза меньше, чем в поговорке «картинка стоит тысячи слов».

(Кроме того, взимается 85 токенов за master thumbnail низкого разрешения каждого изображения, а изображения более высокого разрешения разбиваются на множество таких тайлов 512x512, но давайте ограничимся одним тайлом высокого разрешения.)

Но почему же 170? Необычное число, неправда ли? В своих ценах OpenAI указывает округлённые числа, например, $20 или $0,50, а в своих внутренних размерностях — степени двойки и тройки. Почему же в этом случае выбрано число 170?

Числа, которые без объяснений вставляют в кодовую базу, называют в программировании «магическими числами», и 170 кажется очевидным магическим числом.

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

Что если OpenAI выбрала 170 не в рамках своей запутанной стратегии ценообразования, а потому что это в буквальном смысле так? Что если тайлы изображений действительно представлены в виде 170 последовательных векторов эмбеддингов? А если это так, то как реализовано?

Я люблю box-тени.

Четыре года назад я выяснил, что мой процессор M1 может рендерить безумное количество таких теней, поэтому решил извлечь из них максимум, и мне это удалось. Если вам интересно, как пользоваться box-тенями, чтобы создать современный стиль UX, то вы не по адресу. Но если вам нравятся творчество и эксперименты, то продолжайте чтение.

Я хочу поделиться худшими примерами того, что можно сделать при помощи box-теней в одном div. Примерами, которые не должны работать, однако почему-то работают. Но прежде чем приступить, нужно ответить на вопрос: что же такое box-тень?

Я бросил себе вызов: симулировать 1000000 (миллион) частиц на чистом Javascript на телефоне, используя только CPU и добившись 60 FPS.

Поехали.

Задача не особо сложна, если выполнять всю работу на GPU, но правило гласит, что нужно пользоваться только CPU, при этом работая на JS, так что никакого WASM.

Самолёт поднялся на высоту трёх километров. Я вытащил свой ноутбук, надеясь воспользоваться Интернетом, а может, немного поработать, если станет совсем скучно.

Подключившись к Wi-Fi самолёта, я открыл браузер. Страница сетевого логина потребовала ввести данные кредитной карты. Я поискал карту, которая обнаружилась внутри паспорта. В процессе поисков я заметил, что страница логина предлагает бесплатно войти в мой аккаунт программы авиамиль, хотя я пока ни за что ещё не заплатил. Я решил, что это дыра в файрволле. Мне предстоял долгий путь из Лондона в Сан-Франциско, поэтому я решил её исследовать.

Я вошёл в свой аккаунт JetStreamers Diamond Altitude, перешёл на страницу своего профиля и увидел кнопку редактирования. Она выглядела обычно: отбрасываемая тень, скруглённые углы, ничего особенного. С её помощью можно было поменять имя, адрес и так далее.

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

Многие коллеги просили меня выполнить ревью их пул-реквестов, потому что я оставлял комментарии типа «опоздало на две недели» или «мешает развёртыванию критического обновления». Но мои идеи тоже важны, поэтому я надел наушники и включил музыку для концентрации. Я забыл зарядить наушники, поэтому Limp Bizkit начал проигрываться через динамики ноутбука. К счастью, никто из пассажиров не был против, так что мы кайфовали вместе.

Прежде чем получить доступ ко всему Интернету через аккаунт программы авиамиль, мне нужно было написать несколько прототипов. Сначала я думал, что напишу их на Go, но потом понял, что если напишу их на Python, то смогу назвать получившийся инструмент PySkyWiFi. Разумеется, я выбрал второй вариант.

Измерение времени — очень сложная задача. Я выяснил это, набив шишки при попытке запрограммировать расширяемый хронометр для небесных тел Солнечной системы. Сложность в том, что все календарные системы имеют так много правил и исключений, что сборщик календаря, по сути, становится ещё одним языком программирования. Впрочем, мне хорошо знаком закон Завински*, поэтому я постарался избежать создания ещё одного Emacs.

^{*Закон Завински — выдуманный закон computer science, высмеивающий неизбежное разрастание фич. Он гласит, что каждая программа рано или поздно постарается прочитать электронную почту. Стоит отметить, что закон сформулирован в 90-х, поэтому и речь об электронной почте. Кстати, я нашёл хороший веб-сайт с другими законами computer science.}

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

Y2K, Y2038 и другие баги Y2xx — это на самом деле не совсем «баги», а простые переполнения выделенного пространства памяти. Unix и подобные ему компьютерные системы измеряют время, выполняя инкремент секунд в единой целочисленной переменной time_t. Естественно, такой хронометраж назван временем Unix, а 0 в нём означает полночь 1 января 1970 года.

В разных реализациях времени Unix для time_t используются разные типы данных. Когда тип данных достигает своего верхнего предела, он «сбрасывается» или до обратного (отрицательного) значения, или до нуля. В текущей основной ветви ядра Linux используются 64-битные числа со знаком. В таком решении точка сброса приходится на 292 277 026 596 год. Он настанет примерно через 292 миллиарда 277 миллионов 24 тысяч лет.

Но что потом?

Последние несколько дней я пытался найти библиотеку, которая бы позволила мне писать на C++ программы с GUI. Мои требования были довольно просты:

• Достаточно только поддержки Windows

• Разрешено коммерческое использование

• Простая стилизация, в том числе и тёмный режим

• Результатом должен быть единый файл .exe размером меньше 40 МБ без или с минимальным количеством зависимостей

• Написание части программы с GUI не должно занимать больше времени, чем сама функциональность

Critique и Gerrit

У Google есть два собственных инструмента для ревью кода: Critique, используемый большинством инженеров, и Gerrit, — опенсорсный, который продолжают применять в публичных проектах.

(Вы можете сами поэкспериментировать с Gerrit в опенсорсных репозиториях Chromium и Android.)

Дэшборды

Когда инженеры логинятся с утра или когда устраивают перерыв для ревью пул-реквестов, внутри Google называемых change list, или CL, и в Critique, и в Gerrit они работают с дэшбордами, в которых можно легко вкратце просмотреть все актуальные изменения (это похоже на окно пул-реквестов репозитория GitHub, только более сложное и информационно насыщенное).

В дэшборде Gerrit есть единичный поиск, извлекающий такую информацию, как размер изменения и более подробные сведения о статусе CL (три столбца справа).