Почему ИИ может не привести к росту ВВП Когда говорят об ИИ, то обычно утверждают, что он позволит повысить производительность труда, что в результате приведет к росту ВВП. И действительно, рост производительности труда необходим для роста ВВП. Чего вам не скажут апологеты ИИ, так это то, что это не произойдет автоматически. Это кропотливая работа. Более того, при определенных стечениях обстоятельств ВВП может и упасть на десятки процентов. Сегодня хочу вам наглядно показать несколько случаев, в которых ИИ может не привести к росту производительности и росту ВВП: 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-фактор продукта.

Теорема о тормозах Поговорим о ситуациях, когда компьютер тормозит. Под тормозами понимается медлительность, мешающая свободному взаимодействию и тем самым вызывающая фрустрацию и раздражение. Если компьютер скачивает пять гигабайт данных, компилирует сложный проект или рендерит видео, это занимает ощутимое время, но это не тормоза: мы дали компьютеру задачу, и он работает, выполняет. Теперь допустим, что видео рендерилось час, потом отобразился статус «Завершено», а через секунду готовый файл отобразился на рабочем столе. Первый час компьютер не тормозил, но следующую секунду — тормозил. Теорема: все тормоза являются ошибками и исправимы. Технически даже своевременное отображение статуса или реакции не действие пользователя — это такая же «работа», как и рендеринг видео. Однако такая работа должна быть выполнена за время, которое человек не способен ощутить. Будем называть это «мгновенно». Примеры тормозов в современно софте: — при запуске программы нельзя сразу же начать ей пользоваться, а нужно ждать загрузки; — после загрузки часть интерфейса дорисовывается на глазах у пользователя; — при нажатии на кнопку нет мгновенной реакции; — при вводе с клавиатуры символы появляются не мгновенно; — при прокрутке страница едет не плавно или с отставанием от пользователя; — при прокрутке часть содержимого догружается на глазах у пользователя, а не приезжает уже готовым из-за края окна; — при изменении размеров окна разные части интерфейса перерисовываются на глазах у пользователя с разной скоростью или в несколько «прыжков»; — при перетаскивании объекта программа понимает, что может «принять» его, не мгновенно; — после открытия меню, на глазах у пользователя в нём добавляются пункты или меняется их порядок; — разные части интерфейса реагируют на действия пользователя через разное время. Во времена первых компьютеров тормоза были неизбежны, потому что мало что можно было сделать мгновенно. Но как минимум последние двадцать лет компьютеры на несколько порядков быстрее, чем необходимо для мгновенности, а значит и для полного отсутствия тормозов во всех случаях. Если программа тормозит, это лишь значит, что в тот момент, когда она должна мгновенно отобразить данные или отреагировать на действие пользователя, она занята чем-то другим. Это что-то другое — ненужная в данный момент, лишняя работа. Это ошибка в программе, и она должна быть исправлена. Лишняя работа должна перестать делаться и мешать пользователю пользоваться компьютером. Таким образом, тормоза нельзя списать на слабое железо; это слабость исключительно её автора.

Греф сказал вслух то, о чём молчат советы директоров Сбер создает антропоморфных роботов, которые смогут заменить человека в физическом мире. И это необходимость, люди работать руками не хотят, производительность труда стоит на месте, рук не хватает. Выступая на ГОСА-2026, Герман Греф заявил: - экстенсивный рост экономики исчерпан, а загрузка производственных мощностей находится на пределе. По оценкам, снижение объема инвестиций по итогам года составит от 2% до 4%. - ИИ — единственный инструмент, способный дать качественный прирост там, где количественный исчерпан - Без инвестиций в технологии и модернизацию переход невозможен — не как опция, а как условие выживания - Компании, которые не адаптируются сейчас, потеряют конкурентоспособность в горизонте 3–5 лет

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

ИИ в менеджменте это не "автоматизировать рутину", а пересмотр самой логики работы: какие задачи вообще должен решать человек, а какие — ИИ.