Исследование Банка Кореи показало, что применение ИИ снижает затраты рабочего времени на 3,8%. Но это снижение почти не выливается в увеличение выпуска. Объяснение даёт ещё одно исследование, в котором рассматривалось производство софта. ИИ действительно увеличивает скорость создания кода, но на каждом следующем этапе - пул реквест, проект, готовый релиз - эффект уменьшается. Ревью, интеграция, тестирование, релиз и другие этапы становятся "узкими местами", всё ещё требующими человеческого участия. Индустрия медленно подстраивается под меняющиеся условия.

Ну и по поводу супер эффективного ИИ, которое всех заменит https://t.me/gus_vasili/7987

Вспомнил, как мы в Джетбрейнс делали текстовый редактор, ну как мы, его еще до меня делали, несколько лет, а тут я прихожу, включаю потестировать, смотрю — строки не переносятся. А че, говорю, давайте Word Wrap включим. И на меня вся команда как посмотрела. Я такой: че такое, че не так? Неудобно? Не, удобно, говорят. Только под капотом РЕАЛИЗОВАНО НЕЭФФЕКТИВНО. В смысле не у них конкретно, а в целом, в любом редакторе, текст с Word Wrap (когда строка по достижении правого края окна сама переносится на следующую, а не уходит за край) рендерить дороже, чем без. Не то чтобы это как-то было заметно на практике, просто как ты его включишь, если будешь знать, что компьютеру там под капотом придется напрягаться? Вот такие вот ПТСР бывают у ИДЕ-разработчиков. А потом мы еще эмоджи и RTL прикручивали.

Почему ИИ может не привести к росту ВВП Когда говорят об ИИ, то обычно утверждают, что он позволит повысить производительность труда, что в результате приведет к росту ВВП. И действительно, рост производительности труда необходим для роста ВВП. Чего вам не скажут апологеты ИИ, так это то, что это не произойдет автоматически. Это кропотливая работа. Более того, при определенных стечениях обстоятельств ВВП может и упасть на десятки процентов. Сегодня хочу вам наглядно показать несколько случаев, в которых ИИ может не привести к росту производительности и росту ВВП: 1. ИИ используется не там. Бесполезно использовать средство повышения производительности в той части процесса, которая не является бутылочным горлышком, потому что потеря производительности будет происходить на другом участке. Элияху Голдратт очень наглядно описал это в своей книге “Цель” на примере завода, который купил дорогого робота, но установил его не в той части производственной цепочки. Робот очень быстро выполнял свою работу, но дальше был затор. В итоге робот простаивал 99% времени. Автоматизация есть, а производительность не растет. Но это, пожалуй, самая простая часть уравнения, которую можно решить. Кстати, в 1970-1980 гг. такое уже было. Почитайте про productivity paradox. Технологии были, а производительность не росла. 2. У клиентов нет денег, чтобы купить ваш товар, или кризис перепроизводства. Очень часто технари забывают, что мало сделать классный продукт. Нужно еще, чтобы его купили. А если у ваших покупателей денег нет, то даже если продукт им очень нужен, они его не купят. Ну а если много людей теряет работу и они не могут по 6-12 месяцев ее найти, то естественно у них становится меньше денег. Соответственно они меньше покупают. А теперь если предположить, что эти люди не найдут работу никогда, то они никогда у вас ничего и не купят. Возможно, из уроков истории вы слышали про кризисы перепроизводства. Например, во времена Великой депрессии ВВП США упал на 26% с 1929 по 1933 гг., а безработица в пике достигала 25%. 3. У клиентов есть деньги, но они экономят. Вообще для роста ВВП самым важным является оптимизм и уверенность в завтрашнем дне ваших клиентов. Если люди знают, что у них завтра будет доход, то они смелее тратят деньги и берут кредиты. А если они напуганы, то откладывают деньги на черный день и отказываются от необязательных трат. Именно поэтому Центробанки всех стран прикладывают максимум усилий, чтобы показать предсказуемость своей политики и дать оптимизма рынкам. С этим кстати, на мой взгляд, ИИ вендоры сейчас очень плохо справляются. Графики прогнозов ужасающих сокращений людей помогают продавать на страхе. Но они также и убивают уверенность в завтрашнем дне. Кстати это одна из причин, почему я не люблю хайпы, хотя и понимаю, как они работают. Завершить этот пост я хочу словами Царя Соломона, который он сказал несколько тысяч лет назад:  “Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас.” Применительно к ИИ можно часто слышать, что мы находимся в точке, которой не было никогда. Хочу напомнить, что еще в 1820 году 70% населения США было занято в сельском хозяйстве и не занималось интеллектуальным трудом. Сейчас в мире секторе работает всего 27% (и всего 1% населения в США), при этом численность населения планеты выросла с 1.1 млрд. до 8.2 млрд. человек. Правда по пути человечеству пришлось пережить две разрушительные войны. Надеюсь, мы сможем выучить ошибки прошлого в этот раз.

Вайб-релиз Bun на Rust На моей памяти это первый настоящий вайб релиз такого масштаба. Помните тот PR команды bun на миллион строк, который им Claude Code сгенерил. Так вот, прошло чуть более 3 месяцев и они зарелизили апдейт для всех. И результаты впечатляют - мало того, что по множеству метрикам ощутимый прирост, так ещё и +1.5к новых тестов с node.js теперь проходят и на bun (это 80.5% всех тестов node.js). Для меня лично наиболее интересный выигрыш в возможности ускорить тесты в наших проектах на node runtime, ибо с приходом агентной разработки, количество тестов выросло кратко, а выполняться они стали неприлично долго. Попробую обязательно. А если вдруг кто-то уже успел попробовать новый bun - поделитесь в комментариях своим опытом, интересно почитать. Браво команде bun и Антропикам, их купившим. https://bun.com/blog/bun-v1.4 @ai_driven

Привет! Вас стало больше, так что пора наконец представиться 🙂 Я Даша, давно пишу на Go, но на своем тернистом пути постоянно нахожу интересности во внутренностях языка. Пишу про производительность, работу с бд и свои наблюдения, которыми грех не поделится. Параллельно развиваю свой поисковый движок - fts-engine: https://github.com/dariasmyr/fts-engine Из-за него тут регулярно появляются посты про full-text search, индексы, фильтры, хранение данных и разные эксперименты вокруг темы поисковиков. Пока тут легкий хаос с темами: от рабочих кейсов до иногда странных углублений в исходники и ищьюс ;’) Чтобы во всём этом было чуть проще ориентироваться, я разметила посты тегами:

#go - Go, рантайм, реализации техник и описание внутрянки #perf - производительность, профилирование и бенчи #db - базы данных, оптимизации #fts - поиск, индексы и устройство движка #projects - мои проекты и эксперименты

Пишите, если заинтересовала какая то тема или идея, буду рада обсудить. Welcome!

Нас в стартапе двое. И с кем-то, кажется, пора расставаться. Мы вместе с 2022 года. Когда начинали, он был в отличной форме. Он тогда вообще считался одним из лучших на рынке. Поэтому я был уверен, что ближайшие несколько лет вопрос с ним закрыт. Первые годы так и было. Я мог навалить на него работы с утра до вечера, он справлялся. Новые задачи подхватывал быстро, работал практически без остановки. В общем, никаких вопросов. Но постепенно возраст начал давать о себе знать. Сначала заметил, что без постоянного питания он уже долго не выдерживает. Раньше мог спокойно работать почти весь день. Потом начал уставать. Если дать одну задачу - всё хорошо. Две-три одновременно уже заметно тяжелее. А если я в течение дня несколько раз меняю приоритеты, может вообще отказаться что-либо делать. Последнее время стало совсем плохо. Вчера я в очередной раз навалил на него работы, и он просто остановился. Сказал, что больше не может, не хватает памяти. Хотя справедливости ради, вопросы есть и ко второму... Постоянно придумывает новые проекты. Берётся за несколько одновременно, не умеет нормально расставлять приоритеты. Может сегодня попросить сделать одно, завтра всё переделать, а послезавтра решить, что теперь вообще делаем другой продукт. Возможно, первый просто стал жертвой плохого менеджмента. Но бизнес есть бизнес. Компания растёт, задачи становятся сложнее, а он явно перестал вывозить. При этом нанять кого-то нового дорого. Мы всё-таки стартап, денег нет, но задач становится только больше, и выбора нет. Да и с другой стороны, сколько можно работать из одной только сентиментальности? Мы многое прошли вместе, но в какой-то момент надо признать очевидное. Мой сооснователь с 2022 года MacBook M1 Pro. И, похоже, пришло время менять состав команды. Правда не факт, что с новым сотрудником будет лучше, учитывая непостоянство первого.

Вы удалили большой файл с логами, но место на сервере не освободилось. Причина может быть в программе, которая всё ещё использует этот файл — для системы он как будто продолжает существовать. Сервер может тормозить и при нормальной загрузке. Например, если он работает на общем оборудовании и другие виртуальные машины забирают слишком много ресурсов. А плохая связь с сайтом не всегда означает, что проблема именно на вашем сервере. Автор собрал простую инструкцию, которая помогает понять, где искать сбои. Они могут быть в интернете, настройках домена, открытых портах, памяти, диске или программах. В конце есть готовый скрипт, который сам запускает основные проверки и собирает результаты в одном месте.

Прочитал замечательную статью: The Linux Scheduler: a Decade of Wasted Cores

“And you have to realize that there are not very many things that have aged as well as the scheduler. Which is just another proof that scheduling is easy.” Linus Torvalds, 2001

20 + лет спустя

As a central part of resource management, the OS thread scheduler must maintain the following, simple, invariant: make sure that ready threads are scheduled on available cores. As simple as it may seem, we found that this invariant is often broken in Linux. Cores may stay idle for seconds while ready threads are waiting in runqueues. In our experiments, these performance bugs caused many-fold performance degradation for synchronization-heavy scientific applications, 13% higher latency for kernel make, and a 14-23% decrease in TPC-H throughput for a widely used commercial database

и

The Group Imbalance bug The bug. We encountered this bug on a multi-user machine which we used to perform kernel compilation and data analsis using the R machine learning package. We suspected that this system, a 64-core, eight-node NUMA server, did not use all available cores for highly-threaded computations, instead crowding all threads on a few nodes. We illustrate this bug with the output from our visual tool

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

Python: как один из самых медленных языков стал королем нейросетей В наборе тестов USENIX приложения на CPython отработали в среднем в 29,5 раза медленнее, чем те же программы на C++. При этом именно Python стал основным инструментом машинного обучения и держит первую строчку в рейтинге TIOBE, опережая C, C++ и Java. Самый медленный в этой компании язык возглавил область, где всё упирается в скорость вычислений. Разгадка в том, что тяжёлую математику Python выполняет вовсе не сам. Один его вызов способен запустить перемножение матриц из миллионов элементов, и вся нагрузка при этом уходит в скомпилированное ядро на C++ или CUDA. Получается, что в такой работе программа большую часть времени проводит за пределами самого Python.

Недавно нужно было оптимизировать скорость выполнения разных LLM задачек —> что сработало: 1) Переход на модели поменьше - с подкручиванием промптов, в том числе сократить/выключить reasoning. Кстати, идеальная задача для /goal команды: просите крутить промпты, пока не получите оптимальное соотношение скорости и качества 2) Сократить обьем output, а потом и input токенов - более компактная структура, выкидывание ненужного 3) У gemini есть настройка приоритета; но вызов тогда стоит в ~2 раза дороже 4) Анализ использования кэша —> фикс промптов и последовательности подачи контекста P.S. Классические вещи типа параллелизации запросов я не покрываю тут; здесь скорее llm specific вещи

Вышел TypeScript 7.0 стал быстрее в 10 раз. что сделали: - Переписали компилятор на Go → нативная скорость + многопоточность - Ускорение сборки: x7.7 – x11.9 на реальных проектах - VS Code (repo): 125.7s → 10.6s - Sentry: 139.8s → 15.7s - Playwright: 12.8s → 1.47s - Память: -6% до -26% - First error в редакторе: 17.5s → 1.3s (x13 быстрее) Реальные кейсы: - Slack: -40% времени merge, CI check 7.5 мин → 1.25 мин - Microsoft: -400 часов в месяц на сборку билдов - Canva: ошибки в редакторе 58s → 4.8s Вопрос: сколько стоит 1 минута ожидания в вашей команде? Это классический эффект второго порядка. Вы ускоряете не билд. Вы ускоряете итерацию гипотез. - Было: 5–10 циклов в день - Стало: 30–50 циклов А значит: - быстрее проверка фичей - меньше batch-thinking - выше скорость обучения команды Это уже не DevEx. Это growth-фактор продукта.