Loser story
В общем я тут побывал на собесах, что спрашивали: много всего про плюсы, найти среднее на slice window, бинпоиск, про вертикальную ось симметрии на Z^2, была задача на дизайн сервиса для подсказок пользователю текста на основе уже введённой строки и баунд…
В общем пишу про работу тут, в целом почти все над чем я работал, особенно после стажки было очень интересным, например почти весь последний год писал новый рендер картографии, где-то даже успели на него перейти уже, а с декабря делал (уже не один правда) рендер погоды. Немного обидно что у нас не опенсурс, я бы хотел посмотреть что там дальше будет.
В целом было классно, пожалуй главные минусы лично для меня это зарплата, ну и немного раздражало отсутствие экспертизы, и при этом завышенное чсв у некоторых коллег, но наверное неприятные коллеги могут быть везде, в основном все нормальные были.
В мейле буду писать с нуля рендер тайловых карт (open street map формат, опенсурс аналоги mapbox gl native, omim), правда тут уже на vulkan и metal. Кажется я первый чел которого они набрали в команду рендера, так что мб если знаете кого-то кому интересно, говорили будут ещё набирать. Немного стремно прям совсем с нуля проект, на старой работе было хотя бы все вокруг рендера, но думаю все получится, да и в целом очень интересный опыт.
В целом было классно, пожалуй главные минусы лично для меня это зарплата, ну и немного раздражало отсутствие экспертизы, и при этом завышенное чсв у некоторых коллег, но наверное неприятные коллеги могут быть везде, в основном все нормальные были.
В мейле буду писать с нуля рендер тайловых карт (open street map формат, опенсурс аналоги mapbox gl native, omim), правда тут уже на vulkan и metal. Кажется я первый чел которого они набрали в команду рендера, так что мб если знаете кого-то кому интересно, говорили будут ещё набирать. Немного стремно прям совсем с нуля проект, на старой работе было хотя бы все вокруг рендера, но думаю все получится, да и в целом очень интересный опыт.
Loser story
Вы никогда не задумывались над такой штукой: часто бывает в плюсах, что некоторые объекты создаются только как указатель в куче, и иногда такие объекты содержат массив фиксированного, но к сожалению известного только в рантайме размера, в таком кейсе вообще…
В общем история имеет продолжение, в llvm существует класс реализующий такой паттерн:
https://llvm.org/doxygen/TrailingObjects_8h.html
Сама идея тривиальна, давайте вместо аллокации под структуру с указателями и отдельными аллокациями на каждый массив сделаем одну большую аллокацию под все массивы + структуру.
Получим 1 аллокацию вместо н + 1, плюс уменьшаем уровень косвенности для доступа к массивам. В llvm написали обертку за которой скрыли вычисления размера аллокации и соответственно адреса по которым валидно обращаться, с учётом выравнивания.
В си для одного массива такое сделать попроще, называется flexible array member.
Лично я к сожалению костылил для одного конкретного кейса такое и не делал общего паттерна, круто если кто-то знает/сделает хорошую опенсурс мит реализацию, мне кажется довольно популярный и красивый кейс.
https://llvm.org/doxygen/TrailingObjects_8h.html
Сама идея тривиальна, давайте вместо аллокации под структуру с указателями и отдельными аллокациями на каждый массив сделаем одну большую аллокацию под все массивы + структуру.
Получим 1 аллокацию вместо н + 1, плюс уменьшаем уровень косвенности для доступа к массивам. В llvm написали обертку за которой скрыли вычисления размера аллокации и соответственно адреса по которым валидно обращаться, с учётом выравнивания.
В си для одного массива такое сделать попроще, называется flexible array member.
Лично я к сожалению костылил для одного конкретного кейса такое и не делал общего паттерна, круто если кто-то знает/сделает хорошую опенсурс мит реализацию, мне кажется довольно популярный и красивый кейс.
Блин все эти переименования чатов, жесть, я чуть не вышел с парочки на автомате
Вот знаете на прошлой работы мы писали свой тредпул, таски, таймеры, стренды, ну вы поняли, а для io просто заводили тредпул с asio event loop-ами, благо буст был.
Но в целом я сторонник того, чтобы взять готовое, но я тут подумал, что мне ничего в голову подходящего не приходит, asio плох для cpu bounded задач, по крайне мере, когда мы меряли было хуже нашей поделки.
folly здоровый пиздец и под android/ios наверно умру тащить, да и нужно оттуда совсем немного.
Плюс мы отказались от буста, интересно кст отдельно асио так то тоже не мелкий ну да не важно.
А tbb вроде без io bounded, да и мне не нравится. Не люблю эти task graph/flow like либы, стремная какая-то штука у кого-то был крутой опыт использования или ссылочка на рассказ как круто?
Но в целом я сторонник того, чтобы взять готовое, но я тут подумал, что мне ничего в голову подходящего не приходит, asio плох для cpu bounded задач, по крайне мере, когда мы меряли было хуже нашей поделки.
folly здоровый пиздец и под android/ios наверно умру тащить, да и нужно оттуда совсем немного.
Плюс мы отказались от буста, интересно кст отдельно асио так то тоже не мелкий ну да не важно.
А tbb вроде без io bounded, да и мне не нравится. Не люблю эти task graph/flow like либы, стремная какая-то штука у кого-то был крутой опыт использования или ссылочка на рассказ как круто?
А никто не помнит названия сайта, который выглядел, как цветные соты (6 угольники) подписанные темами в алгоритмах, например, жадники, дфс, снм. При нажатии на соту выдавало список задач на тему.
Хотел скинуть ссылку, но не смог вспомнить название.
Хотел скинуть ссылку, но не смог вспомнить название.
Я тут оподливился в ишью, но зато понял как расставить порядки слабее, в одном месте + их идею с active/inactive.
https://github.com/facebookexperimental/libunifex/issues/267
А в целом алгоритм такой "очереди" мне очень нравится, он кст довольно популярен, можно встретить в бусте и перфбуке например.
https://github.com/facebookexperimental/libunifex/issues/267
А в целом алгоритм такой "очереди" мне очень нравится, он кст довольно популярен, можно встретить в бусте и перфбуке например.
GitHub
Explain memory_order for atomic_intrusive_queue · Issue #267 · facebookexperimental/libunifex
Hi there are memory_orders chosen for this data structure, but it is not very clear how some of them were chosen. There is no release here, why? https://github.com/facebookexperimental/libunifex/bl...
У меня возле старого дома, ходят трамваи, так вот раньше я их не любил громко, медленно, древние седушки как мир, сейчас еду на новом и збс
https://golang.org/src/sync/mutex.go?#L80 кст мне тут показывали прикольную, видимо оптимизацию, в golang.
Кажется в таком коде компилятору достаточно просто заинлайнить вызов lock. И тогда, если нам удастся сразу захватить лок, то не будет call(jmp) к коду, который загружен в какую-то жопу.
Кажется в таком коде компилятору достаточно просто заинлайнить вызов lock. И тогда, если нам удастся сразу захватить лок, то не будет call(jmp) к коду, который загружен в какую-то жопу.
Почему в типо ресторанах (ну в каких-то дорогих я не бываю) всегда салаты странные? Ну то есть порезаны как то крупно обычно. Может мне кажется конечно
Я тут задумался насколько компании выгодно хорошее код ревью?
Тут стоит уточнить, что в тех местах где я работал на ревью обычно смотрят на плюсовую составляющую кода, если повезёт на многопоточность или алгоритмы, тут зависит от компетенции ревьювера.
Но в целом, особенно учитывая что я работаю в графике и не в геймдеве, лично у меня все как-то грустно.
Но даже если не брать в расчет мою специфику и посмотреть на другие пр, да и на тот же опенсурс, не редки случаи, когда максимум, что напишут в ревью, это какие то языковые нюансы, которые ты мог упустить случайно.
Ну это помимо кодстайла и очевидных багов/недостатков.
И мне вот интересно если в ревью выставлять теги и требовать апрувы по конкретным темам, типо язык программирование, многопточность, етс. Это будет явно больше и сложнее с точки зрения организации. Но будет ли это профитнее?
Тут стоит уточнить, что в тех местах где я работал на ревью обычно смотрят на плюсовую составляющую кода, если повезёт на многопоточность или алгоритмы, тут зависит от компетенции ревьювера.
Но в целом, особенно учитывая что я работаю в графике и не в геймдеве, лично у меня все как-то грустно.
Но даже если не брать в расчет мою специфику и посмотреть на другие пр, да и на тот же опенсурс, не редки случаи, когда максимум, что напишут в ревью, это какие то языковые нюансы, которые ты мог упустить случайно.
Ну это помимо кодстайла и очевидных багов/недостатков.
И мне вот интересно если в ревью выставлять теги и требовать апрувы по конкретным темам, типо язык программирование, многопточность, етс. Это будет явно больше и сложнее с точки зрения организации. Но будет ли это профитнее?
Как вы проводите ревью? (Забыл написать если вы не программист, или возможно не участвовали ни в каких проектах, голосуйте только результаты)
Anonymous Poll
19%
Не провожу
13%
Баги/фичи языка, поверхносто
20%
Вникаю в то что делает код, в 1/3 пр
11%
2/3
4%
99%
9%
Ревьювю пр в код который писал сам/очень хорошо знаком
43%
Результаты
Loser story
В общем пишу про работу тут, в целом почти все над чем я работал, особенно после стажки было очень интересным, например почти весь последний год писал новый рендер картографии, где-то даже успели на него перейти уже, а с декабря делал (уже не один правда)…
Собственно по поводу работы в мейле, я тут сейчас один над рендером работаю. И хоть на сайте нет вакансии, на самом деле она есть. Поэтому если вы/у вас есть знакомые на мидл-сеньор позицию заинтересованные, пишите расскажу подробнее и прорекомендую вероятно.
Я тут дочитал классный блог, думаю стоит рассказать, вот посты, которые мне показались наиболее интересные:
1. https://travisdowns.github.io/blog/2019/06/11/speed-limits.html про ограничения скорости исполнения программы на уровне железа, оно конечно не совсем применимо для большинства, но очень любопытно
2. https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.htmlдля тех кто не читает, то что я кидаю в общем немного про то как считать счётчики конкурентно, и в целом как понять что твой конкурентный код хорош вообще про это все более подробно можно почитать в perfbook, может быть теперь вы наконец-то решите его прочесть
3. https://travisdowns.github.io/blog/2020/05/13/intel-zero-opt.html прикольный эффект с заполнением нулями
4. https://travisdowns.github.io/blog/2019/08/20/interrupts.html Когда именно происходят прерывания? Вопрос интересен даже без полноценного ответа
В целом есть ещё интересные посты, но они наверняка вам в том или ином виде знакомы ('\0' vs 0, strict aliasing, порядок инклудов, етс. Если нет, читайте). Часть же постов немного специфична, в основном про avx512, не думаю что многим оно будет интересно
1. https://travisdowns.github.io/blog/2019/06/11/speed-limits.html про ограничения скорости исполнения программы на уровне железа, оно конечно не совсем применимо для большинства, но очень любопытно
2. https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html
3. https://travisdowns.github.io/blog/2020/05/13/intel-zero-opt.html прикольный эффект с заполнением нулями
4. https://travisdowns.github.io/blog/2019/08/20/interrupts.html Когда именно происходят прерывания? Вопрос интересен даже без полноценного ответа
В целом есть ещё интересные посты, но они наверняка вам в том или ином виде знакомы ('\0' vs 0, strict aliasing, порядок инклудов, етс. Если нет, читайте). Часть же постов немного специфична, в основном про avx512, не думаю что многим оно будет интересно
Performance Matters
Performance Speed Limits
A laundry list of speed limits that your code can’t exceed.