Hacker News Digest

PR оптимизирует процесс хеширования при извлечении wheel-файлов в uv, переиспользуя один 64 KiB буфер вместо выделения нового для каждого файла. Это сокращает количество аллокаций буфера с 11 120 до одного при обработке PyTorch wheel, сохраняя размер буфера на активное wheel. Измерения показывают ускорение холодной установки: AnyIO — на 2,6%, SymPy — на 8,3%, NumPy — на 9,5%, PyTorch CPU — на 7,8%, а среда из 14 пакетов с конкурентностью 4 — на 7,0%. Изменения были применены поверх коммита a188b8e833aef3c3b4b60a32ed9fafe6ac74186a и позже слиты в main. PR также включает исправления: не доверять хешам из прямых URL в метаданных wheel при --require-hashes, использовать совместимую версию Azure Storage API для анонимных и аутентифицированных запросов, скрывать параметр sig в URL и рассматривать проекты ниже уровня workspace-глобов как standalone. Обновлена зависимость astral-tokio-tar до 0.7.0 с учётом эффективных размеров при отслеживании жёстких ссылок. PR был сгенерирован Mend Renovate CLI и прошёл ревью.

Обсуждение подтверждает, что uv ускоряет тёплые установки благодаря кэшу распакованных wheel‐ов и жёстким ссылкам, но реальный выигрыш в скорости для большинства проектов незначителен (1 с против 0,1 с), а старые бенчмарки pip завышены, поэтому пользователи часто не замечают разницы. Утверждается, что единственное реальное преимущество uv перед pip — параллельное асинхронное извлечение, и если pip реализует аналог, он может догнать uv; жёсткие ссылки при этом считаются опасными и зависят от ОС. Отсутствие команды «uv download» и рост кэша при множестве окружений вызывают опасения; предлагается двухуровневое кэширование для ограничения диска. Сокращение кэша на ~10 % ценой 4 % замедления и усложнения кода большинство считает невыгодным. Среди реальных удобств uv отмечают установку из git без сборки пакета, использование BLAKE3 для дедупликации и быстрых проверок целостности (хотя некоторые предпочитают xxHash), а также объединение в одном бинарнике управления версией Python, автосоздания .venv, поддержки pyproject.toml и запуска скриптов — даже если по отдельности эти функции не уникальны.

Карпати утверждает, что понимание обратного распространения ошибки (backprop) критически важно, несмотря на автоматизацию в фреймворках вроде TensorFlow. Он называет backprop "утечкой абстракции" — опасно верить, что просто соединяя слои, можно "магически" обучить сеть. Студенты курса CS231n жаловались на ручную реализацию backprop в numpy, но Карпати настаивает: без понимания математики невозможно диагностировать проблемы обучения.

Яркий пример — сигмоидные функции. При плохой инициализации весов сигмоиды "насыщаются" (выходы близки к 0 или 1), делая локальный градиент z*(1-z) равным нулю. Это полностью останавливает обучение. Даже при нормальных условиях градиент сигмоиды не превышает 0.25 (при z=0.5), что означает его 4-кратное ослабление при каждом проходе. Для сетей с сигмоидами нижние слои учатся значительно медленнее верхних.

• Обсуждение вращается вокруг статьи Карпати "Yes, you should understand backprop" и его тезиса о том, что понимание backprop важно, даже если вы никогда не будете писать его вручную.
• Участники спора сомневаются в ценности этого подхода, указывая на то, что современные фреймворки и высокоуровневые абстракции делают знание деталей неактуальным.
• Некоторые участники подчеркивают, что даже если вы не будете реализовывать backprop вручную, понимание принципов работы оптимизаторов и функций активации важно для отладки и проектирования моделей.
• Обсуждение также затрагивает вопрос о том, насколько важно понимать детали, когда вы пользуетесь высокоуровневыми инструментами, и какие уровни абстракции считаются приемлемыми.
• В конце концов, спор сводится к тому, что хотя фундаментальное понимание важно, но не стоит забывать, что большинство практических задач будут решаться с помощью высокоуровневых инструментов и фреймворков.

Команда Wasmer анонсировала бета-поддержку Python в своей edge-платформе на базе WebAssembly. Это позволяет запускать популярные фреймворки вроде FastAPI, Django и Streamlit, а также библиотеки типа numpy и pandas — всё в песочнице с почти нативной производительностью. Ключевые улучшения включают динамическую линковку, поддержку сокетов, потоков и собственный индекс пакетов.

Производительность впечатляет: тесты показывают, что Python на Wasmer работает всего на 5% медленнее нативного, при этом обеспечивая изоляцию и портативность. Платформа уже обгоняет Cloudflare по поддержке мультитрединга и нативных модулей, а вскоре добавит полную поддержку PyTorch и других тяжёлых библиотек.

• Запуск Python в WebAssembly через Wasmer предлагает производительность, близкую к нативной, и обеспечивает надежную песочницу для выполнения кода.
• Обсуждаются практические применения: встраивание скриптов в приложения, серверные API (FastAPI, Django) и выполнение пользовательского кода в изоляции.
• Поднимаются вопросы о поддержке ключевых библиотек (numpy), асинхронности (asyncio) и межъязыкового взаимодействия (Python-JS).
• Отмечаются существующие альтернативы (Pyodide, контейнеры) и сложности с зависимостями, имеющими нативные расширения.
• WASM рассматривается как более простая и легковесная альтернатива виртуальным машинам и контейнерам для развертывания.

Современный Fortran может быть предпочтительнее Python для обучения основам численной линейной алгебры из-за строгой типизации и явного управления памятью, что помогает студентам лучше понять внутреннюю работу алгоритмов. В Python студенты часто полагаются на готовые функции вроде np.linalg.solve, что скрывает детали реализации и приводит к ошибкам, связанным с динамической типизацией и неправильной индексацией массивов. Например, путаница между списками и массивами NumPy или неявное приведение типов могут затруднить отладку.

Fortran, напротив, требует чёткого объявления переменных и размеров массивов, что снижает риски ошибок и заставляет студентов продумывать структуру данных. Это особенно важно для таких задач, как метод Гаусса-Зейделя или метод наименьших квадратов, где понимание циклов и операций с матрицами критично. Хотя Python с его экосистемой удобен для сложных проектов, Fortran обеспечивает более прозрачный переход от математических формул к коду, укрепляя фундаментальные навыки.

• Обсуждается выбор языка для преподавания численных методов и линейной алгебры (Python, Fortran, Julia, C++ и др.), где Fortran хвалят за производительность и удобство для математики, а Python — за распространённость и простоту.
• Критикуется чрезмерно объектно-ориентированный подход в C++ для научных вычислений, а также сложности и "бородатость" некоторых языков (например, Fortran) для новичков.
• Поднимается вопрос о важности баланса между теоретической "чистотой" языка и его практической полезностью для будущей работы студентов.
• Отмечаются преимущества Julia и MATLAB/Octave для обучения благодаря близости их синтаксиса к математической нотации и удобным инструментам.
• Упоминаются проблемы с ошибками в Python (например, типизация и сообщения об ошибках), а также сложности отладки в сравнении с другими языками.