Hacker News Digest

Стандартный алгоритм Ланцоса для вычисления матричных функций требует значительных ресурсов памяти: хранение n×k базисной матрицы, которая растёт с каждой итерацией. Для задачи с 500 000 переменными и 1000 итерациями это около 4 ГБ только для базиса. В статье представлен двухпроходной вариант алгоритма, требующий всего O(n) памяти ценой удвоения числа матрично-векторных произведений. При грамотной реализации этот подход не только экономит память, но и может работать быстрее для определённых задач.

Автор подробно описывает реализацию на Rust, включая шаги рекуррентного вычисления, итератор для управления состоянием, первый проход (вычисление разложения) и второй проход (восстановление решения). Интересно, что теоретические ожидания производительности не всегда подтверждаются на практике, особенно для средних по размеру матриц. Весь код доступен на GitHub, а технический отчёт с доказательствами и дополнительными экспериментами можно скачать отдельно.

• Обсуждение охватывает редкий случай, когда матрица и векторы помещаются в кэш, но базис не помещается, и показывает, что алгоритм Ланцоша может быть реализован без реортогонализации, что экономит O(n²) памяти и O(n²) FLOP в обмен на O(n) дополнительных итераций.
• Участники обсуждают точность двухпроходного подхода, влияние потери ортогональности на точность и применимость метода, а также то, что влияние на точность может быть меньше, чем погрешность самого алгоритма Ланцоша.
• Также обсуждается выбор языка для реализации алгоритма, причем участники делятся опытом и мнением о том, какие языки лучше всего подходят для высокопроизводительной численной линейной алгебры.
• В конце обсуждение сдвигается к тому, что автор может в будущем опубликовать расширенную версию статьи, и что читатели могут ожидать увидеть ее в будущем.

Инженер с опытом работы в Intel и Sun развенчивает популярные мифы о CPU-кэшах. Многие разработчики ошибочно полагают, что разные ядра могут иметь устаревшие значения в своих кэшах, а ключевое слово volatile в Java заставляет читать/писать данные напрямую в оперативную память. На самом деле, даже одноядерные системы подвержены проблемам конкурентности без правильных синхронизационных конструкций, а volatile-операции могут быть такими же быстрыми, как доступ к L1-кэшу (в 200 раз быстрее, чем к оперативной памяти), а не к основной памяти.

Современные CPU x86 поддерживают когерентность кэшей на аппаратном уровне через сложные протоколы, такие как MESI. Каждая строка данных в кэше помечается одним из состояний: Modified (измененные данные, источник правды), Exclusive (синхронизированные данные, нет копий в других кэшах) или Shared (синхронизированные данные, присутствуют в других кэшах). Понимание этих механизмов помогает лучше проектировать распределенные системы и избегать ложных представлений о производительности и конкурентности.

Here's my favorite practically applicable cache-related fact: even on x86 on recent server CPUs, cache-coherency protocols may be operating at a different granularity than the cache line size. A typical case with new Intel server CPUs is operating at the granularity of 2 consecut

PostgreSQL может быть как чтением, так и записью интенсивной в зависимости от бизнес-логики приложения. Для социальных сетей характерно чтение интенсивное, а для IoT логгеров — запись интенсивная. Определение профиля нагрузки критично для эффективной настройки: чтение интенсивные БД выигрывают от индексации, кэширования запросов и реплик, тогда как запись интенсивные требуют оптимизации хранилищ, управления WAL и дизайна таблиц.

Чтения и записи в PostgreSQL не равны по стоимости: чтение происходит 8kb блоками, часто из памяти, в то время как запись включает WAL, индексы, TOAST таблицы и требует больше ресурсов. Автор предлагает запрос для оценки соотношения чтения/записи на основе внутренних метаданных PostgreSQL, где по умолчанию используется соотношение 5:1 (чтение:запись).

• Обсуждение критикует статью за то, что она не сравнивает PostgreSQL с другими СУБД и не дает практических советов по тюнингу под конкретную нагрузку.
• Участники обсуждают, что статья не учитывает, что большинство приложений имеют смешанную нагрузку на чтение и запись, а не чисто чтение или запись.
• Некоторые комментаторы отмечают, что статья не упоминает OLTP и OLAP, что делает ее менее полезной для практического использования.
• Также обсуждается, что статья не дает ясного определения, что считается "read-heavy" или "write-heavy" в контексте PostgreSQL.
• Наконец, участники обсуждают, что статья не предоставляет конкретных советов по тюнингу PostgreSQL под конкретную нагрузку.

DeepSeek AI выпустила экспериментальную версию своей языковой модели DeepSeek-V3.2-Exp. Это обновление демонстрирует улучшенные возможности обработки естественного языка, включая более точное понимание контекста и генерацию кода. Модель оптимизирована для разработчиков и исследователей, предлагая расширенную поддержку программирования и анализа данных.

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

• Обсуждается значительное снижение стоимости моделей ИИ, особенно у DeepSeek, с акцентом на важность доступности для широкого распространения технологий.
• Поднимаются вопросы о технических особенностях моделей (sparse attention, кэширование) и их влиянии на производительность и стоимость вычислений при больших контекстных окнах.
• Участники спорят о реальной выгоде "дешевых" моделей в рабочих процессах, учитывая необходимость поддержки кэширования провайдером для снижения затрат.
• Высказываются предположения о дальнейшей динамике цен на ИИ, ссылаясь на возможное продолжение стремительного падения стоимости по аналогии с законом Мура.
• Обсуждается открытость и прозрачность платформ (OpenRouter, DeepSeek), включая вопросы о использовании данных для обучения и статусе исходного кода.

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

При изменении количества узлов перемещаются только данные, попадающие в зону между старыми и новыми узлами — примерно M/N элементов вместо всех M. Это обеспечивает стабильность системы: например, при выходе узла из строя его нагрузка равномерно распределяется между соседями, а не вызывает каскадный сбой. Алгоритм широко применяется в кеширующих прокси, распределённых базах данных и CDN для минимизации дисбаланса при масштабировании.

• Предложено использовать rendezvous hashing как более простую и универсальную альтернативу consistent hashing, не требующую виртуальных узлов и поддерживающую взвешенное распределение.
• Упомянуты различные реализации и применения хеширования: CRUSH в Ceph, Lamping-Veach алгоритм, кеш-ориентированная версия для SSD, простая реализация на Clojure.
• Обсуждаются стратегии минимизации перераспределения данных при изменении числа узлов: увеличение числа партиций, метод "power of 2 choices", кластеризация в rendezvous hashing.
• Отмечена опечатка в заголовке исходного поста ("Constitent" вместо "Consistent") и дан совет по её исправлению.
• Затронута историческая справка об основателе Akamai Дэниеле Люине и его трагической судьбе.

Redis показал заметно лучшую производительность по сравнению с Postgres при использовании в качестве кэша. В тестах на чтение Redis обрабатывал больше запросов в секунду, при этом нагрузка на CPU у сервера с Redis была умеренной (~1280mCPU из доступных 2000mCPU), а потребление памяти стабильно держалось на уровне ~3800 МБ. Сервер HTTP стал узким местом в случае Redis, исчерпав свои CPU-ресурсы.

Для Postgres основным ограничением стал CPU самой базы данных, который постоянно работал на максимуме. Это подтверждает, что Redis эффективнее справляется с высоконагруженными сценариями кэширования, особенно когда требуется низкая задержка и высокая пропускная способность операций чтения.

• Критика методологии бенчмарка: сравнение ненастроенных Postgres и Redis считается некорректным, так как Postgres требует тонкой настройки под железо для серьёзных тестов.
• Сомнения в целесообразности использования Postgres как кэша: отсутствие встроенного TTL, нагрузка на основную БД и сложности с вакуумом делают Redis более надёжным решением.
• Подчёркивается важность контекста: для небольших нагрузок (<1000 RPS) и упрощения стека использование Postgres может быть оправдано.
• Замечания о специфике теста: сравнение ограниченного Postgres (2 ядра) с неограниченным Redis, малый размер данных и отсутствие пайплайнинга искажают результаты.
• Обсуждаются альтернативы: использование UNLOGGED таблиц, специализированных клиентов (rueidis) или встроенного кэша приложения вместо распределённого решения.

Контекстная инженерия для AI-агентов — это ключевой подход, позволяющий быстро итеративно улучшать производительность без переобучения моделей. Опыт разработки Manus показал, что вместо обучения end-to-end модели эффективнее использовать способность современных LLM к обучению в контексте, что сокращает цикл улучшений с недель до часов и делает продукт независимым от прогресса базовых моделей.

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

• Предлагается использовать файловую систему как память для агентов через директорию .agent/ для хранения задач, планов и других данных.
• Проводятся параллели между лучшими практиками для AI-агентов и управления кодом: избегать раздувания, не удалять плохие коммиты, не рефакторить слишком часто.
• Отмечается разница в стимулах для кеширования: на фиксированных тарифах выгодно провайдеру, на поминутных — пользователю.
• Рекомендуется простота в инструментарии, согласующаяся с подходом OpenAI Codex, например, использование update_plan для отслеживания прогресса.

Объектные хранилища вроде Amazon S3 стали основой для современных систем данных благодаря почти неограниченной ёмкости, низкой стоимости и высокой долговечности. Однако их высокая задержка и стоимость каждого запроса создают серьёзные проблемы для приложений, требующих низкой задержки, таких как потоковые системы вроде RisingWave. Задержки в сотни миллисекунд накапливаются при частых чтениях, делая систему медленной и дорогой.

Для решения этой проблемы разработан гибридный кеш Foyer на Rust, объединяющий память и локальный диск. Он снижает количество обращений к S3, ускоряя доступ к горячим данным в памяти и тёплым — на диске, что сокращает задержки и затраты. Архитектура Foyer включает шардированный кеш в памяти для высокого параллелизма и дисковый кеш с эффективным управлением данными, координируемые единым компонентом. Это позволяет достичь баланса между скоростью и ёмкостью, критически важного для реального времени.

• Обсуждение библиотеки Foyer для гибридного кеширования (память + диск) и сравнение с альтернативами (CacheLib, rclone, S3 Mountpoint, AWS Storage Gateway).
• Вопросы о производительности S3 и целесообразности кеширования из-за задержек и стоимости запросов.
• Технические детали реализации: инвалидация кеша, запись в S3, поведение в гибридном и in-memory режимах.
• Проблемы с работой сайта Medium (модальные окна, блокировка прокрутки) в Firefox.
• Критика формата комментариев и призыв к содержательным обсуждениям.

• Сделал блог-фреймворк на XSLT: демо, код.
• Зачем? Для себя. После пары «вайб-промптов» понял, что 20-летний стандарт покрывает всё, что надо.
• Хочу: писать чистый HTML, без WYSIWYG и Markdown; RSS «из коробки»; единый шаблон на все посты; немного JS для картинок и тем.
• XSLT = один файл-шаблон, XML-контент. Браузер сам превращает XML в HTML. RSS тоже XML, поэтому тот же индекс используется и для ленты.
• Публикация: создал пост, добавил в index.xml, залил — всё. Без сборок и бэкенда.

• Участники вспомнили XSLT как способ превращать XML в HTML прямо в браузере, но большинство считают технологию устаревшей и медленной.
• Предложено заменить RSS на Atom из-за более чистого формата дат и лучшей поддержки.
• Некоторые используют XSLT на сервере (PHP, SaxonJS), где он работает быстро и безопасно.
• Браузеры удаляют XSLT из-за рисков безопасности и низкого спроса; IBM предложила свой JIT-движок, но его вряд ли примут.
• SEO и кэширование вызывают сомнения: динамически собранные страницы могут быть плохо проиндексированы.

Как работает технология «мультиплеера» в Figma

Основная идея
Figma позволяет десяткам дизайнеров одновременно работать над одним файлом без конфликтов. Это достигается за счёт оперативной синхронизации изменений и разрешения конфликтов на лету.

Архитектура

• WebSocket-соединение — каждый клиент держит постоянное соединение с сервером.
• Операционные преобразования (OT) — любое действие (перемещение слоя, изменение текста) описывается как операция. Сервер применяет её и рассылает всем клиентам.
• Дельты и патчи — вместо полной передачи файла отправляются только изменения, что экономит трафик и ускоряет работу.

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

Производительность

• Дерево объектов хранится в памяти браузера и обновляется по мере поступления операций.
• Сжатие и батчинг — несколько операций объединяются в один пакет, чтобы снизить нагрузку на сеть.
• Кеширование — сервер хранит последние состояния файлов, чтобы быстро «догнать» клиента, который только подключился.

Безопасность и надёжность

• Все операции логируются и могут быть отменены (undo/redo).
• Данные шифруются при передаче и хранятся в зашифрованном виде.
• Регулярные снепшоты защищают от потери данных при сбоях.

Итог
Технология «мультиплеера» превращает Figma в «Google Docs для дизайна», где коллаборация происходит без конфликтов и задержек.

• Участники делятся ссылками на материалы Linear, Automerge, Croquet и другие решения для реал-тайм синхронизации.
• Обсуждают, насколько сложной остаётся задача и какие новые инструменты (Liveblocks, Electric SQL, Rocicorp Zero) делают её доступнее.
• Спорят о терминологии «multiplayer» и о том, насколько часто пользователи действительно одновременно редактируют дизайн.
• Отмечают, что Figma пошла на радикальные меры: собственный WebGL-рендерер и протокол, отказавшись от готовых библиотек.
• Шутят о случайном переключении сайта из тёмной в светлую тему при прокрутке и о «figma balls».