• Windows Terminal development focuses on improving throughput and performance, with recent updates significantly boosting speed.
• Users compare terminal performance across platforms, noting macOS's Terminal.app and alternatives like Ghostty, with some pointing to benchmarks showing macOS may lag.
• Feature requests include serial communication support (e.g., Serial/RS232) and better integration with tools like Tera Term, alongside discussions on handling output buffering.
• Some users highlight Windows Terminal's advantages, like WSL integration, while others note limitations compared to Linux/macOS terminals.
• Discussions acknowledge Windows as a multi-purpose OS, not just for gaming, with many developers using it daily for development, especially with WSL.

В функциональном программировании высшие функции вроде map, filter и fold можно определить через reduce, показывая что "всё сворачивается". Эти функции зависят от коллекций лишь через операцию conj, что открывает путь к абстракции. В Clojure это реализуется через трансдьюсеры — функции, принимающие шаг обработки и возвращающие его модифицированную версию.

Трансдьюсеры позволяют создавать переиспользуемые преобразования данных, работающие с различными структурами, от списков до потоков. Их ключевое преимущество — композиция: несколько трансдьюсеров могут объединяться без потери производительности. Реализация поддерживает разные арности (0, 1 или 2 аргумента), что делает их универсальными для различных сценариев обработки данных. Такой подход обеспечивает как переиспользование кода, так и высокую производительность за счет meaningful абстракции.

• Обсуждение началось с предложения рассмотреть альтернативное, более мягкое введение в трансдюсеры как функции a -> List<b>, подчеркивая их полиморфизм и простоту.
• Участники поделились опытом, что новички в Clojure часто переоценивают reduce и пытаются заменить им циклы, что приводит к запутанному коду, в то время как трансдюсеры предлагают более чистый и декларативный подход.
• Сообщество единодушно подтвердило, что трансдюсеры действительно делают код более выразительным и устойчивым к ошибкам, особенно когда дело касается обработки коллекций.
• В итоге обсуждение сошлось на том, что хотя трансдюсеры и требуют некоторого переосмысления привычных паттернов, их преимущества в выразительности и надежности делают их ценным инструментом для Clojure разработчика.

Команда Skald переписала бэкенд с Python на Node.js всего через неделю после запуска, идя против стандартного совета стартапам сначала "делать то, что не масштабируется". Основная причина — сложность с асинхронностью в Python, особенно при работе с Django. Автор отмечает, что писать качественный асинхронный код на Python "очень сложно и неинтуитивно", в отличие от JavaScript с его event loop или Go с goroutines.

Django до сих пор не имеет полной поддержки асинхронности: нет нативного асинхронного файлового ввода-вывода, ORM не поддерживает async, а для интеграции синхронных и асинхронных функций требуется постоянно писать sync_to_async и async_to_sync. Даже крупные компании вроде PostHog, несмотря на наличие AI-фич, продолжают использовать традиционный WSGI вместо полного перехода на асинхронность. В итоге команда пришла к выводу, что Django скоро начнет создавать проблемы с производительностью даже при небольшом количестве пользователей.

• Обсуждение в основном вращается вокруг того, что Python/async-экосистема остаётся незрелой, а Django-ORM не предназначена для асинхронной работы, что делает выбор между «старым, но проверенным» и «новым, но сырым» неоднозначным.
• Участники спорят, стоит ли жертвовать удобством разработки и экосистемой ради производительности, или же лучше переписать всё на Node/TypeScript, если речь идёт о высоконагруженном REST API.
• Поднимается вопрос о том, что выбор стека влияет на набор инженеров, и что важнее — удобство разработки или производительность.
• Некоторые участники подчеркивают, что важно не только выбрать правильный инструмент, но и уметь его использовать, иначе даже самый современный фреймворк не спасёт от проблем с масштабированием.

• Python-оптимизация часто сводится к выносу «горячих» участков в C/NumPy, а не к микро-оптимизации кода.
• Сам факт, что в CPython «всё является объектом» влечёт за собой неизбежные накладные расходы, которые нельзя убрать без отказа от части философии языка.
• JIT (PyPy) и отсутствие GIL в будущем могут решить 90 % проблем производительности, но это не касается CPython.
• Сообщество в целом согласно с тем, что вместо попыток «оптимизировать» Python-стильный код, стоит либо полностью переписать узкие места на C/Rust, либо вовсе перейти на Julia/Go.

Предоставленный контент — это навигационное меню GitHub для репозитория "samrolken/nokode", без описания самого проекта. На странице отсутствует информация о функционале, целях или особенностях nokode.

В интерфейсе присутствуют стандартные элементы GitHub: поиск, разделы для Enterprise, Pricing, Open Source, Resources и Solutions. Нет ни README, ни кода, ни обсуждений — только базовая структура страницы репозитория.

Для получения информации о проекте потребуется доступ к содержимому репозитория или его документации.

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

Инженер с опытом работы в 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

При оптимизации кастомной ограниченной приоритетной очереди автор столкнулся с парадоксальным случаем, когда уровень оптимизации O3 работал на 123% медленнее, чем O2. Этот результат был подтверждён на процессорах Intel Haswell и AMD Zen 3, что указывает на системную проблему, а не на специфичную для архитектуры. Бенчмарки проводились с использованием criterion, а результаты демонстрировали устойчивую регрессию производительности при повышении уровня оптимизации.

Реализация использует отсортированный Vec с бинарным поиском вместо бинарной кучи, что эффективнее для данного случая из-за требования уникальности id элементов. Ключевую роль играет функция сравнения, работающая с числами с плавающей запятой, которые известны своей сложностью в сравнении. Для анализа производительности автор использовал flamegraph, чтобы выявить разницу в поведении между уровнями оптимизации.

Nice read. Last week I wrote a blog post about two noteworthy cases of O3 being slower than O2 in C++: https://barish.me/blog/cpp-o3-slower/ In the branchy function, id is only compared if distance is equal, and since distance is a random float, this almost never happens and the

Пять лет после выхода первых Mac с чипами M1 показали, что предсказуемые обновления — это именно то, чего мы хотели. Автор статьи цитирует Джона Грубера, который в 2020 году отмечал, как M1 сломал компромисс между производительностью, нагревом и временем работы от батареи. Несмотря на это, некоторые называют M5 «скучным incremental-обновлением», что, по мнению автора, как раз и является целью.

В эпоху PowerPC и Intel Mac иногда годами не получали значительных апдейтов, а проблемы с перегревом и неудачные решения вроде клавиатуры-бабочки были обычным делом. Теперь, когда Apple контролирует собственную silicon-архитектуру, компания может регулярно выпускать чипы с последовательным улучшением производительности и эффективности. Графики Geekbench показывают значительный прирост производительности CPU и GPU от M1 до M5, и для большинства пользователей, не меняющих компьютеры каждый год, каждое обновление будет ощутимым.

Это и есть успех Apple silicon — не революция, а эволюция, которая обеспечивает стабильный прогресс. Назвать такие достижения «скучными» — значит упускать суть и игнорировать то, что мы сами и требовали от Apple после перехода с Intel.

• Пользователи обсуждают, что ежегодные обновления процессоров в MacBook не всегда вызывают восторг, но важно, чтобы покупатели не вынуждены были покупать устаревший продукт без понимания, когда будет обновление.
• Некоторые отмечают, что Apple не предоставляет достаточно новых функций, чтобы оправдать обновление, и что они хотели бы, чтобы Apple сосредоточилась на улучшении программного обеспечения.
• Обсуждается, что Apple Silicon делает возможным запуск локальных моделей ИИ, но не все считают, что это оправдывает ежегодные обновления.
• Участники обсуждают, что Apple не предоставляет достаточно новых функций, чтобы оправдать обновление, и что они хотели бы, чтобы Apple сосредоточилась на улучшении программного обеспечения.

Проект представляет собой набор реализаций бенчмарка "Are-we-fast-yet" на различных языках программирования, включая Oberon, C++, C, Pascal, Micron и Luon. Основная цель - сравнение производительности разных языков через единый тестовый набор. Реализации позволяют разработчикам оценить эффективность каждого языка в стандартных задачах и понять, как современные языки конкурируют с классическими.

Бенчмарк охватывает ключевые алгоритмические задачи, такие как сортировка, обработка строк и математические вычисления. Интересно, что даже в 2023 году некоторые классические языки, как C и Pascal, демонстрируют конкурентоспособную производительность, в то время как более современные языки предлагают разные компромиссы между скоростью и выразительностью кода. Проект предоставляет ценный ресурс для выбора языка программирования под конкретные требования производительности.

• Обсуждение в основном касается языков Oberon и их компиляторов, включая их производительность и репозиторий.
• Участники обсуждают, что репозиторий недавно добавил реализацию на C++, но она оказалась значительно медленнее.
• Также поднимается вопрос о названии Micron — участники считают его плохим выбором, так как может вводить в заблуждение.
• Появляется ссылка на недавно опубликованные результаты тестов производительности.
• Участник под ником «dead» отмечен как неактивный.

Проект h3o представляет собой полную переработку библиотеки Uber H3 на языке Rust, а не просто обертку. Основные цели - упрощение интеграции в Rust проекты (особенно для WASM), создание более безопасного API с использованием строгой типизации, достижение сопоставимой или превосходящей производительности и 100% покрытие API H3 версии 4.0. Для обеспечения качества использовалось дифференциальное тестирование против эталонной реализации, включая 756 тестов, 166 интеграционных тестов, 42 юнит-теста и 15 fuzz-целей.

Бенчмарки, состоящие из 911 тестов, показывают, что в 862 случаях h3o превосходит оригинальный H3 по производительности. В 463 тестах h3o работает в 2-5 раз быстрее, в 117 тестах - в 5-10 раз быстрее, и в 24 тестах - более чем в 10 раз быстрее. Однако в 44 тестах H3 все еще быстрее, особенно при работе с пятиугольными ячейками и преобразованиями координат. Основные оптимизации h3o включают использование предвычисленных таблиц вместо формул на лету и применение битовых операций вместо циклов для достижения постоянного времени выполнения.

• H3/Hexagonal tiling vs. S2/Square tiling: обсуждение сфокусировалось на том, что H3 обеспечивает равные расстояния между соседними ячейками, что важно для анализа данных и моделирования потоков, в то время как S2 не обеспечивает равные расстояния между соседними ячейками. Однако, S2 имеет преимущество в том, что он может быть более эффективен для запросов, которые включают родительские и дочерние ячейки, тогда как H3 может быть более удобен для визуализации и анализа данных, особенно если важно сохранить равные расстояния между ячейками.

• Использование H3 в различных контекстах: обсуждение включало примеры использования H3 в различных контекстах, включая Uber, FCC, ClickHouse, Overture Maps и другие. Это показывает, что H3 используется в различных контекстах, включая телематика, анализ данных, визуализация и хранение данных.

• Сравнение H3 с другими системами: обсуждение также коснулось сравнения H3 с другими системами, включая S2 и другие геометрические системы. Это показывает, что H3 имеет свои уникальные преимущества и недостатки, которые важно учитывать при выборе системы для конкретного применения.

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

Проект hist-rs представляет собой высокопроизводительный утилиту для подсчета уникальных строк, написанную на Rust. Его ключевое преимущество — скорость работы, которая в 25 раз превышает производительность классической команды sort | uniq -c в Unix-системах. Это делает его идеальным инструментом для анализа больших лог-файлов и наборов данных, где важна скорость обработки.

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

• Обсуждение началось с вопроса о производительности различных инструментов для подсчёта уникальных строк в файле, где был упомянут clickhouse-local как самый быстрый способ.
• Участники обсуждали различные инструменты, включая sort, uniq, awk, uniq -c, sort | uniq -c | sort -n, tsv и csv, а также их производительность и использование памяти.
• Были упомянуты такие инструменты как tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, tsort, `tsor

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

В статье демонстрируется сравнительный анализ производительности между UUIDv4 и UUIDv7 через создание двух таблиц для "магазина крабов" с использованием Aiven for PostgreSQL. Авторы предоставляют практические примеры кода для создания сервиса и таблиц, а также функцию для вставки случайных данных. Тесты показывают, что UUIDv7 может значительно улучшить производительность операций вставки по сравнению с UUIDv4, особенно при работе с большими объемами данных.

• UUIDv7 раскрывает время создания записи, что может быть критично для приватности и безопасности, особенно если первичный ключ публично доступен.
• Эксперты рекомендуют использовать UUIDv7 только для внутренних ключей и выставлять отдельный UUIDv4 как публичный идентификатор.
• Но в большинстве случаев, когда выбор между UUIDv7 и v4, важно учитывать, что v7 предоставляет лучшую производительность при вставке и сортировке, но требует дополнительных усилий для защиты приватности.

• Обсуждение показало, что serverless не всегда подходит для высоконагруженных API, особенно если требуется низкая латентность и стабильность.
• Участники отметили, что serverless может быть полезен для MVP или спайков, но не для высоконагруженных сервисов.
• Некоторые участники подчеркнули, что serverless может быть дороже и сложнее в управлении, чем традиционные серверы.
• Было отмечено, что serverless может быть полезен для специфических задач, таких как обработка фото или видео, но не для высоконагруженных API.
• Участники также обсудили, что выбор между serverless и традиционными серверами должен основываться на конкретных потребностях и ограничениях проекта.

SQLite написан на C, а не на более современных языках, по нескольким ключевым причинам.

Производительность и контроль: C позволяет разработчикам писать код, который выполняется максимально близко к аппаратному уровню, что критично для низкоуровневых библиотек, таких как SQLite. Хотя некоторые языки могут заявлять о схожей производительности, C остается эталоном. Кроме того, его "портабельность" (работа практически на любой платформе) делает его универсальным.

Совместимость и стабильность: Библиотеки на C могут использоваться практически из любого другого языка программирования, что делает SQLite доступным для разработчиков на разных платформах и в разных экосистемах. C также является зрелым и стабильным языком, что минимизирует риски, связанные с изменчивостью более молодых языков.

Минимальные зависимости: В отличие от многих современных языков, которые требуют объемные среды выполнения, код на C имеет минимальные зависимости. Это делает развертывание легким и надежным, что критично для встраиваемых систем, где SQLite часто используется.

Хотя существуют аргументы в пользу использования объектно-ориентированных или "безопасных" языков (таких как Rust), эти варианты были либо недоступны, либо незрелы, когда начиналась разработка SQLite. Более того, переход на новый язык потребовал бы значительных усилий без гарантии улучшений, особенно учитывая, что SQLite уже хорошо отлажен и оптимизирован в своей текущей реализации на C.

• Обсуждение вращается вокруг того, стоит ли переписывать SQLite на другие языки, но аргументы сводятся к тому, что существующий код уже безупречен, а переписывание может внести новые баги и даже замедлить работу.
• Подчеркивается, что SQLite — это не только код, но и 100% покрытие тестами и 25 лет отладки, что делает язык менее важным, чем для других проектов.
• Участники обсуждения отмечают, что языки вроде Rust всё ещё молоды и меняются, а также не предоставляют преимуществ в контексте уже готового кода.
• Поднимается вопрос о том, что важнее — язык или разработчики, и подчеркивается, что последние могут писать на любом языке, если бы это действительно было нужно.

• Современные компиляторы умеют как микро-, так и макро-оптимизации, но между ними остаётся «запретная зона», где оптимизация неэффективна из-за сложной модели стоимости операций в памяти и ветвлениях.
• Пример: вместо векторизации циклов компилятор может вставить rep movsb, что на старом CPU быстрее, но на новом медленнее.
• Практический вывод: измеряйте, прежде чем оптимизировать; не верьте мифам о «магии» компилятора.

Проект JIT-компилятора для PostgreSQL сталкивается со сложностями из-за особенностей современных процессоров. Автор объясняет, что даже хорошо написанный интерпретатор может проигрывать в производительности из-за непредсказуемости переходов в switch-based интерпретаторах.

Используя технику "computed gotos" (динамических переходов), можно значительно ускорить интерпретацию, сделав шаблоны переходов более предсказуемыми для предсказателя ветвления процессора. Это может дать до 15-20% прироста производительности.

Автор также упоминает, что его JIT-решение для PostgreSQL будет использовать этот подход, а также другие оптимизации, такие как векторизация и inlining, чтобы превзойти стандартный интерпретатор PostgreSQL.

Кроме того, автор отмечает, что оптимизация под современные процессоры (особенно с их out-of-order исполнением и предсказанием ветвлений) требует осторожного подхода. Например, код должен быть структурирован так, чтобы минимизировать зависимости по данным и максимизировать параллелизм на уровне инструкций.

В итоге, проект направлен не только на создание JIT-компилятора, но и на то, чтобы переосмыслить, как должен работать интерпретатор, чтобы эффективно использовать современные процессоры.

• Обсуждение затронуло ограничения JIT в iOS из-за политики Apple, что влияет на производительность и возможности использования JIT в этой системе.
• Участники обсудили, что JIT-компилятор может быть полезен для оптимизации, но его отсутствие в iOS ограничивает возможности приложений.
• Также обсуждались различные аспекты производительности интерпретатора и JIT, включая влияние на предсказание переходов и спекулятивное исполнение.
• Участники упомянули, что JIT может быть полезен для DSL или других специализированных языков, но ограничения iOS могут затруднить это.

Почему Wi-Fi в домашних условиях часто работает плохо? Потому что маркетинг и потребительская психология заставляют производителей и провайдеров выставлять по умолчанию широкие каналы 80 МГц вместо 20/40 МГц, что приводит к перегрузке эфира и соседским помехам. А ведь профессионалы знают, что узкие каналы дают больше свободных частот и лучше масштабируют сеть. Но продавать «широкий» канал как «фичу» выгоднее.

Кроме того, популярные онлайн-тесты скорости, которые пользователи любят запускать, сами по себе создают конкуренцию за эфирное время и ухудшают качество связи для всех устройств в сети. Это показывает, что «скорость» как метрика качества Wi-Fi вредоносна сама по себе.

• Wi-Fi оптимизирована под скорость, а не под надежность, что приводит к перегрузке каналов и влияет на задержки и потери пакетов, что особенно критично в плотно населенных местах.
• Пользователи часто не осознают, что их сети могут быть перегружены из-за соседей, и что это может быть причиной проблем, которые они приписывают провайдеру или оборудованию.
• Провайдеры и производители оборудования продолжают продвигать "скорость" как единственную метрику качества сети, потому что это легко продавать, даже если это не отражает реальную производительность сети.
• В действительности, наилучшая производительность Wi-Fi достигается при использовании Ethernet кабеля для стационарных устройств, оставляя Wi-Fi для мобильных устройств, где это действительно необходимо.

Ryan Fleury в своём блоге Digital Grove рассуждает о том, что современные процессоры уже давно многоядерны, но большинство программистов всё ещё пишут однопоточный код, упуская до 90% вычислительной мощности. Он приводит пример: сумма элементов массива может быть распараллелена на 4 ядра, но в итоге выигрыш в 3.2 раза превращается в проигрыш в 1.3 раза из-за накладных расходов на синхронизацию и кэш-коэффициенты. Автор приходит к выводу, что надо не "добавлять" многопоточность в специфические случаи, а с самого начала писать весь код как будто он многопоточен, и тогда не будет никаких "особых случаев".

• Обсуждение показало, что современные языки и фреймворки всё ещё не решают фундаментальную проблему — как писать код, который по-настоящему использует многоядерные CPU.
• Участники подчеркнули, что большинство программистов не имеют ни инструментов, ни культуры для эффективного использования параллелизма.
• Были упомянуты такие концепции как "неявный параллелизм" и "автоматическое распараллеливание", но никто не смог привести примеры их практического применения.
• Обсуждение также затронуло вопрос о том, что большинство задач пользователя не требуют параллельного выполнения, и что производительность часто ограничена не столько CPU, сколько IO или GPU.

Python 3.14 вышел 8 октября 2025 года. Автор сравнил его с 3.9-3.13, а также с PyPy 3.11, Node.js 24 и Rust 1.90. Для тестов использовались два скрипта: рекурсивный расчет 40-го числа Фибоначчи и пузырьковая сортировка 10 000 элементов. Все тесты запускались на ноутбуке с Intel Core i5 под Ubuntu и ноутбуке Apple M2 под macOS.

Результаты: CPython 3.14 оказался на 10-15% быстрее 3.13 и примерно вдвое быстрее 3.9. JIT в 3.14 работает стабильно, а в 3.13 еще может выдавать сбои. Free-threading в 3.14 показал себя как надежный способ распараллеливать задачи, но прирост не столь драматичен, как ожидалось. PyPy 3.11 оказался в 2-3 раза быстрее CPython 3.14, но требует в 2-3 раза больше памяти. Node.js и Rust оказались в 2-3 раза быстрее, но это сравнение не совсем корректно, так как они не тестировали рекурсию.

• Пользователи обсуждают производительность Python 3.14, сравнивая его с PyPy и другими языками, и обсуждают, почему сообщество продолжает тратить усилия на ускорение CPython вместо перехода на PyPy.
• Несколько комментаторов отмечают, что 3.14 всё ещё значительно уступает PyPy и даже Node.js в ряде тестов, хотя и демонстрирует прогресс.
• Обсуждается, почему Python не может быть переименован в π-thon, несмотря на то, что это было бы логично, и почему не используется возможность перехода на PyPy, несмотря на то, что он быстрее.
• Участники также обсуждают, что, несмотря на то, что Python всё ещё остаётся медленным, он остаётся незаменимым для прототипирования и имеет огромную экосистему библиотек, что делает его незаменимым для многих задач.
• Наконец, обсуждается, что, несмотря на то, что Python медленный, он всё ещё может быть использован для большинства задач, и что важнее всего - он всё ещё может быть использован для большинства задач.

PGLinter — это инструмент для анализа качества базы данных PostgreSQL, который выявляет проблемы с производительностью, безопасностью и стандартизацией. Он работает на основе настраиваемых правил, которые можно включать или отключать, и поддерживает экспорт результатов в стандартном формате SARIF для интеграции с CI/CD.

Ключевые возможности:

• Автоматическое выявление проблем: Отсутствующие индексы, неиспользуемые индексы, неправильные настройки безопасности
• Глубокая интеграция с PostgreSQL: Реализован как расширение, поэтому использует внутренние механизмы СУБД
• Гибкая настройка: Можно отключать отдельные правила, менять пороги срабатывания
• Удобство для разработчиков: Встраивается в CI/CD, есть санитизация схемы данных

Например, правило B001 выявляет таблицы без первичного ключа. T003 находит индексы, которые полностью дублируются другими индексами. C001 предупреждает, если настройки памяти небезопасны.

Пользователи могут запускать анализ через SQL: SELECT pglinter.perform_base_check(); или экспортировать результаты в SARif для интеграции с GitHub Actions, Jenkins и другими инструментами.

Проект активно развивается, с планами по добавлению правил, связанных с безопасностью, и расширением покрытия различных аспектов базы данных. Конечная цель — сделать PGLinter таким же обязательным в проекте, как ESLint для JavaScript или RuboCop для Ruby.

• Инструмент анализа БД pg_linter представляет собой расширение PostgreSQL, что вызывает вопросы о необходимости именно расширения, а не отдельного инструмента, который можно было бы запускать против любой БД.
• Участники обсуждения отмечают, что в 2025 году принцип наименьших привилегий в контексте безопасности и стабильности системы особенно важен, и устанавливать сторонние расширения в продакшен средах может быть неприемлемо.
• Некоторые участники высказывают мнение, что вместо расширения мог бы подойти и инструмент, который мог бы анализировать дамп базы данных либо имитировать схему в контейнере.
• Также обсуждается, что правила вроде B006 (таблицы с именами в верхнем регистре) могут быть неуместны в контексте конкретной ORM или обстоятельств, и что некоторые правила могут быть неприменимы к специфическим ситуациям, таким как TimescaleDB.

Статья разбирает, как структуры данных влияют на производительность Go-программ под современными CPU. Автор подчеркивает, что чтение из оперативной памяти в 60 раз медленнее, чем из кэша L1, и что ложный обмен (false sharing) между ядрами может убить производительность. Показано, как добавление 56-байтовой прокладки между полями структуры устраняет проблему и ускоряет код в 6-10 раз. Другой совет — разделять «горячие» и «холодные» данные и использовать структуры, оптимизированные под кэш-линии. Показано, как профилировать кэш-промахи через perf и как тестировать эффективность структур данных.

• False sharing и cache-line padding в Go приводят к 10-кратному ускорению при использовании структур, разделённых на разные ядра, но требуют ручного управления выравниванием и размером кэш-линии.
• Компилятор Go не переупорядочивает поля структур и не вставляет паддинг, что делает невозможным автоматическое устранение false sharing без кода, что ограничивает оптимизации только ручными методами.
• Пользователи отмечают, что большинство описанных приёмов применимы к другим языкам и что современные компиляторы должны бы справляться с большинством этих проблем автоматически, но в то же время признают, что для низкоуровневой оптимизации лучше подойдут другие языки и инструменты.

Написанная на Rust утилита ut предлагает разработчикам набор инструментов для повседневных задач, вдохновляясь функциональностью it-tools.tech. Она включает конвертеры, генераторы хешей, кодировщики и другие инструменты для работы с данными, кодом и системами. Проект стремится объединить распространённые утилиты в одном месте, упрощая доступ без переключения между сервисами.

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

• Предложения по распространению: упаковать как Python и NPM модули для удобного запуска через uvx или npx, использовать cargo-dist для автоматизации.
• Критика архитектуры: обсуждается целесообразность единого бинарника (по аналогии с BusyBox) против множества отдельных утилит в духе UNIX-философии "делай одно дело хорошо".
• Вопросы к функционалу: предостережения против включения слишком большого количества функций (например, HTTP), предложения добавить конкретные команды (uuidv7, retry).
• Замечания по реализации: критика требований к вводу (только UTF-8, чтение stdin до EOF), отсутствие тестов для кода, созданного с помощью ИИ.
• Общая оценка: инструмент воспринят как удобный "швейцарский нож" с продуманными умолчаниями, но вызвал дискуссию о разумных пределах его роста.

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

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

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

• Обсуждается сложность реализации двусвязных списков и циклических ссылок в Rust из-за системы владения, предлагаются решения через арены, weak pointers и изменения в языке.
• Поднимаются вопросы безопасности памяти: арены и handles могут предотвратить неопределённое поведение, но не исключают ошибки в пределах границ, что может привести к уязвимостям.
• Сравниваются подходы к управлению памятью: ручное управление через арены vs. сборка мусора, отмечаются компромиссы между производительностью, безопасностью и сложностью разработки.
• Высказываются мнения о месте Rust среди других языков: он конкурирует с C++ по производительности и безопасности, а с GC-языками — по простоте, но имеет крутую кривую обучения.
• Обсуждается необходимость и сложность добавления в Rust стабильного API для аллокаторов и других низкоуровневых возможностей для большей гибкости и контроля.

В TypeScript-коде Microsoft активно используются устаревшие var вместо современных let и const, несмотря на их проблемы с областью видимости. Это связано с Temporal Dead Zone (TDZ) — зоной, где переменные объявлены, но не инициализированы. При использовании let и const обращение к переменным в TDZ вызывает ошибки, что повышает надёжность, но требует вычислительных ресурсов.

Переход на var в критичных к производительности участках дал TypeScript до 8% ускорения в бенчмарках, поскольку var избегает проверок TDZ. Это демонстрирует компромисс между безопасностью кода и производительностью, особенно в крупных проектах, где даже небольшие оптимизации значимы.

• Обсуждается производительность let/const против var в JavaScript, где var может давать выигрыш до 8% из-за отсутствия проверок TDZ (Temporal Dead Zone).
• Поднимается вопрос о дизайне JS: хоистинг и TDZ считаются проблемными и неочевидными особенностями языка, усложняющими оптимизацию.
• Участники спорят, является ли текущая реализация лексической области видимости в JS "ужасной" или это просто особенность, которую нужно принять.
• Обсуждаются возможные решения: более умный анализ TDZ в движках, трансляция в var на этапе сборки или использование других языков (например, Lua) как примера.
• Затрагивается практический аспект: TypeScript перешел на таргет ES2018+, что неожиданно привело к падению производительности из-за использования let вместо var.

Некоторые версии Electron на macOS вызывают системные лаги, особенно на Tahoe. Проблема решена в версиях 36.9.2, 37.6.0, 38.2.0, 39.0.0 и выше. Для обнаружения уязвимых приложений используется скрипт, который сканирует установленные программы и проверяет версии Electron Framework.

Временное решение — установка переменной окружения CHROME_HEADLESS=1 при запуске системы, что отключает тени окон Electron, устраняя лаги, но ухудшая визуальный вид. Среди популярных приложений с проблемными версиями: Visual Studio Code (37.3.1), Slack (38.1.2), DaVinci Resolve (36.3.2) и другие.

• Обсуждаются способы выявления Electron-приложений на Mac с устаревшими версиями фреймворка, вызывающими лаги системы, включая скрипты и инструменты для анализа.
• Участники отмечают, что многие популярные приложения (VS Code, Slack, Discord, Docker Desktop и др.) используют устаревшие версии Electron, что приводит к проблемам с производительностью после обновления macOS.
• Высказывается критика в адрес Apple за недостаточное тестирование ОС и в адрес Electron за отсутствие разделения рантайма и приложений, что затрудняет массовые обновления.
• Приводятся примеры конкретных приложений и их версий Electron, а также личный опыт удаления или отказа от обновления проблемного ПО.
• Обсуждаются технические детали бага Electron (проблема с перерисовкой тени) и тот факт, что команда Electron выпустила патч для предыдущих версий.

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

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

• Обсуждение определяет "хороший вкус" в разработке как способность выбирать оптимальные решения, основанные на контексте и требованиях проекта, а не на личных предпочтениях.
• Участники подчеркивают, что хороший вкус тесно связан с опытом, гибкостью, умением аргументировать выбор и предвидеть последствия решений для поддержки и масштабирования.
• Многие отмечают, что хороший вкус — это баланс между читаемостью, производительностью, простотой и соответствием бизнес-целям, а не слепое следование догмам или модным тенденциям.
• Спорным остается вопрос, является ли "вкус" субъективным эстетическим понятием или его можно формализовать через принципы инженерии (например, поддерживаемость, ясность, минимальная сложность).
• Некоторые видят корень проблемы в смешении объективно плохих решений (например, неэффективные алгоритмы) и субъективных предпочтений (стиль кода, выбор парадигм).

PostgreSQL 18 добавляет нативную поддержку UUID v7 через функцию uuidv7(), что позволяет использовать UUID в качестве первичных ключей без потери производительности благодаря их последовательной природе. Это устраняет необходимость в сторонних расширениях или реализации генерации на уровне приложения.

Также введены VIRTUAL generated columns — теперь вычисляемые столбцы по умолчанию генерируются при чтении, а не записи, что экономит место на диске и избегает перезаписи таблиц при их добавлении. Эти изменения упрощают разработку, делая работу с базой данных более гибкой и эффективной.

• Участники обсуждают преимущества вычисляемых столбцов в базах данных, отмечая их полезность для миграций схем и единообразия логики между разными клиентами.
• Поднимается вопрос о производительности: выполнение вычислений на стороне БД может быть эффективнее, чем в клиентских приложениях, особенно при использовании индексов.
• Высказываются опасения о возможном злоупотреблении этой функцией и усложнении схемы, но признаётся, что иногда это единственное решение.
• Упоминается конкретный пример использования для преобразования временных зон, чтобы упростить запросы.
• Обсуждение начинается с упоминания функции pg_get_acl() и сложности составления запросов для проверки привилегий.

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) или встроенного кэша приложения вместо распределённого решения.

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

Проблема проявляется при одновременной работе нескольких Electron-приложений, таких как Slack, Discord или VS Code. Система начинает проседать по производительности, что негативно сказывается на пользовательском опыте. Разработчики Electron признают проблему и изучают её, но пока не предложили конкретного решения.

• Проблема с производительностью в macOS 26 вызвана использованием приложениями (включая Electron) приватных API Apple, что приводит к утечкам ресурсов и лагам.
• Некоторые пользователи не сталкиваются с проблемами, возможно, из-за высокой производительности железа (например, чипов M4), которое маскирует недочеты.
• Обсуждается, кто виноват: разработчики приложений за использование приватных методов или Apple за отсутствие регрессионного тестирования и обратной совместимости.
• Для части приложений (Chrome/Chromium) уже выпущен фикс, а также известны временные решения через терминал.
• Спектр мнений варьируется от критики Electron до защиты его как кросс-платформенного решения с хорошим DX.

Новички в программировании часто зацикливаются на изучении структур данных и алгоритмов (DSA), потому что это проверяется на собеседованиях. Однако в реальной работе редко приходится реализовывать сложные алгоритмы вручную — вместо этого стоит понять базовые структуры, их trade-offs и основы Big O, чтобы эффективно организовывать и обрабатывать данные.

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

• Участники обсуждают важность знания структур данных и алгоритмов (DSA) для разработчиков, отмечая, что понимание их характеристик (например, сложности операций) часто важнее умения реализовывать их с нуля.
• Подчеркивается необходимость баланса между теоретическими знаниями (DSA) и практическими навыками тестирования, при этом многие отмечают, что эти навыки не исключают, а дополняют друг друга.
• В дискуссии звучит критика статьи, указанной в исходном посте, за её провокационный заголовок, который, по мнению участников, упрощает сложную проблему и создает ложную дихотомию между DSA и тестированием.
• Несколько комментаторов приводят примеры из практики, где незнание базовых принципов DSA (например, сложности алгоритмов) приводило к серьезным проблемам с производительностью в продакшене.
• Обсуждается роль тестирования: одни видят в нем ключевой навык для обеспечения качества, другие указывают на его ограничения (например, сложность тестирования многопоточных систем) и необходимость сочетать его с другими методами, как property-based тестирование или формальные доказательства.

Lua_u_

Lua_u_ (строчная u, /ˈlu.aʊ/) — это быстрый, компактный, безопасный, постепенно типизированный встраиваемый язык сценариев, основанный на Lua.

Мотивация

Примерно в 2006 году Roblox начал использовать Lua 5.1 в качестве языка сценариев для игр. Со временем мы значительно развили реализацию и язык: для поддержки растущей сложности игр на платформе Roblox, увеличения размеров команд и написания большого объёма кода (более 1 млн строк к 2020 году) нам пришлось инвестировать в производительность, удобство использования, инструменты языка и ввести постепенную систему типов. Подробнее…

Песочница

Luau ограничивает набор стандартных библиотек, доступных пользователям, и реализует дополнительные функции песочницы для возможности запуска непривилегированного кода (написанного разработчиками игр) вместе с привилегированным кодом (нашим). Это создаёт среду выполнения, отличающуюся от традиционной для Lua. Подробнее…

Совместимость

По возможности Luau стремится быть обратно совместимым с Lua 5.1 и одновременно включает функции из более поздних версий Lua. Однако Luau не является полным надмножеством более поздних версий Lua — мы не всегда согласны с решениями Lua и имеем другие варианты использования и ограничения. Все функции Lua после 5.1, а также их статус поддержки в Luau, документированы здесь.

Синтаксис

Luau синтаксически обратно совместим с Lua 5.1 (код, действительный для Lua 5.1, также действителен для Luau); однако мы расширили язык набором синтаксических функций, делающих его более привычным и эргономичным. Синтаксис описан здесь.

Анализ

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

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

В дополнение к полностью кастомному фронтенду, реализующему парсинг, линтинг и проверку типов, среда выполнения Luau включает новый байткод, интерпретатор и компилятор, сильно оптимизированные для производительности. Интерпретатор Luau может конкурировать с интерпретатором LuaJIT в зависимости от программы. Также доступен опциональный компонент для ручной JIT-компиляции на платформах x64 и arm64, который может значительно ускорить определённые программы. Мы продолжаем оптимизировать среду выполнения и переписывать её части для ещё большей эффективности. Хотя наша общая цель — минимизировать время, которое программисты тратят на настройку производительности, некоторые детали о характеристиках производительности предоставлены для любознательных.

Библиотеки

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

© 2025 Roblox.

• Переход на Luau обусловлен системой типов, но язык имеет шероховатости и слабую документацию, а сообщество практически отсутствует.
• Luau значительно сложнее и объёмнее стандартного Lua, что связано с реализацией системы типов и дополнительных возможностей.
• Существуют альтернативные реализации и среды выполнения Luau, такие как Lune, предназначенные для использования вне Roblox.
• Сообщество отмечает проблемы обратной совместимости между различными форками Lua (LuaJIT, Luau, PUC Lua), что создаёт фрагментацию.
• Luau сравнивают с Teal, но они fundamentally разные: Teal — это транспилятор, а Luau — полноценный форк Lua с собственной средой выполнения.
• Разработчики Roblox работают над улучшением поддержки Luau вне своей платформы, включая создание standalone-рантаймов.
• Несмотря на критику, инженерные решения в Luau, особенно в области производительности, оцениваются как впечатляющие.

Java 25: новый CPU-Profiler (1)

В JDK 25 появился экспериментальный CPU-Profiler — метод-сэмплер, который показывает, сколько процессорного времени тратит каждый метод, а не просто «время выполнения». Это важно: метод, ждущий I/O, занимает процессор лишь доли миллисекунды, и старый sampler не видит разницы между ним и вычислительно тяжёлым кодом.

Старый JFR-сэмплер каждые 10–20 мс выбирает 5 Java-потоков и 1 native, просто пробегая по списку. На 32-ядерной машине это превращает заявленный интервал 10 мс в фактические 53 мс, а при смеси Java и native потоков приоритет всегда получают Java. Результат — искажённая картина.

Новый профилировщик измеряет именно CPU-time, позволяя найти узкие места, которые реально жгут ядра, и повысить throughput без догадок.

• JVM за последние годы стал двигателем инноваций: виртуальные потоки, Loom и быстрый цикл релизов делают Java снова «весёлой».
• Большинство участников рады избавлению от реактивного async-кода: «пусть всё будет синхронно и просто».
• Скептики напоминают: виртуальные потоки всё-таки тратят CPU на GC и не решают проблемы доступа к ограниченным ресурсам.
• Кто-то жалуется на качество современных Java-разработчиков, другие отвечают: плохие devы есть везде, язык тут не при чём.
• Автор серии постов анонсировал три продолжения про новый CPU-Tracing в Java 25.

Новый экспериментальный JSON-API в Go

Go 1.25 предлагает encoding/json/v2 и encoding/json/jsontext — переработанные пакеты для работы с JSON. Они решают давние проблемы стандартного encoding/json и пока доступны только по флагу GOEXPERIMENT=jsonv2.

Главные недостатки старого API

• Неточности синтаксиса: принимает невалидный UTF-8, дублирует ключи, трактует числа как float64.
• Производительность: 2-3× медленнее современных альтернатив; каждый вызов тратит память на рефлексию.
• Гибкость: нельзя пропустить неизвестные поля, работать с потоковым JSON, получать исходный текст, сохранять порядок ключей, использовать сторонние типы.

Что нового в v2

• Три пакета
  – jsontext — низкоуровневое чтение/запись токенов, сохраняет формат.
  – json — высокоуровневый marshal/unmarshal, совместим с v1, но строже и быстрее.
  – jsontext можно использовать отдельно для потоковой обработки.

• Строгость
  UTF-8 проверяется, дубли ключей — ошибка, числа не теряют точность.

• Производительность
  Без рефлексии в hot-path, 2-3× быстрее, меньше аллокаций.

• Новые возможности
  Пропуск неизвестных полей, сохранение порядка, работа с any, доступ к сырому JSON, совместимость с v1 через теги.

Как попробовать

GOEXPERIMENT=jsonv2 go mod download

import "encoding/json/v2"

Фидбек приветствуется: golang.org/issue/71497.

• Вышел экспериментальный encoding/json v2: новый API, лучшая производительность, но спорные решения по nil-значениям.
• Часть пользователей рада росту скорости и модульному пакету jsontext; другие считают, что костыли с nil → null остались.
• Кто-то уже прогнал тысячи тестов — почти всё прошло; кто-то нашёл регрессию аллокаций. Авторы просят больше отзывов.
• Сравнения со сторонними библиотеками (Sonic, goccy) показывают выигрыш в CPU, но проигрыш в безопасности и поддержке ARM.
• Обсуждение выродилось в холивар: «почему за 15 лет JSON до сих пор не решён» vs «две v2 за всю историю — отличный результат».

• Сортировка с хешем быстрее хеш-таблиц: на больших данных 1,5–4×, несмотря на «O(n log n)».
• Память: хеш-таблица тянет 128 Б на 8-Б ключ (64 чтение + 64 запись), радикс-сорт 3 прохода — 48 Б (вся линия кэша используется).
• Плохие распределения (мало заполненных корзин) замедляют радикс-сорт; решаем хешем hash(key) перед сортировкой. Берём обратимую функцию (Murmur3, MulSwapMul), хешируем «на лету» в первом проходе.
• Результат: 2 ГиБ уникальных uint64 за 1,9 с против 2,6 с у оптимизированной хеш-таблицы.
• Подходит, когда порядок не важен, а нужны только уникальные значения; иначе остаёмся на хеш-таблицах.

• Улучшенная нестабильная сортировка Rust почти догнала по скорости специально настроенный radix-sort, несмотря на разницу в O(n log n) vs O(n).
• Хэш-таблица «побеждает» лишь при ограниченном размере ключа и хорошем кэше; при росте данных снова проигрывает из-за промахов и O(n log n) внутри.
• Radix можно ускорить, выделяя buckets через MMU, а не вручную управляя памятью.
• На очень больших объёмах (≥120 ГБ) константы radix снова могут перевесить, но пока доминирует кэш-эффективность сортировки.
• Всё обсуждение подчёркивает: конкретные константы и архитектура CPU важнее «чистой» Big-O.

TL;DR
Чтение напрямую с диска быстрее, чем из кеша в памяти: пропускная способность SSD растёт, а латентность памяти стоит на месте. Нужны новые инструменты.

Эксперимент

• Задача: подсчитать количество десяток в 50 ГБ псевдослучайных int.
• Железо: AMD EPYC 7551P, 96 ГБ DDR4-2133, два Samsung PM983a PCIe 3.0 SSD (3,1 ГБ/с каждый) в RAID-0.
• Ограничения:
  • Память: 13 ГБ/с на поток (3 канала × 2133 МТ/с × 8 Б / 4 NUMA-домена).
  • Диски: 6,2 ГБ/с суммарно.

Код

int* data = mmap(..., size, PROT_READ, MAP_SHARED, fd, 0);
for (...) if (data[i] == 10) count++;

Результаты

• Первый запуск (с диска): 0,61 ГБ/с — ограничение диск.
• Второй запуск (из кеша): 3,71 ГБ/с — всё ещё ниже пропускной способности памяти.
• Бутылочное горлышко: не векторизованный цикл, ~3–4,5 млрд инструкций/с.

• mmap тормозит из-за последовательных page-fault и 4 Кб страниц; io_uring на 6 потоках читает буферы заранее и просто отдаёт готовые.
• Пропущены MAP_POPULATE / MADV_SEQUENTIAL / hugepages — без них сравнение «mmap vs io_uring» нечестое.
• Автор признаёт кликбейтное название «Memory is slow, Disk is fast»; суть: «RAID-0 NVMe даёт больше пропускной канала, чем DDR5-каналов на тестовой машине».
• Под капотом io_uring + O_DIRECT сам управляет кэшем, mmap же полагается на page-cache ядра.
• PCIe-5 ×128 линий серверных CPU уже >1 ТБ/с, что выше DDR5-6400 12-канального узла (~600 ГБ/с), но данные всё равно идут в RAM перед CPU.

• Зачем замедлять программу?
  Искать race-conditions, «виртуально» оценить выгоду оптимизации (как в Coz) и проверять точность профилировщиков. Для этого меняют расписание потоков или вставляют задержки.

• Как замедляют сейчас?
  Грубо: Thread.sleep, остановка потоков, вставка лишнего байт-кода. Это снижает точность.

• Наша идея
  Вставлять задержки внутри basic block на уровне x86. Нужны инструкции, которые:
  – надёжно тратят циклы;
  – не искажают семантику;
  – не оптимизируются CPU за счёт out-of-order.

• Проблема
  Современные процессоры выполняют независимые mov параллельно, поэтому просто добавить «тяжёлые» команды недостаточно — нужно учитывать зависимости и микроархитектуру.

• Используются разные способы замедления: от NOP-циклов и RDTSC до AVX-нагрузок и «тормозных» устройств вроде C64 Snail или Turbo-кнопки.
• Замедление помогает выявлять N+1-запросы, неработающие кеши и другие узкие места, которые на быстрых машинах незаметны.
• Современные CPU оптимизируют NOP/MOV на стадии переименования, поэтому они плохо подходят для точного контроля времени.
• Causal-profiling (Coz) и специальные прокси (Toxiproxy, dummynet) позволяют «ускорять» выбранный код, оставляя остальное медленным, чтобы заранее оценить выгоду оптимизации.

Big O — способ описать, как время работы функции растёт с ростом входных данных, без привязки к конкретным секундам.

Рассмотрим 4 основные категории:

---

O(n) — линейное время

function sum(n) {
  let total = 0;
  for (let i = 1; i <= n; i++) total += i;
  return total;
}

• sum(1e9) ≈ 1 с
• sum(2e9) ≈ 2 с
  Время пропорционально n.

---

O(1) — константное время

function sum(n) {
  return (n * (n + 1)) / 2;
}

• sum(1e9) и sum(100e9) выполняются почти мгновенно.
  Время не зависит от n.

---

Ключевые идеи

• O = «order of growth»; описывает рост, а не абсолютное время.
• O(1) ≠ «быстро», а «не растёт с размером входа».
• При достаточно большом n O(1) всегда обгонит O(n).

• Обсуждение статьи о нотации Big O разделилось на «лайтовое» восхищение визуализациями и «экспертные» споры о точности определений.
• Новички признаются, что статья впервые открыла им глаза на сложность алгоритмов, а ветераны IT спорят, что за 40 лет ни разу не пригодилась.
• Критика сводится к тому, что автор описывает «поп-культурный» вариант Big O, путая его с Θ-нотацией и worst-case.
• Практики напоминают: на реальном железе константы, кэш и NUMA могут перечеркнуть асимптотику, а O(n²) при малых n часто быстрее «константного» хэша.
• Люди делятся шпаргалками (bigocheatsheet.com, visualgo.net) и просят ещё интерактивных уроков.

Идея: вместо одного огромного LLM использовать роутер, который для каждого запроса выбирает наиболее подходящую по размеру и качеству модель из набора.
Проблема: GPT-4/5 дороги и не всегда нужны; мелкие модели дешевле, но хуже.
Решение: обучить роутер-LLM прогнозировать, какая модель справится с задачей с минимальными затратами и заданным порогом качества.

Методика:

• Собрали 30 задач NLP (перевод, суммаризация, код и т.д.).
• Для каждой задачи подготовили набор моделей разных размеров (от 1.3 B до 70 B параметров).
• Обучили роутер на 100k примеров, где вход — запрос, выход — выбор модели + оценка качества.
• Использовали Pareto-оптимизацию: минимизировать стоимость при фиксированном качестве.

Результаты:

• При том же качестве, что у GPT-4, роутер сокращает стоимость в 4–6 раз.
• На 50 % запросов достаточно модели 7 B вместо 70 B.
• Роутер добавляет <1 мс задержки (незаметно).

Вывод: дешевле и быстрее держать «зоопарк» моделей + роутер, чем один сверхбольшой LLM.

• Обсуждают «роутинг» запросов между разными LLM вместо одной большой модели: берут 70 % примеров, смотрят, какая модель лучше справляется с каждым кластером, и на оставшиеся 30 % уже маршрутизируют.
• Идея пока простая (эмбеддинг + выбор лучшей по истории), но сообщество считает её неизбежным следующим шагом после CoT и способом дешевле масштабироваться.
• Критика: не учитывают латентность роутера, могут промахнуться со «сложными» запросами, выглядящими простыми; GPT-5 редко включает reasoning-модель.
• Некоторые сравнивают с NotDiamond и другими стартапами, а также с «облачной» эволюцией: сначала дорого, потом дешевеет.
• Видение будущего — AGI как ансамбль специализированных модулей, которые можно миксовать под задачу пользователя.

Acronis True Image замедляет ПК даже без запуска

Поставил Acronis True Image для миграции на новый SSD, оставил «на всякий случай». Через два года заметил: при подключении/отключении внешнего монитора Explorer.exe жрёт 44 с CPU за 16 с реального времени, ПК тормозит.

ETW-трейс показал, что 20 из 42 тыс. сэмплов уходят на windows.storage.dll!CFSFolder::_GetOverlayInfo, а дальше — в tishell64_26_0_39450.dll. Библиотека вызывает CreateToolhelp32Snapshot и Process32NextW, перебирая процессы. В Visual Studio поставил условную точку останова на CreateToolhelp32Snapshot с ограничением в 1 млрд срабатываний: за 15 с она сработала 1 200 000 раз — ≈80 000 вызовов в секунду.

DLL принадлежит Acronis и внедряет оверлей-иконки в Проводник. При любом изменении конфигурации экрана (подключение монитора, смена DPI) она перечитывает список процессов, чтобы понять, какие иконки рисовать. Это и есть причина подвисаний.

Что делать

• Удалить Acronis True Image или отключить его расширение оболочки.
• Acronis уже выпустил временный патч и обещает исправить в следующей версии.

Итог: даже «ничего не делающая» утилита может легко превратиться в тормоз.

• Пользователи удивлены, что проприетарная компания добровольно отдала отладочные символы DLL по запросу техподдержки.
• Предполагают, что отключение монитора сбрасывает кэш иконок Windows и вызывает проблему через сторонний обработчик.
• Файлы Acronis выглядят подозрительно: отсутствуют базовые метаданные, что напоминает вредоносное ПО.
• Множество участников жалуются на глючность Acronis: слетают лицензии, портят резервные копии, конфликтуют с аудио-драйверами.
• Альтернативы: Veeam (бесплатный и лёгкий), Macrium Reflect, Clonezilla.
• На Windows «тысяча мелких порезов» от стороннего софта; на Linux проще отлаживать, но проблемы тоже есть.

Как я ускорил Ruby до скорости Ruby

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

Как работает компиляция

Шаблон — это Proc:

->(title:) {
  html { body { h1 title } }
}.render(title: 'Hi')

При вызове #render код превращается в:

->(buf, title) {
  buf << "<html><body><h1>"
  buf << ERB::Escape.html_escape(title.to_s)
  buf << "</h1></body></html>"
  buf
}

1. Парсинг: Sirop читает файл и строит AST через Prism.
2. Трансформация: TagTranslator заменяет CallNode на TagNode, если вызов соответствует HTML-тегу без получателя.
3. Обратный код: подкласс Sourcifier преобразует AST обратно в Ruby, подставляя строки буфера и экранирование.

Оптимизация

Jean Boussier указал узкие места и направления. В результате генерация стала заметно быстрее «чистого» Ruby.

• Автор создал альтернативу ERB, ускорил её до сопоставимой скорости, но, по мнению @swombat, выводит ошибочное заключение.
• @ciconia (автор) спорит: производительность Ruby важна, его системы выдают >1K RPS.
• @barrkel: Ruby медленнее, но быстрее Python; у каждого свои пути к скорости.
• @Alifatisk: сравнивать Ruby с Rust бессмысленно — языки для разных задач.
• Остальные комментарии свелись к старому мему «yo dawg».

ClickHouse vs PostgreSQL: UPDATE-скорость

• Коротко: на одном железе ClickHouse догоняет PostgreSQL в одиночных UPDATE и в 4 000 раз быстрее при массовых.
• Почему: колоночное хранилище + параллелизм ClickHouse выигрывает у строкового PostgreSQL при поиске и перезаписи миллионов строк.
• Но: PostgreSQL всегда транзакционен; ClickHouse — нет, поэтому сравнение по «родным» режимам, а не по ACID.

Что мерили

• 1 строка: UPDATE orders SET status='shipped' WHERE id=1234567
• 1 млн строк: UPDATE orders SET discount=0.1 WHERE order_date<'2023-01-01'

Аппаратура

• c6i.8xlarge (32 vCPU, 64 ГБ RAM, gp3 SSD)
• PostgreSQL 16.4 (дефолт + fillfactor=90, checkpoint_timeout=30 min)
• ClickHouse 25.7 (дефолт)

Результаты

метрика	PostgreSQL	ClickHouse
1 строка, мс	0.12	0.11
1 млн строк, сек	120	0.03
CPU, %	100	2800
чтение, ГБ	30	0.8

Почему так

• Поиск: ClickHouse читает только нужные колонки, фильтрует за счёт индексов и распараллеливает на все ядра.
• Запись: обе СУБД пишут новые версии строк (MVCC), но PostgreSQL переписывает целые страницы, а ClickHouse — только изменённые куски колонок.
• Фоновая работа: PostgreSQL ждёт checkpoint’а, ClickHouse сразу сортирует и сжимает куски.

Когда выбирать

• Нужны транзакции и row-level locks → PostgreSQL.
• Нужны массовые обновления аналитических данных → ClickHouse.

Код и данные

GitHub

• ClickHouse показывает огромный выигрыш в скорости обновлений, но это «яблоки-к-апельсинам»: PostgreSQL по умолчанию полностью транзакционен, а CH — нет.
• Если данные можно терять или обновления редки, CH идеален; если нужна строгая согласованность, PostgreSQL остаётся безальтернативным.
• Многие пользователи CH считают обновления адом: приходится использовать ReplacingMergeTree, версии или event-sourcing; прямых UPDATE-ов до недавнего времени вообще не было.
• Часть комментаторов предлагает сравнивать CH с DuckDB, Vertica или ScyllaDB, а также настроить PostgreSQL (synchronous_commit = off, COPY) для более честного бенчмарка.
• Авторы поста подчёркивают: цель не «победить» PostgreSQL, а показать, как каждая СУБД решает задачу в своей «родной» модели исполнения.

OpenBSD быстрее Linux в 10 раз?
Тест Jann Horn: создаём поток, оба потока открывают по 256 сокетов.

Linux

elapsed: 0.017–0.026 s

OpenBSD

ulimit -n 1024
elapsed: 0.002–0.006 s

Машины примерно равны. Подсказка в коде (не в сетевом стеке).
Обычно OpenBSD проигрывает в странных тестах, а тут — наоборот.

• Обсуждение выросло из «патологического» теста, который на Linux показывает замедление из-за роста таблицы файловых дескрипторов и блокировок, а на OpenBSD — нет.
• Участники спорят, что считать «быстрым»: OpenBSD жертвует скоростью ради безопасности, тогда как Linux активно оптимизирует критические пути.
• Для микробенчмарков советуют использовать __rdtsc(), но предупреждают о проблемах синхронизации TSC между ядрами и на ARM.
• Несколько человек отвлеклись на «пасхалку» в статье — плавающие «пушки», стреляющие курсором.
• Общий вывод: измеряйте свою нагрузку на одинаковом железе; универсального «быстрее» не существует.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

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

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

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

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.

JSON encoding is a huge impediment to interprocess communication in NodeJS.Sooner or later is seems like everyone gets the idea of reducing event loop stalls in their NodeJS code by trying to offload it to another thread, only to discover they’ve tripled the CPU load in the main