Hacker News Digest

WSL 3.x с ядром Linux 6.18 привёл к заметным улучшениям в низкоуровневых операциях по сравнению с WSL 2.x на ядре 6.6. Наибольший прирост наблюдается в памяти: пропускная способность memcpy выросла на 61,35 % — с 7,84 ГБ/с до 12,64 ГБ/с благодаря более крупному размеру страниц при репортинге памяти, что снижает накладные расходы гипервизора. Планировщик и межпроцессное взаимодействие также ускорились: latency контекстного переключения упал на 11,25 %, а производительность в тестах sched/pipe и sched/messaging выросла на 12,68 % и снизилась на 10,06 % соответственно. Базовые системные вызовы вроде getppid() стали быстрее на ~4 %, но здесь ограничения архитектуры процессора оставляют мало места для оптимизаций.

В реальной нагрузке — сборке GoReleaser — общее время уменьшилось на 3,91 % (с 191,27 с до 183,80 с), причём основной выигрыш пришёлся на снижение времени, проведённого в ядре: sys‑time упал на 15,98 % (с 57,39 с до 48,22 с) благодаря меньшим издержкам при открытии файлов, mmap и futex. Однако так как компиляция Go на 80 % зависит от пользовательских вычислений, а vCPU ограничены двумя ядрами на 2,10 ГГц, общий приростwall‑clock времени остался скромным. Вывод: WSL 3.x выигрывает в задачах с высокой интенсивностью IPC и работы с памятью (БД, микросервисы), тогда для вычислительно ограниченных сборок улучшение будет ощущаться преимущественно в снижении нагрузки на ядро, а не в ускорении самого билда.

WSL3 улучшает производительность, но не решает фундаментальные проблемы Windows как ОС. Основная проблема — медленный доступ к файлам через /mnt/c из-за 9P-файловой системы, а не виртуализация. Улучшения в WSL3 (например, +61% пропускной способности memcpy) значимы для разработчиков, но не меняют восприятия WSL как второсортной среды по сравнению с нативным Linux. Многие пользователи, перешедшие на Linux, не планируют возвращаться к Windows из-за нестабильности, принудительных обновлений и ограничений в управлении системой. AI (например, Claude) стал ключевым фактором, позволяющим новичкам преодолевать сложности Linux и ускоряя переход от WSL к нативной системе. WSL3 — это не архитектурный прорыв, а обновление WSL2 до версии 3.0 без изменения гипервизора или фундаментальной модели. Оно не решает проблему отсутствия полноценной интеграции с Windows и считается 'leaky abstraction' с ненужными слоями. Споры о стабильности Windows 11: некоторые называют её надёжной, другие — нестабильной, особенно на ноутбуках Lenovo Legion 5 с проблемами Wi-Fi. Одни видят в WSL незаменимый инструмент для корпоративных пользователей, другие — неудовлетворительное решение, не компенсирующее неудобства Windows. Советы: хранить рабочие файлы внутри WSL-файловой системы, а не в /mnt/c; полностью отказаться от Windows в пользу Linux с AI-помощью; переход на Linux с AI становится решаемым за час вместо дней. WSL стал 'вратами' для многих, кто впоследствии перешёл на нативный Linux и не возвращался. WSL2 и WSL3 не решают проблему производительности при работе с большими файлами — это остаётся ограничением. Воссоздать 'полированный' интерфейс Windows на Linux сложно, и даже dual-boot может быть технически сложной задачей.

Экспериментальный пакет golang.org/x/exp/simd предоставляет платформенно-независимый доступ к SIMD-инструкциям в Go, позволяя писать высокопроизводительный код для обработки массивов данных без привязки к конкретной архитектуре. Он абстрагирует низкоуровневые инструкции (такие как SSE, AVX, NEON) через универсальный API, где разработчик описывает операции над векторами, а компилятор и рантайм подбирают оптимальную реализацию под текущее оборудование. Это упрощает написание кода, который одновременно работает эффективно на x86, ARM и других платформах, избегая необходимости вручную писать ветвления по наборам инструкций или использовать cgo/ассемблер.

Пакет поддерживает типизированные векторные типы (например, v128 для 128-битных регистров) и операции над ними: загрузка/сохранение из памяти, арифметика, логические операции, перестановки и редукции. Особое внимание уделено безопасности и предсказуемости: все операции имеют чётко определённое поведение, включая обработку случаев, когда запрашиваемая ширина вектора недоступна на текущей платформе (в этом случае происходит паника или fallback на скалярный код, в зависимости от режима). В экспериментальном режиме пакет позволяет включать автовекторизацию через флаги компилятора, а также предоставляет инструменты для benchmarking и проверки генерации кода. Хотя пакет всё ещё находится в exp и может меняться, он демонстрирует путь к тому, чтобы SIMD стал доступной частью стандартного Go-стека для задач вроде обработки изображений, сигналов, криптографии и научных вычислений.

Экспериментальный пакет simd в Go дает прирост производительности от 30% до 5x по сравнению со скалярным кодом, при этом имея лишь небольшой оверхед относительно платформенно-специфичных реализаций. Это подтверждают тесты @ImJasonH, задачи по обработке видео и аудио (speech-to-text/text-to-speech). SIMD устраняет необходимость в CGO для векторизации, упрощая сборку и убирая зависимости от C/C++. Это делает Go привлекательнее для системных задач, включая разработку баз данных (например, streambed). Технические особенности: — Поддержка архитектур с переменной длиной вектора (SVE, RVV) обеспечивает будущестойкость. — Генерация специализированных версий функций при компиляции исключает runtime-накладные расходы. — Автоматическая векторизация в компиляторе Go (CL 791740) уже в разработке и показывает хорошую эффективность. Рекомендации и альтернативы: — Для максимальной скорости стоит использовать платформенно-специфичный код, оставив портативную реализацию как запасной вариант. — Чтобы сохранить портативность, длину вектора следует ограничивать минимально поддерживаемым размером целевых платформ. — В качестве альтернативы CGO можно использовать Go-ассемблер и пакет unsafe (как в go-pherence). — Предложено создать линтер для автоматической замены числовых циклов на SIMD-операции. Дискуссии: — Некоторые критикуют Go за игнорирование долгосрочных запросов (например, 13-летнее ожидание generics) при внедрении SIMD без явного спроса. — Возник спор о влиянии SIMD на проблему накладных расходов CGO: часть пользователей считает, что SIMD полностью устраняет необходимость в CGO.

Apple представила новый SpeechAnalyzer, который в тестах на 5 559 utterance‑ах показал лучшую точность среди всех сравниваемых систем. На чистом наборе LibriSpeech его WER составил 2,12 %, а на шумном — 4,56 %, что вдвое‑трижды лучше, чем у Whisper Small (3,74 % и 7,95 %) и в четыре раза лучше, чем у устаревшего SFSpeechRecognizer (9,02 % и 16,25 %). Модель работает полностью на устройстве, в три раза быстрее, чем Whisper Small, при этом требует в три раза меньше вычислительных ресурсов.

Переход с SFSpeechRecognizer на SpeechAnalyzer оправдан: ошибка в тексте снижается в 3‑4 раза, а качество транскрибирования становится более пунктуационно правильным и заглавным. Для английского распознавания на iPhone или Mac встроенный движок теперь превосходит даже Whisper Small как по точности, так и по скорости, хотя Whisper сохраняет преимущество в поддержке множества языков и кроссплатформенности. Поэтому разработчикам стоит мигрировать сразу, а остальные системы использовать только там, где требуется многоязычность.

Все результаты и исходные транскрипции открыты для проверки: вы можете загрузить JSON‑файлы с WER‑значениями и оценить их самостоятельно, что делает выводы независимыми и публично проверяемыми и легко интегрируемыми.

• Apple SpeechAnalyzer показывает в 3‑4 раз лучшую точность и в 3 раз быстрее, чем Whisper Small, при этом работает полностью офлайн на устройстве.
• Обсуждаются преимущества стриминговой транскрипции и поддержка тайм‑стампов, чего не хватает у большинства открытых моделей.
• Участники отмечают, что сравнение с лишь Whisper Small/​Base / Tiny бессмысленно – нужны тесты против Whisper V3‑Large, V3‑Turbo, Parakeet и Cohere Transcribe.
• Есть запросы добавить автодетекцию языка, более широкий набор языков и интеграцию в системный клавиатурный ввод.

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

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

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

Ubuntu 25.10 представляет поддержку архитектурных вариантов, в частности amd64v3 (x86-64-v3), позволяя оптимизировать пакеты под современные процессоры без потери совместимости со старым оборудованием. Для этого были изменены dpkg, apt и Launchpad, чтобы создавать несколько версий пакетов для разных уровней архитектуры. В текущем релизе около 2000 пакетов в компоненте "main" уже пересобраны, но они не прошли полное тестирование, поэтому возможны ошибки. Бенчмарки показывают прирост производительности около 1% для большинства пакетов и больше для числовых приложений.

Большинство облачных экземпляров и машин за последние 10 лет поддерживают x86-64-v3, что можно проверить командой ld.so --help | grep '\-v[0-9]'. Чтобы включить amd64v3, нужно установить последнюю версию dpkg и добавить конфигурацию APT::Architecture-Variants "amd64v3"; в /etc/apt/apt.conf.d/99enable-amd64v3, затем обновить систему. Важно, что после установки amd64v3 версий пакетов перенос жесткого диска на старое оборудование без поддержки x86-64-v3 станет невозможен. В 26.04 LTS эта проблема будет решена, а все пакеты будут пересобраны и полноценно протестированы.

• Ubuntu 25.10 предлагает оптимизированные пакеты для x86-64-v3 (AVX2), но не делает акцент на этом в анонсе.
• Сторонние репозитории уже предоставляют оптимизированные пакеты для разных уровней ISA, что делает спор о «1 % прироста» не столь значимым.
• Вопрос о том, стоит ли жертвовать совместимостью ради 1 %, остаётся открытым, особенно если учесть, что в будущем может появиться v4 или v5.
• Пользователи обеспокоены, что не смогут вынуть диск и загрузиться на старом ноутбуке в случае сбоя.
• Сторонние репозитории уже предоставляют оптимизированные пакеты для разных уровней ISA, что делает спор о «1 % прироста» не столь значимым.

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 медленный, он всё ещё может быть использован для большинства задач, и что важнее всего - он всё ещё может быть использован для большинства задач.

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