Эффективная работа с git worktree Если вы уже дошли до точки, когда параллельные агентские сессии как не в себя делают фичи, то вы точно должны были столкнуться с новыми проблемами, среди которых одновременный запуск нескольких копий приложений, быстро забивающийся диск и оперативная память, плюс работа которая встает колом из-за одновременных запусков тестов и линтеров. В этом посте я расскажу про то, как поправить свой сетап, чтобы все стало снова летать. Сначала быстрый рекап. Worktree это фича гита, которая создает под ветки отдельные физические директории в которых можно вести работу. Раньше этой фичей почти не пользовались, так как просто переключались на ветку, сейчас же переключение на ветку будет сбивать параллельные сессии, поэтому все перешли на worktree. Даже если вы этого явно не просите, агенты нередко сами пользуются ими (но не всегда). И так поехали, проблемы и их решения. Отказ от веток Если вы пошли по этому пути, то лучше явно описать агенту, что ветки использовать нельзя, а вместо них нужно создавать worktree. Иначе регулярно будет возникать ситуация, когда один из агентов прыгнет на ветку и помешает другим. Начало и завершение работы По умолчанию создание worktee просто копирует данные, но в таком виде проект врядли заработает и на нем можно будет прогонять тесты. Скорее всего есть какие-то подготовительные шаги от установки зависимостей до создания .env. Вот эту часть нужно сначала автоматизировать, например, с помощью make-команд, а потом уже зафиксировать в доках с агентом, чтобы он вызывал их как при создании рабочего дерева, так и при завершении работы. У себя я считаю завершением это отправку pr, в это время происходит чистка. Независимые базы данных Помните проблему миграций в ветках? Вот здесь будет тоже самое, если не создавать отдельные базы данных под каждое дерево. Сделать это просто, достаточно объяснить агенту задачу и он сам предложит способ формирования динамического имени, связанного с названием worktree. Дальше снова автоматизируем и добавляем в команду создания worktree из предыдущего шага. При этом важно сделать так чтобы это были именно базы данных, а не субд, иначе если на каждое дерево будет подниматься свой postgresql, вы быстрее начнете упираться в производительность Одновременные запуск приложения Кроме баз, такой же трюк надо провернуть с портами (и если используется dns то доменами). Каждое дерево при старте тестов или приложения должно работать со своим набором портов. Опять же, эту задачу сделает сам агент, он без проблем напишет небольшие скрипты, которые находят свободные порты и подсовывают их при старте приложения Параллельный запуск проверок Но даже если сделать все шаги выше, все равно запуск тестов или линтеров из двух worktree, уже может поставить колом всю машину. Здесь есть красивый выход через блокировку. Нужно запускать проверки не напрямую, а через утилиту, которая ставит такие блокировки и упорядочивает запуск (с нужным уровнем параллельности). Пока я этим занимался написал такую утилитку https://github.com/mokevnin/heavy Шаринг данных Ну и последнее, установка зависимостей и кеши. Если вы не хотите чтобы место на диске улетало со скоростью ветра, то нужно использовать инструменты или настраивать существующие так, чтобы они шарили (безопасно) все свои артефакты во внешних директориях. Например лучше работать с pnpm, а не npm, потому что первый хранит зависимости во внешнем сторадже, что очень сокращает потребляемое место. Если все это сделать, то работать с worktree станет реально удобно и быстро. Пользуйтесь 🙂 Telegram | YouTube | ИИ для разработчиков

Qualcomm подчистила графики с тестами процессора Snapdragon C Спустя неделю после презентации Snapdragon C компания Qualcomm изменила официальные слайды. Из материалов удалили результаты двух тестов энергоэффективности против процессора Intel N250 — показатели в веб-серфинге и в режиме простоя приложений. В первой версии презентации чипмейкер заявлял о преимуществе над Intel на 68% при браузере и на 39% в фоновых задачах. Представители Qualcomm объяснили правки желанием «повысить точность наглядных данных», но не дали технических пояснений. Остальные графики, включая превосходство на 106% при просмотре Netflix, оставлены без изменений.

RTX Spark проиграл в чипу M4 Max в CPU-тесте Cinebench 2026 Первый ноутбучный SoC от NVIDIA, RTX Spark, в одноядерном тесте Cinebench 2026 набрал 540 баллов — примерно на уровне трехлетнего Apple M3 Max. В многоядерном тесте 20-ядерный чип от Nvidia набрал 5771 баллов, что на 35,6% меньше, чем у M4 Max. И это при том, что тест проводился в режиме High Performance на Surface Laptop Ultra. Правда, активировать его оказалось непросто — энтузиасту с форума TechPowerUp пришлось включать скрытую настройку, чтобы выжать из чипа 50 Вт мощности при частоте 2,8 ГГц. При этом ядра Cortex-X925 теоретически способны разгоняться до 4 ГГц — либо Microsoft сознательно ограничила производительность, либо система охлаждения не справляется. Сердце RTX Spark — 8 ядер Cortex-X925 и 12 Cortex-A725 т.е. прошлогодние ARM-ядра в сборке от Mediatek, и это не кастом-ядра, которые зеленые использует на серверах.

Вышли первые тесты Ryzen 7 7700X3D — 8 ядер, 16 потоков, Zen 4, AM5. По сути, это урезанная версия Ryzen 7 7800X3D с рекомендованной ценой $329: базовая частота снижена до 4,0 ГГц, а буст ограничен 4,5 ГГц против 5,0 ГГц у старшей модели. Объём кэша L3 остался прежним — 96 МБ за счёт 3D V-Cache. В играх 7700X3D уступает 7800X3D немного в пределах 2-5%. В синтетике вроде Cinebench отставание более заметно: 7700X3D набрал 92% результата 7800X3D в одноядерном тесте и 93% в многопоточном. Если сравнивать с 5800X3D, то в тесте KitGuru c 9070 XT в FullHD 7700X3D быстрее, чем 5800X3D аж на 38%! При этом разница между 7700X3D и 7800X3D менее 4%, а между 7700X3D и 9800X3D за $479 около 7%. По цифрам выходит неплохой проц для игр, но не для рабочих задач.