🙄🙄 Есть ли смысл в CPU-bound сoncurrency?

Мы все видели таких коллег 😎😎 — только что изучили горутины и сразу решили «распараллелить всё!» Особенно так любят делать новички:

«Оо, я недавно изучил пакет unsafe и concurrency, сейчас распараллелю вычисления в этом запросе и уберу лишние копии».

В лучшем случае код становится менее читаемым.
В худшем — станет медленнее 🫡🫡

Как однажды сказал Дональд Кнут — один из отцов информатики:

«Преждевременная оптимизация — корень всех зол»

Особенно наглядно это работает для CPU-bound задач — например, сложение матриц, хэширование, кодирование. Интуитивно кажется, что «больше горутин = быстрее», но это ловушка.

Закон Амдала отлично иллюстрирует, насколько сложно получить ускорение в этом случае. Например, при 60% параллельного кода разницы между 100 и 1000 ядрами практически нет 💔. В задаче из поста выше ответ по формуле 5.263.

С точки зрения практики, всегда лучше сделать бенчмарк. Как видим, ответ почти сошёлся.

BenchmarkAdd/par/w=1-12        168
BenchmarkAdd/par/w=10-12       776

При этом важно понимать, что с IO-bound задачами всё иначе — там другие принципы и прирост может быть на порядки выше.

Кстати, как раз сегодня на канале вышло видео про устройство атомиков и распараллеливание CPU-bound задач.

Если же хочется разобраться в этих принципах глубже, 25 ноября стартует 2 поток курса The Nature of Concurrency. Это системное погружение в базу многопоточности: от устройства атомиков, мьютексов до модели памяти, устройства race detector'a и lock-free алгоритмов.

Курс закрывает 100% вопросов про Concurrency на собеседованиях, видеоотзывы можно посмотреть на сайте. В честь распродажи 11.11 до конца недели действует скидка на PREMIUM тариф, на нём есть возможность поработать со мной 1 на 1, осталось всего 2 места.

🍀 Время это иллюзия?

🙄🙄 Что же такое время? Мы часто оперируем этим понятием в наших приложениях, но откуда вообще наш компьютер знает точное время?

Всё началось ещё давно, когда морякам необходимо было знать точное время, чтобы определить точное местоположение корабля в океане. Это связано с принципом долготы — одной из двух координат на Земле. В 1731 году изобрели хронометр, который надолго стал золотым стандартом на море. В современном мире используют спутниковые системы (GPS).

Но как же наши компьютеры понимают, сколько сейчас время? В каждом компьютере есть маленький чип — Real-Time Clock (RTC). Он работает даже тогда, когда устройство выключено. Но есть проблема в том, что RTC не очень точный, за минуту дрейф может составлять миллисекунды, а за дни и недели — уже секунды и больше.

Для решения этой проблемы был придуман Network Time Protocol (NTP). Операционная система почти всегда периодически синхронизирует время через интернет. Но откуда те, с кем мы синхронизируемся, знают точное время, как они его считают?

Существует международное атомное время (TAI - International Atomic Time). Оно равняется средневзвешенному времени цезиевых часов из разных лабораторий, с поправками на локальную разницу гравитации. Через GPS атомные часы калибруются по отдельности через положение GPS-спутников. Сами атомные часы завязаны на факт, что одна секунда равна времени, за которое атом цезия-133 совершает 9_192_631_770 переходов между энергетическими состояниями, там всё неочевидно, оставим эти вопросы физикам)

Но где же здесь всем знакомый UTC (Coordinated Universal Time)? На самом деле UTC — это шкала, которая идёт почти как TAI, но периодически в неё вставляют високосные секунды, чтобы не убегать от астрономического времени. Поскольку Земля со временем вращается медленнее, «солнечные сутки» постепенно расходятся с атомным временем. Поэтому международная служба времени (каких служб только не придумают) вставляет лишнюю секунду, чтобы синхронизировать шкалы. Таким образом, можно было увидеть время:

23:59:60 <- вставленная секунда 😎😎

Так делали 27 раз, начиная с 1972 года. Високосная секунда кажется мелочью — всего одна лишняя секунда. Но на практике 30 июня 2012 года она вызвала крупные сбои по всему миру: в интернете, авиакомпаниях, дата-центрах, базах данных, Linux-серверах и даже в платежных системах. В частности, в ядре Linux был баг в обработке таймеров, и при вставке секунды некоторые таймеры начинали бесконечно перезапускаться, загружая CPU на 100%.

Эта секунда так всех достала, что в ноябре 2022 года на 27-й Генеральной конференции по мерам и весам было принято решение отказаться от дополнительных секунд к 2035 году или ранее))

Но как всё-таки получать точное время? Ведь даже при использовании NTP нет жёсткой гарантии на дрейф, ибо всё зависит от множества факторов (аппаратные часы, сеть, серверы) В нормальных условиях речь обычно идёт о миллисекундах, иногда десятках миллисекунд, но это всё равно слишком много, чтобы на это завязаться.

В рамках одного процесса ОС эту проблему решают монотонными часами. Например, в Go пакет time хранит такое время от операционной системы. В отличие от "реального" времени оно монотонно, то есть можно более безопасно реализовать различные таймеры.

Но что делать, если нам нужно точное время между разными компьютерами? Например, базам данных критично получать точное время для выбора меток при реализации распределённых транзакций с уровнем изоляции snapshot isolation (MVCC).

Эту проблему решают специальными чипами с атомными часами, например, Chip-Scale Atomic Clock (CSAC), который можно купить за +- 5.000$. Далее такую аппаратную поддержку используют в time server'ах, с помощью которых приложение может получить "интервал доверия" для текущего времени — диапазон, в котором оно почти наверняка находится. Сами серверы бывают разные (master, slave), соответственно, с разной точностью.

Подводя итоги, можно сказать одно. Прежде чем сильно завязаться на время в вашей системе, подумайте несколько раз, правда ли вы этого хотите 🖐️🖐️