300

Тем временем эти скромные измышления читают уже более 300 человек. Спасибо!

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

@engineer10x

Синхронизация потоков

При обсуждении многопоточности в первую очередь говорят про синхронизацию доступа к общей памяти из разных потоков через mutex или аналогичный синхронизационный примитив. Однако одновременный доступ из нескольких потоков к одному и тому же участку памяти не так уж прост. Как учит нас MIT, у него немало подводных камней и редко проявляющихся багов, его сложно организовать и тестировать, как правило он плохо влияет на дизайн, и так далее.

Другой способ, лишённый этих недостатков, это общение потоков через сообщения. В таком случае потоки общаются друг с другом явно через очереди (вместо неявного общения через изменение общих данных). Использование явной зависимости выпрямляет дизайн, делает код тестируемым и по-сути однопоточным. (Кстати, реализовать эти очереди можно и на мьютексах с условными переменными, главное, чтобы они не вытарчивали наружу).

При этом явными очередями можно не только улучшить дизайн, но и скорость, если реализовать их на неблокируемых инструкциях процессора вместо мьютексов. Классический пример такой реализации - это LMAX disruptor.

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

При таком подходе нет столпотворения читателей, пытающихся взять mutex или rwlock, им не нужно уходить спать в ядро, ожидая его освобождения, а latency может приближаться к пределу, ограниченному только скоростью синхронизации кешей между ядрами, особенно если удастся упаковать свои данные в L1 cache, как рекомендовалось выше.

@engineer10x

О подходах к работе и бизнес-моделях в торговле

Хозяин одной из успешных крупных американских торговых фирм создаёт и нагружает команды так, чтобы у них было значительно больше работы, чем ресурсов, а также чтобы ответственность пересекались с другими командами (для развития беспощадной конкуренции).

Для каждой создаваемой бизнес-единицы с самого начала вычисляется стоимость её мгновенного закрытия (например, досрочный разрыв контракта на офис, выплаты выходного пособия всем сотрудникам при увольнении и т. д.). Эта цифра постоянно ревностно обновляется, а хозяин всё время сравнивает её с доходами от подразделения.

Выжившие зарабатывают очень хорошо, но риск того, что могут разогнать, всегда присутствует на фоне и атмосфера бывает так себе.

@engineer10x

ChatGPT для работы

Сначала, в незапамятные времена, к библиотекам прикладывали мегабайты документации по каждому классу/функции. Чтобы понять как с помощью этой библиотеки решить конкретную задачу нужно было изучить много отдельных функций и приобрести кругозор, чтобы знать где искать (либо спросить у старших товарищей, у которых тоже был встроенный rate limiter). Либо могло повезти и документация содержала хорошие примеры типа "как построить такое-то приложение", но обычно примеров было меньше процентов пяти.

Потом развился поиск, документацию стало можно найти в интернете, но принцип её организации особо не поменялся.

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

Теперь, когда появились LLM, можно попросить ChatGPT (или его конкурента) прямо написать затравку какой-то программы, включая обвязку и boilerplate для тестов, на ходу меняя используемые библиотеки.

Кроме этого, ChatGPT разбирал для меня сообщения из разных протоколрв и описывал их составные части. Или реализовывал стандартную агрегатную функцию из базы данных на С++. Однако мне кажется, что я не использую его и на 5% возможностей. Поделитесь как LLM помогает вам увеличивать свою эффективность в программировании и вообще?

@engineer10x

Как выбрать язык программирования?

Как оценивают какой-то язык когда на нём пишут? Например, "мои программы летают со скоростью света!" или "тяп-ляп и в production за 5 минут!" или "библиотеки всего мира на все случаи жизни под рукой".

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

По каким критериям вы бы выбирали язык(и) программирования для своего проекта?

А для своей фирмы? Особенно если вы вкладываете в неё все накопленные за свою жизнь сбережения...

@engineer10x

Павел Дуров

Очень интересное и насыщенное интервью. Возможно что всё это широко известно, но для меня многое было новым.

- Телеграм пишет и обслуживает ~30 человек 10х инженеров.- Для их найма в компании 0 HR - люди выбираются по результатам соревнований на https://contest.com/

- Компания была и остаётся lean, что делает её похожей на торговые фирмы, торгующие своим капиталом. Причём не только в инженерном смысле, но и в ~~бес~~полезной регуляторной нагрузке. Но при этом мотивирована не деньгами, как торговцы, а идеалами свободы и беспристрастности, если верить Павлу ;)

- Например, компания не планирует размещаться на бирже - единственный сосредоточенный хозяин позволяет всем участникам кооператива сохранять независимость и концентрироваться на деле вместо ерунды. К тому же, по словам Павла, прежний Твиттер не мог поувольнять -10х инженеров из-за возможного волнения инвесторов ("массовые сокращения == в компании что-то не так").

- (Интересно, что, насколько мне известно, Маск увольнял людей из Твиттера так: всех сотрудников спросили кто в их команде самый лучший. Этих лучших оставили, остальных уволили. Опять-таки, чтобы это сделать, ему пришлось сделать компанию частной и убрать её с биржи).

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

- Для сравнения, приехав в Германию с уже готовой командой, Павел встретился с визовой/трудовой бюрократией (сначала нужно пробовать нанять местных и только если не получится через полгода - можно нанимать своих).

- А в США слишком много внимания со стороны спецслужб (да и пришлось отбивать свой телефон от гопников на улице в Сан-Франциско).

- Лондон и Сингапур тоже почему-то не подошли.

@engineer10x

Telegram

Du Rove's Channel

***🐥******🐥*** The full version of my interview with Tucker is out https://www.youtube.com/watch?v=1Ut6RouSs0w ***🎙***

Виталий Шароватов задаётся вопросом кто же такой этот мистический 10x engineer.

https://t.me/vsharovatov/492

В твиттере предлагаются такие примеры. Вам встречались такие? Или, быть может, ещё более впечатляющие?

Ещё про эффективность (и дофамин)

Торговля стала первой отраслью в моей программистской карьере где оказалось возможно хлебать дофамин литрами ~~без того, чтобы от скуки уходить за ним в соцсети~~. Очень впечатляет когда для решения внезапно появившейся серьёзной проблемы специалисты из разных команд и ролей мгновенно собираются в ad hoc team, бросая всю более медленную проектную работу которой занимались до этого, и интенсивно решают проблему "здесь и сейчас", не расслабляясь от начала и до конца.

Все имена и события в истории вымышлены, любые совпадения с реальными людьми, живыми или мертвыми, случайны.

Однажды команда, отвечавшая за наблюдения за успешностью быстрых торговых роботов, забила тревогу: с утра они перестали попадать по короткоживущим заявкам с рынка. Мгновенно из повседневной неспешной работы в разных командах выдернули несколько программистов (включая изначальных авторов), которые стали смотреть на трафик и сравнивать его с предыдущими днями в попытке понять, что же случилось.

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

Ребята отправились в переговорку, захватив старших трейдеров и ещё несколько человек с разными специализациями, где объяснили проблему и предложили несколько решений. Минут за 30 интенсивного обсуждения договорились о том, как чинить, получили добро от юристов, и пара программистов пошла править код. Через пару часов первая версия была готова, проверена на сохранённом трафике и начала пропихиваться по трубопроводам билд-системы в релиз, в то время как программисты дописывали тесты (поймавшие потом пару забытых в горячке пограничных случаев).

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

Видели ли вы похожую по насыщенности работу? Дополнительные баллы за примеры не из биржевой торговли.

@engineer10x