Программирование *

Я наткнулся на пост в X/Twitter, где Pritam обнаружил, что его решение на Leetcode работало медленнее, когда он использовал встроенную функцию min, и производительность улучшилась, когда он реализовал min прямо в своем коде на Python.

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

Автор на этом скриншоте использовал Python 2, который на данный момент уже стал древностью. За последние 10 лет Python 3 получил множество релизов, и последние версии были нацелены на улучшение производительности языка. Так действительно ли вызовы функций по‑прежнему так сильно влияют на производительность в Python?

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

▍ Если ты (или твоя команда) постоянно стреляешь себе в ногу, то почини ружьё

Один из моих старых постов о strlcpy недавно вызвал обсуждения на различных форумах. Вероятно, с этим как-то связан выпуск новой версии POSIX. Многие авторы приводили один контраргумент, который я слышал и раньше:

«В общем случае, когда исходная строка умещается в конечный буфер, strlcpy будет обходить строку только один раз, а strlen + memcpy будут обходить её дважды».

Под этим аргументом скрывается допущение о том, что однократный обход строки выполняется быстрее. И, честно говоря, это вполне разумное допущение. Но справедливо ли оно? Об этом мы и поговорим в статье.

В декабре 2023 года я выпустил 175 Pixel Font Megapack, за которым вскоре последовали 42 отдельных пака для каждого из семейства шрифтов. Я создал собственный тулчейн для генерации, тестирования и развёртывания этих шрифтов... на Rust! В посте я расскажу об этом процессе.

Введение

Мы покажем, что система, имеющая лишь команды GNU find и mkdir, полна по Тьюрингу.

Хорошо известно, что команды sed и awk сами по себе полны по Тьюрингу, но мне не удалось найти информации о Тьюринг-полноте find + mkdir.

Доказательство основано на реализации таг-системы.

Мы по порядку рассмотрим реализацию цикла, FizzBuzz и таг-системы.

Примечание: основная часть изложенного в статье относится к реализации SMT компании Intel, также называемой гипертредингом (hyper-threading). Она основана на научной статье компании, опубликованной в 2002 году.

Мы будем считать 1000,000,000 число Фибоначчи со всеми цифрами. Для этого я буду использовать продвинутый алгоритм для поиска чисел Фибоначчи. Тут не будет базовых алгоритмов на подобии матричного возведения в степень и проще. Но эта статья будет понятна и школьнику :-)

Привет! Меня зовут Виталий, я тимлид в KTS, и за годы работы я провел больше 100 собеседований.

Кто-то на собеседовании от вас может ожидать знание 50-го аргумента функции callKek(), но это не мой подход, потому что в реальной жизни глубокого знания JavaScript не всегда бывает достаточно, а отдельные его тонкости и вовсе пригождаются крайне редко.

В статье я расскажу о своем подходе к найму сотрудников и поделюсь множеством рекомендаций тем, которые стоит изучить.

high_impact

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

Столкнувшись много раз подряд с тем, что найти что-то толковое довольно непросто, я решил попробовать распутать это узел и предложить для русскоязычных читателей свой справочник классных библиотек на С++. Я исходил из этого источника. Это очень многогранный и объемный список библиотек языка С++, но, скажем так, у меня были к нему вопросы. Потому я сделал перевод, затем значительно улучшил его в плане содержания (далее объясню, как, почему и зачем). На выходе получилось около 1000 библиотек. Как в сказке). Они, конечно, не покрывают все возможные задачи и предметные области, но поверьте, они затрагивают действительно многое.

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

Привет, Хабр!

Давайте знакомиться: меня зовут Никита Соболев, я core‑разработчик CPython, mypy и typeshed. Некоторое время назад я понял, что на русском языке довольно мало контента про устройство CPython внутри. В основном доклады с конференций и статьи. Где‑то про память, где‑то про GIL, где‑то про парсер. Но чтоб системно и по всем основным частям в одном месте — такого я не нашел.

И решил сделать своё! Под катом я расскажу, как я делаю «Лучший курс по Питону»* на ютюбе. Почему он бесплатный. И почему он такой, какой есть. А еще я расскажу, какая польза будет разработчикам от его просмотра.

Всем привет! Меня зовут Сергей Яхницкий. Я пишу на Python уже больше шести лет, техлид в Яндекс Такси, Python-евангелист и член Python-комитета Яндекса (аналог Python Steering Council).

Человек я простой, звёзд с Гитхаба не хватал: до того, как я устроился в Такси, я мирно писал маленькие бэкенды на Python. А потом меня прорвало: кодогенерации, CI/CD, кучи тестов, монорепа и прочее. Вот тут-то моя питоничья душа и воспряла. Решил я всё автоматизировать, обновить всё, что движется, а что не движется — подвигать и обновить. Из этого вышел мой рассказ.

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

Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

Почему тормозит я вам не скажу: возможно разработчики, которые делали её (на не самом новом движке, надо сказать) просто делали игру и не задумывались о рядовых игроках, которые сидят на пятилетнем железе, хотя даже пятилетнее железо уделывает приставки текущего поколения. Возможно это другая причина - когда твоя рабочая машина с 64 гибайтами оперативки и 4080 на борту тянет редактор, то беспокоиться об игроках можно начинать после патча первого дня.

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

Меня зовут Антон Гращенков, и я занимаюсь развитием Java в Альфа-Банке. Программированием увлекаюсь ещё со школы: писал на множестве разных языков — от Pascal до TypeScript, мне это просто нравится. В статье я на примерах покажу, для каких задач я использую локальные модели. Да, существует много инструментов доступных в облаке, — тот же ChatGPT, Copilot или YandexGPT. Однако можно запустить такую модель и локально, и сделать это крайне просто. 

Ведь если хочется, то почему бы и да?