А ещё смотрите че покажу

Наш нерегулярный герой Александр Ланцов будет выступать на JPoint в этом году. Тема доклада офигенная, я об неё много копий сломал и потратил много часов своей жизни -- memory модели без happens-before. Будет интересно послушать и посмотреть на примерах (потому что сам я до сих пор не потыкал и уже не буду). Если вы читали что-то из ранних ссылок этого канала (например, статьи про lock-free структуры данных на c++), то вам скорее всего интересно разобраться в release-acquire/release-consume и их друзьях.

А ещё есть приятный бонус в виде промика на скидку на билет 20%: ALantsov2023JRGpc

Хочу поделиться интересным видео

Уважаемый господин Баженов рассказывает про SVB, кризисы и российскую экономику.
За несколькими несущественными деталями, я согласен (и это всё согласуется с моими постами выше, но только разъяснено гораздо детальнее и проще). Единственное, что хотелось бы отметить: Григорий считает, что не будет кризиса, но ничего не говорит о рецессии 😉 А грань между понятиями иллюзорная, в определениях

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

https://nplus1.ru/news/2023/04/01/monocopter-drone-pulsar

Однажды очень давно, когда я был студентом магистратуры, пришел я на встречу по постановке целей в Дойче Банке. Не моих целей, а как вообще в компании цели ставятся. Дойче Банк — круто! Но интересно же, что там вообще в мире делают. Начитался я про OKR (не обсессивно-компульсивное расстройство, а objectives — key results) в гугле (в авито тогда еще не было, или они не рассказывали), чтобы понять, как мы будем делать круче. Подготовился к обучению, короче.
Пришел на эту встречу. Там че-то SMART-SMART-SMART-SMART-SMART (ни слова про целеполагание). Ну я возьми да и спроси: "а нам вот надо цели ставить амбициозные, ну типа, чтобы если на 70% сделал, то круто?". А на меня HR посмотрела огромными глазами, как на идиота и говорит: "зачем?" с интонацией: "ты что, совсем дебил?". В общем я че-то там промямлил про: "ну гугл так делает, там типа мотивация, амбициозные цели, не бояться рисковать...", а меня просто проигнорировали.

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

Я, кстати, стажёров ищу. Двух. Программировать на С++ и читать питон3. Или программировать на golang. Или программировать на python3 и C++, но _очень_ аккуратно. Пишите в личку @usyrname

Очень много постов про AI alignment

Буквально из каждого утюга
И есть опасения, что ИИ притворится тупым, или что мы не умеем понять, когда он стал умным.

Полная брехня!
Как только робот сможет надёжно отличить осину от берёзы по фотографии, можно утверждать, что его интеллект превзошёл человеческий!

Про LLM

Машинное обучение меня заинтересовало, когда я ещё учился в ШАДе. Но в меня не влезло пройти там ещё и поток ДС. Я тогда работал в Дойче, подружился с другим грудатом, который закончил РЭШ. И вот он мне рассказывал про эконометрику, а я ему лечил про МЛ (что успевал схватить у Червоненкинса в книжке). И я ещё никак не мог понять разницу. Вообще понял её уже сильно позже.
Потом в какой-то момент начитался, что Ренессанс активно хайрил (и на тот момент продолжал) специалистов в области NLP. Мне показалось, что там собака и зарыта. Ну типа это не таймсириес, но ведь по сути тоже последовательности и прогнозирование следующего элемента. Просто нужно на рыночные данные посмотреть не как обычно (когда нифига не работает вот это вот всякое там garch, фильтрации и т.п.), а как смотрят чуваки из тусовки тех анализа (над ними ещё все "настоящие" кванты и трейдеры ржут).
Возможно, какие-то паттерны действительно можно прогнозировать (вы же не верите, что процесс цены реально абсолютно случайный?).
Я даже прошёл курс DMIA с Витей Кантором. А после него сходил попробовал какие-то азы NLP. Но у меня чет не особо получилось, а не очень-то и хотелось... Короче, я забил.

Так вот смотрю я на этот ваш chatGPT и думаю. А почему его никто ещё не натравил на рыночные данные? Он же не на один шаг вперёд прогнозирует, а сильно дальше, очень сильно.

Раз эта светлая мысль пришла в голову мне, то почти наверное кто-то всё-таки уже попробовал. Я знаю, что какие-то вещи в этой области делает Bloomberg, но на этом всё.
Признавайтесь, получается там что-то?))

В Белграде дождь, а у меня хорошее настроение

Поэтому задачка из 10-го класса.
С какой скоростью едет моё такси, если скорость капель дождя около 35 км/ч?

Вот че настроение хорошее было.
Кванты, всех с праздником! 😁

Сегодня отмечается Всемирный день квантов. В честь этого ученые из Российского квантового центра развенчали самые популярные мифы о своей профессии

Ненавижу, когда на загадки не публикую отгадки. Поэтому вот. У капли относительно стекла две компоненты скорости: вертикальная (задана в условии) и горизонтальная (скорость авто относительно капли). Отношение скоростей здесь это тангенс угла alpha. Угол alpha, под которым капли размазываются по стеклу, чуть меньше 45 градусов. Значит, скорость такси чуть выше скорости капель. На деле примерно 35-40 км/ч.
Эта задачка была у меня в (лучшей физмат) школе в Уфе, в 10-м классе. Там че-то про Мюнхгаузена было. Так что не расстраивайтесь, если не решили, это для молодых и дерзких. :)

Расскажу, что получилось на проекте в ЦМФ

Возможно вы ожидали здесь видео про аналог пепси-колы, но нет. Что-то у нас получилось. На основной сети тезоса ребята написали смарт-контракт, который умеет ставить и матчить ордера. Да, получилось, что всё делается прямо в контракте. Поддержали лимитники и маркетные ордера. Написали очень примитивный фронтенд к этому всему. И забили.
Сайдчейн так и не появился, энтузиазм у ребят поугас, программировать на rust не понадобилось.
Стоит отрефлексировать этот проект.
1. На мой взгляд, у нас получилась ситуация "у семи нянек дитя без глазу": два ПО (один из них я), оба в какой-то момент понадеялись на другого и продолбали где-то сроки, где-то решения.
2. У нас не было толком трекера проекта, минуток со встреч и даже запланированные встречи часто ехали. Поэтому, если выпал разок, то уже потерял много контекста (а команда у нас была сильно распределённой, кто-то выпадал регулярно).
3. Коммуникация была в личках, а не в трекере или общем чате, поэтому сложно даже отследить, кто что сделал, почему пришли к такому решению, кто принял решение и т.д.
4. Использование хороших практик на работе, за деньги, в окружении привычных, удобных, всем знакомых инструментов не гарантирует, что вы будете применять эти же практики в условиях маленького учебного хаоса.

В общем, получилось скорее вопреки, а не благодаря, но, не сколько мне известно, это вообще единственный проект в этом потоке web3, который показал хоть какое-то готовое решение. Но это не точно 😁.

Оставлю тут рецензию на доклад Саши Ланцова на Jpoint'е

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

Тема достаточно сложная, въехать в неё непросто, особенно, если кристального понимания даже стандартной JMM в голове нет. Я ждал, что будет какой-то ассемблер, протоколы когерентности, топологии процессоров или по крайней мере барьеры памяти! В крайнем случае, думал я, можно как-то отвертеться абстрактными математическими serializability vs linearizability. Но нет! Вообще никакой дичи! Вся тема доклада раскрыта без использования сложноты.
Да, пожалуй, понимания "почему" не появится, но в инженерной профессии по-существу нужно только "как" (почему это в факультативном порядке). И вот в этом месте доклад не только дает хорошую интуицию, но и валит примерами, как из рога изобилия. Есть даже отдельный репозиторий на гитхабе, код из которого автор любезно погонял на x86 и ARM (ради такого дела даже купил Raspberry Pi).

Если вам хочется подглядеть, что там в конкаренси за пределом volatile, то must watch. Не только сможете наконец прочитать исходники дисраптора, но и гораздо лучше поймете, какие гарантии вы имеете, используя ставший уже классическим happens-before.

А я под впечатлением грузану немножко программерской духоты в этот канал. Держитесь.

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

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

Короче, почитайте, умные вещи дедушка говорил.

Платон, кстати, жёстко издевается надо мной. Здесь речь про то место, которое я так толком и не понял.

serializability vs linearizability

Начнём с изянства. Есть такие математические понятия, с которыми вы могли познакомиться в книжке The Art of Multiprocessor Programming.

Что это такое?
Если программа обладает любым из этих свойств, то гарантируется, что _любой_ _результат_ выполнения программы можно объяснить _последовательным_ исполнением инструкций программы.
Пример.
Вот в java есть такие типы, как long и double, для которых на 32-разрядных версиях спецификацией не гарантируется атомарность записи. То есть у вас поток А писал число 2*10^10, а поток B писал число 20 в одну и ту же переменную условно одновременно. Может получиться, что в переменной по итогу окажется число 0. Ни поток А, ни поток B это число туда не писали. Значит, объяснить такое поведение программы последовательным исполнением команд нельзя. У такой программы нет ни serializability, ни linearizability.

В чем тогда разница?
serializable гарантирует только наличие _какого-то_ порядка последовательного исполнения инструкций (возможно, разного для разных наблюдателей), а linearizable — _одинакового_ для всех акторов.
Пример.
Знаменитый IRIW (independent reads of independent writes). Смотрите на прикрепленную картинку. Два потока пишут в две разные независимые переменные, а два других читают из этих переменных по очереди. В случае с serilalizability _может_ так получиться, что и первый поток прочитает (x=1, y=0), и второй (y=1, x=0), т.е. не существует какого-то одного глобального порядка исполнения инструкций, которым можно было бы объяснить такой исход. В случае с linearizability такое невозможно.
*Картинка нагло украдена у господина Шипилёва.

Теперь посмотрите на семантики, о которых рассказывал Саша, и попробуйте понять, какие семантики дают гарантии serializability и linearozability.

Про зарплатные вилки

Очень тяжёлая штука, указывать зарплатную вилку. Если, конечно, бюджетом управляешь ты, а не кто-то тебе сверху спустил стандарты. С одной стороны есть вот эта тема с утечкой информации, якобы компания больше знает об уровне зарплат (смотрит много кандидатов), а соискатель якобы не знает. И получается, что ассиметрия информации, надо выбивать вилку и вот это всё. Надо. Несомненно надо.
С другой стороны, когда указываешь вилку типа 250-400к в месяц, то любой, вообще каждый кандидат будет просить 400к. И будет уверен, что он достоин, как минимум, не меньше.
На выходе иногда получается, что компания либо просто отказывает кандидату, потому что могла бы предложить 300, а он просит 400 — больше разница. Либо предлагает кандидату 300, и тот в некоторых случаях принимает, а в некоторых уже всё, раз в вилке прочитал 400, будет искать эту зарплату на рынке, пока не переберёт все компании мира.
Такова человеческая натура, я тоже всегда только на верхнюю границу смотрю.

Вопрос праздный, у меня этой проблемы нет (пока?). Но как вы думаете, нужно выбирать вилку для указания в вакансии?

Про лоу перформеров

У нас на работе несколько месяцев как появились разные мероприятия для руководителей, где можно обсудить острые темы и обменяться опытом. В том числе анонимно. Насколько раз за последнее время всплывала тема "плохо работает, обратная связь не помогает, мотивация не помогает; ну или альтернативно: помогает волнами". Это ситуация, которая была у меня, к сожалению, уже несколько раз.
Давайте я обозначу здесь сразу какие-то очевидные вещи.
- Самая важная очевидная вещь. Нужно говорить с людьми. Если им не сказать, что они делают что-то плохо/медленно/не то, то они об этом не узнают.
- Вторая важная очевидная вещь. Разговаривать нужно конкретно по поступкам. Не "ты чет плохо работаешь", а "ты делаешь задачу Х уже на неделю дольше и всё ещё не готово". Не по персоналии.
- Третья очень важная очевидная вещь, которую часто забывают. Сначала узнать у сотрудника, как он видит ситуацию. Только потом рассказать, как видишь ты и _предложить_ помощь_.
- Четвёртая очевидная важная вещь, которую тоже забывают. После того, как обсудили план, че делать дальше, _убедиться_, что вы поняли друг друга одинаково. Проще всего попросить объяснить своими словами, что человек понял и что собирается делать.
- Пятая, не столь очевидная вещь. Нужно знать, что мотивирует конкретного сотрудника и пытаться это ему дать.

Все эти очевидные вещи в нормальном формате можно узнать в практикуме.

Теперь предположим, что вы всё делали, как написано в учебнике. Несколько раз. Но ТРЕНЕР, БЛОКИ НЕ РАБОТАЮТ. Тогда надо перестать жевать сопли и говорить с сотрудником о расставании. Все попытки дать ещё и ещё и ещё один шанс, какие-то там пряники и кнуты, возможно, будут помогать на _очень_ короткие промежутки времени. Но, во-первых, это издевательство над психикой сотрудника, постоянный стресс, отсутствие уверенности в завтрашнем дне. Во-вторых, это ужасающая куча геморроя, на который времени тратить придётся много, а эффекта будет мало.

Про "бывают уникальные ситуации" мы должны были выяснить в первой половине поста. Если вам приходит в голову мысль, "а если у его собачки запор" и т.п., то, ещё раз, в первой половине поста написано, что это нужно выяснить. На регулярных вот этих самых встречах.

Дочитал диалог "Протагор"

И преисполнился. Во-первых, это очень понятный диалог. Во-вторых, сложно не согласиться с его выводами. Почувствовал себя намного мудрее теперь.

Интересные наблюдения:
- если "апология Сократа" дала понимание, почему греческие философы зачастую прибегали к аскезе вообще; то "Протагор" подтверждает, что аскеза — это общепринятое в греческом обществе благо. Это сразу расширяет границы понимания университетского курса философии (не аспирантского, конечно), где куча аскетов, потому аскеза это круто 🤡
- греки практиковали голодание, как оздоровительную процедуру 🤔
- теперь полностью ясна концепция, что всё зло от незнания; что человек по природе своей не может осознанно деять зло. Я, кстати, с этим полностью согласен, от этой основы строится моя картина мира. Но из-за этого со мной редко кто согласен в дискуссиях на общественно-политические темы.
Именно из-за этого представления Платон потом говорит, что идеальные правители — это философы, т.е. люди, посвящяющие жизнь приобретению знаний.
- САМОЕ ГЛАВНОЕ ДЛЯ МЕНЯ. Даже мудрейший Протагор нем умеет читать, чито написано! Я очень сильно бешусь, когда люди читают не то, что написано, а то, что они хотят прочитать. Додумывают в контексте собственных мыслей, знаний и представлений, не задумываясь о таковых автора.
Это, кстати, проблема именно письменной речи, почему-то. Надо бы обдумать, почему так.
Справедливости ради, Протагор не смог прочитать довольно сложный кейс (в отличие от большинства людей в интернете), но сути дела это не меняет — читать, что написано, не умеет почти никто (я тоже), но у всех неумение на разных уровнях.

Суть ошибки Протагора следующая. Он рассматривает стих Симонида.

Трудно по истине стать человеком хорошим.
Руки, и ноги, и ум, чтобы стройными были,
Весь же он не имел никакого изъяна.

Там же, ниже по тексту, Симонид критикует Питтака:

Вовсе не ладным сдаётся мне слово Питтака,
Хоть его рёк и мудрец: добрым быть нелегко.

Простите, но думаю, что многие, как и Протагор, увидят здесь противоречие. Сам Симонид сначала говорит, что сложно стать хорошим, а потом критикует Питтака за слова, что трудно брать хорошим. Но противоречия здесь нет. TL;DR Симонид утверждает, что даже стать хорошим (будучи плохим) сложно, а уж быть хорошим (всё время) вообще невозможно. И Симонид считает, что не стоит осуждать неидеальных людей, потому что иначе придётся осуждать всех.

Здесь нужно быть в контексте того, что лаконцы (спартанцы), из коих Питтак, видят и чтут тончайшие смыслы в словах. И когда они пишут два разных слова, то вероятно, вкладывают в них два разных смысла. Так же нужно знать, что Симонид честолюбиво стремился к тому, чтобы превзойти мудрого лаконца Питтака. Отсюда и этот стих.

Какой вывод я делаю?
Нужно быть терпимее к тем, кто не умеет читать, что написано. Если уж даже мудрейшие не способны, то чего ждать от остальных. Буду стараться смиренно переносить эту боль впредь.

Про memory barriers

Опять не про психологию, а эти мои любимые компьютеры. Контент в кои-то веки c++ tolerant!

Сегодня снова про разницу между sequential consistency и release/acquire. Если забыли, в чем там прикол, то перечитайте презентацию с гитхаба Саши или статью Дага Ли. Многие продвинутые джависты, я уверен, читали jsr 133 cookbook. Там написано, как _можно_было_бы_ реализовать volatile записи и чтения (это sequential consistency) на разных архитектурах процессоров.

В этой статье есть несколько интересных моментов. Давайте их посмотрим поближе.
Первое. Рассматриваются барьеры между парами операций чтения и записи (load/load — между двумя чтениями, store/load — между чтением и записью, load/store и store/store). Это представление достаточно удобно для рассуждений (reasoning), но является абстракцией.
Второе. У x86 есть только одна инструкция-барьер — mfence, у power pc две: [lw]sync и hwsync; и вообще больше двух инструкций ни у кого нет. А абстрактных барьера — четыре. Наплодили тут!
Третье. Для x86 вообще почти все барьеры — noop. И только store/load требует барьера. Но! Мы видели у Саши Ланцова на графиках, что release/acquire быстрее sequentially consistent исполнения на x86. Как так? Всё просто: абстрактная модель с четырьмя такими барьерами не позволяет описать release/acquire! (Можете даже в исходники jdk заглянуть, они там отдельные)

В своё время (очень очень много лет назад) я увидел iriw и никак не мог понять, как с помощью этих барьеров его описать. Это меня очень мучало, я во сне даже это видел. Пришёл на JPoint. Пытался спросить г-на Шипилёва, но его всё время перехватывали, поэтому он меня отфутболил к г-ну Елизарову, который просто цензурно, но грубо послал меня на хер, с посылом, что дебилам это не нужно, отвали и забей, мальчик. ¯\_(ツ)_/¯
Но мальчики не сдаются. Я поймал г-на Шипилёва где-то во время какого-то доклада и он показал мне это. И это офигенно, почитайте на досуге.

Теперь давайте посмотрим, как устроены внутри setRelease и getAcquire, да и в целом все инструкции с барьерами внутри. Важный для понимания факт: при записи барьер выставляется ПЕРЕД самой записью, а при чтении — ПОСЛЕ самого чтения. Это может быть контринтуитивно. Но если подумать от гарантиях, то всё встанет на свои места. Смысл примерно такой:

Если мы увидели конкретную запись, то увидим и все предыдущие
Если мы прочитали какое-то значение, то его же должны видеть все последующие

Это неаккуратно, но передаёт мой посыл — куда думать.

Ну так вот. Для release/acquire на ppc нужны lwsync и до записи и после чтения. Для sequentially consistent нужна более тяжёлая артиллерия: [hw]sync на чтении. Для x86, как мы видели в cookbook'е, для sc нужен только mfence после чтения. А вот для release/acquire вообще ничего не нужно ни на чтении, ни на записи! Мы специально проверили, что opaque на x86 дает ту же корректность и ту же производительность, что и release/acquire. Напомню, что opaque ставит только компиляторные барьеры (не дает оптимизировать через компиляторный барьер). А всё благодаря TSO (total store order).
Интересный факт: явная инстркция барьера на x86 работает (работала?) медленнее, чем дающая те же гарантии атомарная инструкция lock addl, поэтому в jdk используется (использовалась?) именно последняя.

Я уже не знаю, зачем существует этот пост, но не могу остановиться.
КОРОЧЕ. В С/С++11 есть еще семантика release/consume... Она еще чуть слабее release/acquire и нужна вот зачем. Вы можете прочитать с consume записанную с release переменную-указатель и вам гарантируется, что по этому указателю вы увидите данные записанные до release записи. Т.е. зависимость по данным порождает видимость. НО! Эта штука была нужна, на сколько я знаю, только на альфах, которые канули в лету. Так что забейте.

Have a nice day, как говорится.

И, пожалуйста, не пишите на основе этой статьи компиляторы! Я не выверял формулировки, мог быть не точен, а мог и вовсе ошибиться.

Ну чёт даже не знаю