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

Главная ошибка была в том, что ты в это вообще ввязался — в этом никаких сомнений.

Ещё когда я впервые взялся проходить курс по C++ несколько лет назад, меня учили, что, если я не предоставлю собственного конструктора, то компилятор сам подберёт ему замену — своего рода конструкторы, действующие по умолчанию. Я решил подробнее в этом разобраться, особенно меня волновали случаи, которые выглядят примерно так:

Недавно у нас в команде зашла дискуссия о неопределённом поведении (UB) в C. Напомню для тех, кто не знает: если мы пишем такой код, эффект от выполнения которого (и события в процессе его выполнения) строго не определён в спецификации языка, то возникает неопределённое поведение. Таким образом, встретив такой код, компилятор может действовать по собственному усмотрению, и нет никаких гарантий, что выполнение этого кода пойдёт по предсказуемому пути. Следовательно, нужно избегать неопределённого поведения любой ценой, поскольку мало того, что оно может приводить к глюкам программы, но и часто становится источником уязвимостей и угрозой безопасности. Примеры кода, в котором проявляется неопределённое поведение: выход за границы массива при его индексировании, целочисленное переполнение, деление на ноль, разыменование указателя на null [1].

Компиляторы нередко пользуются неопределённой семантикой языка, чтобы делать те или иные допущения о программе. Например, если написать что-то вроде int x = y/z, компилятор может предположить, что z не может быть равно нулю, так как деление на ноль приводит к неопределённому поведению, а программист явно не собирался писать такой код. На основе этой информации он может попытаться далее оптимизировать программу так:

Присаживайтесь поудобнее и послушайте стариковскую байку: что случилось, когда я попросил у Rust слишком многого.

Допустим, вы хотите написать на Rust новую библиотеку. Всё, что для этого требуется — обернуть её в публичный API, через который будет предоставляться доступ к какому-то другому продукту, например, в Spotify API или, может быть, в API базы данных, скажем, ArangoDB. Не так это и тяжело: в конце концов, вы не изобретаете ничего нового, вам не приходится иметь дело со сложными алгоритмами. Поэтому вы полагаете, что задача решается относительно прямолинейно.  

Вы решаете реализовать библиотеку с применением async. Работа, которая будет выполняться с помощью вашей библиотеки, заключается в основном в выполнении HTTP-запросов, обслуживающих ввод/вывод, поэтому применять здесь async действительно целесообразно (кстати, это одна из тех фишек, благодаря которым сегодня так востребован Rust). Вы садитесь писать код — и вот, через несколько дней у вас готова версия v0.1.0. «Приятно», — думаете вы, как только cargo publish заканчивается успешно и загружает вашу работу на crates.io.

Проходит несколько дней, и вам прилетает новое уведомление с GitHub. Оказывается, кто-то открыл тему:

Как говорится, «не будите во мне ботана». Иногда кто-нибудь беспечно задаст мне, казалось бы, невинный вопрос — и я убиваю следующие несколько часов (в описываемом случае — дней), чтобы полноценно сформулировать ответ. Обычно всё это заканчивается с моей стороны очередной филиппикой на mastodon или в каком-нибудь приватном чате. Но на сей раз не буду этим ограничиваться и напишу целый пост.

Вот с какого невинного вопроса всё началось:

А почему UID начинаются с 0, но PID начинаются с 1?

Если совсем коротко: в Unix PID (идентификаторы процессов) начинаются именно с 0! PID 0 просто не отображаются в пользовательском пространстве через традиционные API.  PID 0 запускает ядро, а затем практически уходит на покой, только немного участвует в работе планировщика процессов и в управлении питанием. Кроме того, на просторах Интернета доминирует заблуждение о PID 0, всё из-за одного ошибочного утверждения в Википедии, которому уже 16 лет.

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

Но, конечно же, любой желающий может просто загуглить, что такое PID 0, верно? Зачем мне вообще всё это писать?

Я фулстек-разработчик, индивидуальный предприниматель. По моему опыту, один из самых востребованных классов проектов, за разработкой которых к нам обращаются, — приложение для работы в режиме реального времени. Конечно, вам такие приложения известны: WhatsApp, Discord, Slack, т.д. При разработке приложений для работы в режиме реального времени следует учитывать различные факторы, в частности, масштабируемость, отказоустойчивость, отзывчивость и распределённость. Это задача не из лёгких, в особенности для небольшой команды или разработчика‑одиночки.

Но что если бы я вам сказал… что можно создавать приложения для работы в режиме реального времени, которые можно масштабировать более чем на миллион пользователей силами всего нескольких разработчиков? К тому же, такие приложения можно было бы развёртывать почти без задержек и ценой минимальных затрат. Здесь я имею в виду, что для этого нужно освоить секретное оружие под названием «Виртуальная машина Erlang» или BEAM (Абстрактная машина Богдана/Бьёрна для языка Erlang).

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

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

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

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

От читателя поста ожидается, что он на базовом уровне понимает Rust, обычные структуры данных, а также концептуально представляет, как выделяется память (в стеке и куче).

Дополнение (14.05.2024): Я учёл поступившую обратную связь и подчеркнул, какие идеи объективно плохи, прояснил некоторые отступления и удалил идею о imbl.

Чтобы было проще прослеживать этапы реализации и исследовать код, отсылаю вас к репозиторию, сопровождающему этот пост.

Ещё одна причуда Python, исследование её подноготной и попытка понять, почему так случается.

Недавно в сети X был популярен этот твит (см. скриншот), и я обратил внимание. Это очередной сюрприз в Python, связанный с характерными для него уникальными деталями реализации.

Как-то раз Бобу поручили построчно обработать текстовый файл. Боб решил решить эту задачу на C++, так как известно, что мало найдётся языков, которые могли бы потягаться с C++ в скорости. Поскольку C++ для Боба — дело новое, неосвоенное, он решил погуглить спросить ChatGPT, какой способ построчного считывания файла на C++. Для этого потребовалось немного затравочного кода, зато не пришлось пролистывать бесконечные страницы документации по стандартной библиотеке C++.

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

💡

После этого Боб выложил окончательную версию кода на GitHub в файле TextFileReader.h, и вы смело можете использовать его в ваших проектах.

Замечания о математике, алгоритмах и методах, применяемых при компьютерной симуляции флюидов (например, огня и дыма) в режиме реального времени.

Исходный код к этой статье выложен на GitHub.

Огонь как явление очень интересен с точки зрения компьютерной графики. Раньше огонь было принято имитировать. Например, в фильме «Властелин колец» Питера Джексона для изображения огня использовались спрайты с огромным количеством дыма (на тот момент симуляция флюидов обходилась слишком дорого, даже при бюджете блокбастера). Когда требовалось моделировать огонь в режиме реального времени, например, в видеоиграх, использовались почти исключительно нефизические подходы.

WebGPU — это мощный GPU-API для веба, поддерживает продвинутые рендеринговые конвейеры и вычислительные конвейеры GPU. WebGPU ключевым образом отличается от WebGL своей поддержкой вычислительных шейдеров и буферов хранения данных. В WebGL такие возможности отсутствуют, а WebGPU, в свою очередь, позволяет целиком выполнять в браузере мощные приложения, требующие вычислений на GPU. Речь может идти о самых разных приложениях, от GPGPU (напр., симуляции, обработка/анализ данных, машинное обучение, т.д.) до конвейеров рендеринга на основе GPU-вычислений — а также о многих других приложениях в этом спектре.

В этой статье мы оценим вычислительную мощность WebGPU, сравнив её с показателями Vulkan. Для этого мы реализуем классический алгоритм «марширующие кубы» (Marching Cubes) для WebGPU. Алгоритм марширующих кубов почти без оговорок относится к чрезвычайно параллельным, в составе этого алгоритма выполняется два глобальных шага редукции, необходимых для синхронизации местоположений рабочих элементов и вывода потоков. Поэтому данное решение — отличный вариант GPU-параллельного алгоритма, который стоит первым делом попробовать на новой платформе. Дело в том, что он достаточно сложен, чтобы API испытал давление сразу по нескольким направлениям сверх элементарных параллельных операций диспетчеризации в ядре. При этом он не столь сложен, чтобы на его реализацию требовалось существенное время, а также он не превращается в узкое место из-за ограничения производительности ЦП.

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

Язык Zig отлично подходит для оптимизации производительности, а также предоставляет детализированный контроль над памятью и потоком операций. Чтобы было ещё интереснее, я проставил контрольные точки, по которым сравнил мою реализацию Ethereum с официальной реализацией на Go.

Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости.

Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году. Трёхзвёздочные указатели, восьмиуровневые зависимости, C-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?

При работе с современными веб-приложениями реального времени незаменима возможность отправлять события с сервера на клиент. Именно этой необходимостью продиктовано то, что за годы работы было изобретено несколько методов для этой цели, каждый с собственным набором достоинств и недостатков. Первоначально единственным вариантом был длинный опрос. Затем в качестве альтернативы появились веб-сокеты — более надёжное решение для двунаправленной коммуникации. Вслед за веб-сокетами появились события, отправляемые сервером (SSE), более простой метод, обеспечивающий однонаправленную связь от сервера к клиенту. Забегая вперёд, сейчас разрабатывается ещё и протокол WebTransport, который может тем более изменить ландшафт этой области, обеспечивая более эффективный и гибкий подход, располагающий к масштабированию. В некоторых нишевых случаях можно присмотреться и к технологии WebRTC, предназначенной для работы с событиями в направлении сервер-клиент.

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

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

Эта статья написана в схожем ключе, но нас наиболее интересует, возможно ли напрямую квантовать предобученные модели при экстремальных настройках, в том числе, при двоичных весах (0 и 1). Уже имеющиеся работы нацелены на обучение моделей с нуля. Но в открытом доступе сейчас достаточно много отличных предобученных моделей, таких как Llama2. Более того, обучение с нуля — это ресурсозатратная задача в пересчёте как на вычисления, так и на данные, поэтому такие подходы не слишком доступны в свободном сообществе.

В этой статье мы подробно разберём крайне малоразрядное (2 и 1-разрядное) квантование предобученных моделей с применением HQQ+. HQQ+ — это адаптация HQQ (полуквадратичного квантования), в которой для повышения производительности используется адаптер с низкой размерностью. Наши результаты показывают, что при обучении лишь небольшой части весов в верхней части HQQ-квантованной модели (даже одноразрядной) качество вывода значительно возрастает, такая модель может даже превосходить небольшие модели полной точности.

Модели находятся на Hugging Face: 1-разрядная, 2-разрядная.

Привет! Я всегда мечтала, чтобы в инструментах для работы с командной строкой заранее сообщалось, насколько популярны те или иные конфигурационные опции, предусмотренные в них, например:

o    «В принципе, никто этим не пользуется»

o    «Этой опцией пользуется 80% аудитории, стоит ознакомиться»

o    «У этой опции предусмотрено 6 возможных значений, но в реальной практике применяется всего 2 из них».

Так что я решила спросить пользователей Mastodon, какие у них любимые опции конфигурации git:

А какие опции git config вы больше всего любите выставлять? В настоящее время у меня в ~/.gitconfig установлены только git config push.autosetupremote true и git config init.defaultBranch main, вот интересуюсь, а что выставляют другие люди.

Как обычно, получила КУЧУ отличных откликов и так узнала множество очень популярных опций конфигурации git, о которых ранее никогда не слышала.

Далее перечислю их по порядку, при этом (очень примерно) попытаюсь начать с наиболее популярных.

Все описанные опции документированы на странице man git-config, а также на этой странице.

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

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

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

В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.

Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:

«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»

Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.

Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.

Векторные представления (эмбеддинги, векторы) — это по‑настоящему приятный инструмент, но в любом рассказе о векторных представлениях эта техника скрыта за ворохом каких‑то страшных словес.

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

Я выступал с лекцией о векторных представлениях на конференции PyBay 2023. Эта статья — улучшенная версия той самой лекции, и она должна быть интересна сама по себе, даже если не смотреть видео.

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

38-минутная видеоверсия

Вот видеоверсия той лекции, которую я прочитал на PyBay.

Python и Go отличаются по свойствам, и поэтому могут дополнять друг друга.

Существует распространённое заблуждение, будто простой и лёгкий — это одно и то же. В конце концов, если некий инструмент легко использовать, то и его внутреннее устройство должно быть просто понять, разве не так? И обратное тоже верно, да? На самом деле, всё как раз наоборот. В то время, как по духу оба понятия указывают на одно и то же (итог со стороны кажется лёгким), на практике такая поверхностная лёгкость достигается огромной подкапотной сложностью.

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

Эти фичи явственно смахивают на внутренние механизмы баз данных. Действительно, в любом достаточно сложном клиентском приложении программисту непременно придётся реализовывать такое множество фич для управления данными, что эта работа будет напоминать построение предметно-ориентированной базы данных. Такая дополнительная сложность удваивается в каждом проекте, над которым мы работаем, поэтому приходится тратить время на решение бизнес-проблем, а радовать пользователя – уже как успеем.

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