До речі, прочитати про це більше ви можете у статті Head of Engineering Solidgate Макса Багінського, в якій він розповідає про втрату $10,000 за хвилину даунтайму нашої системи.

Це 432 мільйона на місяць. Немає у вас таких грошей, хлопці.

Не можна рахувати об’єм транзакцій за втрати. Бо:
1. Ви берете собі лише 3% і ой! Це вже не 10К а 300$. А ще, то напевне є найгірший випадок..
2. Насправді ніхто нічого не втрачає, якщо воно не впало менш ніж на 2-3 години. Бо люди це такі істоти які вміють в retry із exponential backoff. Якщо у людини не пройшла транзакція, вона спробує повторити пізніше.

$10.000 за хвилину

Це 10К*60*24*30 = 432M на місяць. Вибачте, але у вас не як не може бути 400 мільйонів прибутку на місяць.

Далі читати немає сенсу. Це маркетинговий буллшіт.

Нащо поліграф у 21 сторіччі якщо є карти таро?

Знання вони як гроші — якщо їх не має, то вони «непотрібні», а якщо є то виявляється, що використовувати їх не дуже й складно. І використовуються вони якось самі та автоматично.

Він задепрекейтен лише якщо є якісь потоки окрім мейн. Бо це може спричиняти неприємні баги. Якщо форк виконувати до того як є потоки усе норм. Тобто, рекомендація наступна:
1. Стартуєте апп
2. Завантажуєте у памʼять усі необхідні статичні дані в основному потоці
3. Робите форк якщо хочете у мультіпроцес
4. Завершуєте ініціалізацію апи (тепер у незалежних процесах). Саме тут повинні запуститися усі допоміжні потоки накшталт експорту телеметрії
5. Інформуєте основний процес, що ваші «сабпроцес» вже готові приймати ревести

А нащо?
— якщо ви сайти робите (Django whatever), то мабуть використовуєте мултіпроцессінг через uvicorn
— якщо ви робите ML — усі ML ліби (torch, numpy, sentence transformers ітп) — відпускають GIL. А деякі навіть мають внутрішні thread pools (на рівні С extensions) щоб множить ваші матриці ефективно
— якщо ви намагаєтеся робити обробку даних саме на пайтон (без С backed extensions)... ну то добре але якщо це одноразовий скріпт/ноутбук (почекайте та випийте кави). Бо пайтон дуже повільний — увесь пайтон ML базується на концепції того, що Пайтон — це лише оркестратор який викликає оптимізовані С ліби

Якось не дуже доконливо, цифри якись завеликі так само як і розбіжність поміж країнах. А ви впевнені що вашої статистики можна взагалі довіряти? Яки ви тип тесту використовували, скільки було даних, як ви контролювали похибку та вирішували коли зупиняти тест? Чи ви дивились результат один раз як повинно бути чи ні? Якщо дивились кожен день (умовно), чи ви використовували якісь корекції або методи аналізу щоб уникнути неконтрольованого росту похибки? Бо статистика займає почесне місце посеред найбільш розповсюджених типів брехні — десь поміж «нахабною брехнею» та «політикою».

Ну звісно ж з декількох. Сенс у тому що ви не зможете написати такий ООП метод щоб його використання коротше за приклад вище. Ну тобто зможете, але лише якщо зробите expensive computation віртуальним методом (але ж це ускладнення). Це все через те що декоратор дозволяє виконати щось ДО І ПІСЛЯ виклику декорованого методу. Це принципово для таких речей як той же кеш.

Тепер уяви векторний кеш:
— функція оброблює батчі поелементно
— треба знайти які ключі є у кешу, а всі інші обчислити
— ті шо обчислили — доплати в кеш, агрегувати і повернути результат батчу

Це вже десь 20 строк на ООП, і все ще одна строка із декоратором

@with_caching(ttl_days=1)
def expensive_computation(data: str) -> str:
   return compute(data)

VS

cache = Cache(ttl_days=1)

def expensive_computation(data: str) -> str:
  if (res := cache.get(data)) is not None:
    return data

  res = compute(data)
  cache.put(data, res)
  return res

Спробуйте wrapt — wrapt.readthedocs.io/en/master — «людький» інтерфейс для декораторів, який (на відміну від базового декорування) — веде себе очікувано в усіх edge cases (наприклад, не ламає рантайм тайп інференс після декорування)

Жпт каже що
1. Є Tier 0/1 оптимізації — JIT на початку генерує не дуже оптимальні інструкції, але якщо метод використовується «багато разів» то оптимізує агресивніше
2. JIT не полюбляє оптимізувати зовсім пусті цикли бо вважає, що ви (може) намагалися таким чином симулювати обчислення

Цікаво, що буде якщо додати count++ (каунт — просто локальна змінна) до вашого циклу? — щоб він не був зовсім пустим (в мене немає дот нет щоб перевірити, вибачте)

Ось приклад — devblogs.microsoft.com/...​ce-improvements-in-net-9

Ще можете погуглити доклади github.com/AndreyAkinshin — я 100% знаю було декілька на конференціях.

Там справді «потужна» бібліотека — вона, наприклад, виконує бенчмарк тести у ізольованих .NET процесах і щось там дуже спеціальне налаштовує щоб увімкнути усі можливі рантайм оптимізації. Якось так, вже не памʼятаю деталі

Якщо дійсно міряти то є ось бібліотека для цього: github.com/dotnet/BenchmarkDotNet

Навряд чи, поспілкуйтеся із ним на дуже досвідчену тему — квантову теорію і ви зрозумієте про що я

Ну отож

Я перефразую: жпт дуже гарно пропонує будь-яку «дурницю» яка не має ніякого співвідношення до реального миру. Щоб не робити «дурницю», тобі потрібно мати змогу казати «це якась дурниця яка немає відношення до реальних речей», але щоб це казати тобі треба розуміти що є «дурниця» а що ні

Чому це не так:
— не можна «швидко розібратися» у системі яку ти не розумієш, потрібно мати дуже багато навичок щоб мати змогу аргументировано казати що Х краще за Y. Якщо таких навичок немає — ти пливеш за течею не знаючи чи вона добра чи ні.
— питання існування професії взагалі не стоїть сьогодні (бо великошаневний АІ «не може»). Стоїть питання існування формошльопів.
— навіть коли АІ «зможе», він все одно буде потребувати інструкцій, а ми (люди) майже сто відсотково будемо ці інструкції генерувати (тут треба трошки перевчитися, авжеж).

Не таке, бо там далі висновки які не виходять ні із чого. На кшталт:

І важливіше не стільки те, що ти знаєш зараз, а те, наскільки швидко зможеш розібратися в новому. У висококонкурентне людське середовище втручається штучний інтелект і ставить під питання майбутнє професії, принаймні в попередньому її вигляді та обсязі.