Давайте новый тег заведём: #perf
Во-первых, надо понять, что я вообще понимаю под перфом, ведь понятие очень широкое. Так как мои интересы лежат в районе эффективности распределённых систем, то перф для меня — всё, что позволяет делать эти распределённые системы быстрыми. В зависимости от системы вам может понадобиться решать проблемы разного характера. Где-то это про сделать ручку для обработки данных батчами, чтобы по сети поменьше ходить. Где-то научиться нормально пользоваться БДшкой. Где-то надо почаще попадать в L1 кеш и префетчить данные. А где-то вообще выбросить всё что есть и сделать заново в другой парадигме. Вся широта проблем меня занимает. В разной мере в разное время.
На самом деле я бы расширил понятие перфа до слова эффективность. И разговаривал бы ещё про то, что такое эффективность команды или всех разработчиков на стеке Х. Что такое developer experience. Почему унификация помогает средне-большой компании экономить деньги и вот это всё. Тут конечно надо быть осторожным и не уйти в степь вида «дайте-ка я ещё померяю, кто у меня в команде больше коммитов делает и буду им оценочку на ревью повыше ставить». Я за здравое понимание «эффективности разработки», а не за вот это корпоративное обмазаться метриками и всем в нос им потом тыкать.
Но такие вещи я постараюсь в тег не заносить, чтобы не обманывать хардкорных си плюс плюс подписчиков.
Во-вторых, начать тег я хочу с концепции. Концепция хорошо показана в докладе с CppCon 2014: Data-Oriented Design and C++ от Mike Acton. Это даже тот самый классический доклад, который всем показывают по теме.
Я его смотрел когда-то пару лет назад. Смотрел не очень осознанно. А сейчас как-то естественным образом пришёл к понимаю подобного направления и случайно ещё наткнулся на доклад, который вроде про то самое.
Суть хорошо показана в первой части (где-то первые 30 минут, дальше начинаются примеры кода). Кратко её сформулировать можно так: данные это всё. Основная проблема: при решении задач мы часто оперируем ментальными моделями, которые хорошо выглядят с точки зрения нашего человеческого понимания объектов, трансформаций данных и решения проблемы «переложить объект слева направо». Но так как компуктеры работают не так, как мы думаем, необходимо взять себя в руки и подумать про то, как данные должны трансформироваться (фактически единственно важный вопрос при проектировании). И из этого ответа у вас вытекают все возможности решений.
Фактически весь перф это про data oriented design. Ведь вам не нужно ускорять то, что согласно данным не нужно ускорять. И нужно то, что нужно. Вам нужно знать, как ваши данные выглядят, какие там взаимосвязи. Как они используются. Желательно знать как можно больше. Вы хотите решать задачу для наиболее common случая, потому что это статистически принесёт больше пользы.
Короче знайте свои данные.
Есть ещё доклад Vittorio Romeo «More Speed & Simplicity: Practical Data-Oriented Design in C++». Несмотря на какой-то околоискуственный пример, тут неплохо показана попытка сдвига мышления от привычной OOP парадигмы в сторону DOD.
Особенно, пусть это и не относится особенно к делу, красиво задвинул в конце про адекватный интерфейс для SoA.
У меня вот прям после некоторого количества информации по этой теме какой-то сдвиг в голове случился, и некоторые вещи обрели новый, более устойчивый смысл, а некоторые его радикально потеряли. Будем наблюдать, какие плоды это в итоге принесёт.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
На правах мегапатрона послание подписчикам от Artyom Garkavy:
Во-первых, надо понять, что я вообще понимаю под перфом, ведь понятие очень широкое. Так как мои интересы лежат в районе эффективности распределённых систем, то перф для меня — всё, что позволяет делать эти распределённые системы быстрыми. В зависимости от системы вам может понадобиться решать проблемы разного характера. Где-то это про сделать ручку для обработки данных батчами, чтобы по сети поменьше ходить. Где-то научиться нормально пользоваться БДшкой. Где-то надо почаще попадать в L1 кеш и префетчить данные. А где-то вообще выбросить всё что есть и сделать заново в другой парадигме. Вся широта проблем меня занимает. В разной мере в разное время.
На самом деле я бы расширил понятие перфа до слова эффективность. И разговаривал бы ещё про то, что такое эффективность команды или всех разработчиков на стеке Х. Что такое developer experience. Почему унификация помогает средне-большой компании экономить деньги и вот это всё. Тут конечно надо быть осторожным и не уйти в степь вида «дайте-ка я ещё померяю, кто у меня в команде больше коммитов делает и буду им оценочку на ревью повыше ставить». Я за здравое понимание «эффективности разработки», а не за вот это корпоративное обмазаться метриками и всем в нос им потом тыкать.
Но такие вещи я постараюсь в тег не заносить, чтобы не обманывать хардкорных си плюс плюс подписчиков.
Во-вторых, начать тег я хочу с концепции. Концепция хорошо показана в докладе с CppCon 2014: Data-Oriented Design and C++ от Mike Acton. Это даже тот самый классический доклад, который всем показывают по теме.
Я его смотрел когда-то пару лет назад. Смотрел не очень осознанно. А сейчас как-то естественным образом пришёл к понимаю подобного направления и случайно ещё наткнулся на доклад, который вроде про то самое.
Суть хорошо показана в первой части (где-то первые 30 минут, дальше начинаются примеры кода). Кратко её сформулировать можно так: данные это всё. Основная проблема: при решении задач мы часто оперируем ментальными моделями, которые хорошо выглядят с точки зрения нашего человеческого понимания объектов, трансформаций данных и решения проблемы «переложить объект слева направо». Но так как компуктеры работают не так, как мы думаем, необходимо взять себя в руки и подумать про то, как данные должны трансформироваться (фактически единственно важный вопрос при проектировании). И из этого ответа у вас вытекают все возможности решений.
Фактически весь перф это про data oriented design. Ведь вам не нужно ускорять то, что согласно данным не нужно ускорять. И нужно то, что нужно. Вам нужно знать, как ваши данные выглядят, какие там взаимосвязи. Как они используются. Желательно знать как можно больше. Вы хотите решать задачу для наиболее common случая, потому что это статистически принесёт больше пользы.
Короче знайте свои данные.
Есть ещё доклад Vittorio Romeo «More Speed & Simplicity: Practical Data-Oriented Design in C++». Несмотря на какой-то околоискуственный пример, тут неплохо показана попытка сдвига мышления от привычной OOP парадигмы в сторону DOD.
Особенно, пусть это и не относится особенно к делу, красиво задвинул в конце про адекватный интерфейс для SoA.
У меня вот прям после некоторого количества информации по этой теме какой-то сдвиг в голове случился, и некоторые вещи обрели новый, более устойчивый смысл, а некоторые его радикально потеряли. Будем наблюдать, какие плоды это в итоге принесёт.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
На правах мегапатрона послание подписчикам от Artyom Garkavy:
Try it today: google.com.
👍18❤2
#perf
Попробовал собрать в кучку (кажется, немного сумбурно всё же) мысли по двум моментам:
• что искать в данных и как их собирать, чтобы на них можно было быть oriented
• чуть более разнообразные, чем обычно, примеры применения DOD.
https://thisnotes.dev/blog/dod_examples/
Да, на инглише, теперь иногда будет так.
Ещё можете подписаться на newsletter: https://thisnotes.substack.com/subscribe
Может вам на почту удобнее получать.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
Попробовал собрать в кучку (кажется, немного сумбурно всё же) мысли по двум моментам:
• что искать в данных и как их собирать, чтобы на них можно было быть oriented
• чуть более разнообразные, чем обычно, примеры применения DOD.
https://thisnotes.dev/blog/dod_examples/
Да, на инглише, теперь иногда будет так.
Ещё можете подписаться на newsletter: https://thisnotes.substack.com/subscribe
Может вам на почту удобнее получать.
@thisnotes. Patreon.
Спасибо Artyom Garkavy и niki4smirn.
thisnotes.dev
Data-Oriented Design in practice
Examples of how we could use data oriented design in real life.
🔥8👍4❤3
#perf
Осознанно не пишу ничего про ИИ, но не удержался.
Есть такой хорошо известный в среднего размера (а может даже и в широких) кругах чувак — Антон Самохвалов. Я несколько раз его периодами читал, но так как мои интересы не очень матчились с его контентом, я переставал. Недавно узнал про концепцию, которой я очень хочу с вами поделиться. Про неё ниже. В целом сейчас, я кажется, в каком-то смысле до контента Антона «дорос», так что в этот раз планирую на канале задержаться.
Про концепцию поверх постов Антона мне рассказал близкий друг. А я во время полёта домой casually перечитал канал Антона с начала лета, вдохновился ещё больше и заодно нашёл несколько примеров, чтобы вам было понятнее.
Поинт такой: раз сегодня с засилием LLM код становится дешёвым, появляется смысл делать (или даже нет смысла НЕ делать) некоторые оптимизации (да и проекты в целом), за которые раньше ни за что бы никто не сел.
Более того, generic решения уходят в прошлое, потому что имея систему, вы можете три доллара понять, что нужно ВАМ в конкретном случае и наклодить частное решение под ваш конкретный юзкейс. Перф даётся проще, если вы знаете, где его искать.
Примеры:
• посмотрел на конкретный паттерн использования памяти и написал аллокатор ровно под него: https://t.iss.one/itpgchannel/4165
• perfect hash с доработками для фиксированного набора расширений файлов: https://t.iss.one/itpgchannel/4184
• огромная стейт машина, которую наклоденерил за 7 часов: https://t.iss.one/itpgchannel/4313
• научился писать данные максимально эффективно на своё конкретное железо в своём конкретном S3: https://t.iss.one/itpgchannel/4484
• тут Антон и сам бы справился, но сэкономил себе нормально так ресурса: https://t.iss.one/itpgchannel/4242
Тут общая концепция словами автора: https://t.iss.one/itpgchannel/4344
и продолжение: https://t.iss.one/itpgchannel/4379
Думаю, вы ощутили, что имелось в виду выше.
Я в последнее время иногда занимаюсь большим проектиком (когда-нибудь вам покажу). И там постоянно натыкаюсь на шероховатости стандартной библиотеки (в которой я вижу general решения, пытающиеся угодить всем). Я постоянно возвращался к мысли, что для перфа частные решения, даже для таких общих вещей, неимоверно важны. А тут оно как-то сматчилось с идеей со стороны и нашло продолжение в связи с ИИ.
Причём у меня после осознания подхода ещё и направление мысли сменилось. Я в целом вообще теперь не вижу смысла особо писать код руками, хотя ещё неделю назад был уверен, что навык это важный (ну он и всё ещё важный, так или иначе. Я бы опустил рандомного сеньора, который почему-то разучился этим заниматься. Но, кажется, на хорошем наборе примеров я понял всех важных дядек из всех больших компаний).
Человек трудящийся уходит в прошлое. В дело вступает человек думающий. У разработчика без глубокой картины происходящего, с узким кругозором, и агент будет использоваться кустарно, чтобы подпереть да подкрутить. Если вы найдёте способы и силы развиваться качественно в текущих условиях, вы не то чтобы станете легитимными 10х, но и всеми 228х разработчиками.
Качайтесь и читайте Антона: @itpgchannel.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
Хотите advent about bad parts стандартной библиотеки в декабре? Если хотите, тыкайте 🌚. Если нет: 🗿.
Осознанно не пишу ничего про ИИ, но не удержался.
Есть такой хорошо известный в среднего размера (а может даже и в широких) кругах чувак — Антон Самохвалов. Я несколько раз его периодами читал, но так как мои интересы не очень матчились с его контентом, я переставал. Недавно узнал про концепцию, которой я очень хочу с вами поделиться. Про неё ниже. В целом сейчас, я кажется, в каком-то смысле до контента Антона «дорос», так что в этот раз планирую на канале задержаться.
Про концепцию поверх постов Антона мне рассказал близкий друг. А я во время полёта домой casually перечитал канал Антона с начала лета, вдохновился ещё больше и заодно нашёл несколько примеров, чтобы вам было понятнее.
Поинт такой: раз сегодня с засилием LLM код становится дешёвым, появляется смысл делать (или даже нет смысла НЕ делать) некоторые оптимизации (да и проекты в целом), за которые раньше ни за что бы никто не сел.
Более того, generic решения уходят в прошлое, потому что имея систему, вы можете три доллара понять, что нужно ВАМ в конкретном случае и наклодить частное решение под ваш конкретный юзкейс. Перф даётся проще, если вы знаете, где его искать.
Примеры:
• посмотрел на конкретный паттерн использования памяти и написал аллокатор ровно под него: https://t.iss.one/itpgchannel/4165
• perfect hash с доработками для фиксированного набора расширений файлов: https://t.iss.one/itpgchannel/4184
• огромная стейт машина, которую наклоденерил за 7 часов: https://t.iss.one/itpgchannel/4313
• научился писать данные максимально эффективно на своё конкретное железо в своём конкретном S3: https://t.iss.one/itpgchannel/4484
• тут Антон и сам бы справился, но сэкономил себе нормально так ресурса: https://t.iss.one/itpgchannel/4242
Тут общая концепция словами автора: https://t.iss.one/itpgchannel/4344
и продолжение: https://t.iss.one/itpgchannel/4379
Думаю, вы ощутили, что имелось в виду выше.
Я в последнее время иногда занимаюсь большим проектиком (когда-нибудь вам покажу). И там постоянно натыкаюсь на шероховатости стандартной библиотеки (в которой я вижу general решения, пытающиеся угодить всем). Я постоянно возвращался к мысли, что для перфа частные решения, даже для таких общих вещей, неимоверно важны. А тут оно как-то сматчилось с идеей со стороны и нашло продолжение в связи с ИИ.
Причём у меня после осознания подхода ещё и направление мысли сменилось. Я в целом вообще теперь не вижу смысла особо писать код руками, хотя ещё неделю назад был уверен, что навык это важный (ну он и всё ещё важный, так или иначе. Я бы опустил рандомного сеньора, который почему-то разучился этим заниматься. Но, кажется, на хорошем наборе примеров я понял всех важных дядек из всех больших компаний).
Человек трудящийся уходит в прошлое. В дело вступает человек думающий. У разработчика без глубокой картины происходящего, с узким кругозором, и агент будет использоваться кустарно, чтобы подпереть да подкрутить. Если вы найдёте способы и силы развиваться качественно в текущих условиях, вы не то чтобы станете легитимными 10х, но и всеми 228х разработчиками.
Качайтесь и читайте Антона: @itpgchannel.
@thisnotes. Patreon, newsletter.
Спасибо Artyom Garkavy и niki4smirn.
Хотите advent about bad parts стандартной библиотеки в декабре? Если хотите, тыкайте 🌚. Если нет: 🗿.
🌚67👍15🗿3❤1🤔1🤪1