Just.Doit

Оверхед большой. И оптимизацию ломает очень сильно. В чем блять оверхуед Ranged это пойнтер + размер или я что-то не понимаю? https://en.cppreference.com/w/cpp/ranges https://youtu.be/cK4cMdx9QeQ?si=qjvBlzLRW4Ll6hcH&t=2375 Проще так. Поинтер + размер это спан. Алсо чет вголос как вебер познает статическую типизацию Ребята из стандарта опять сделали тормозную неюзабельную хуйню ради красивых абстракций. Никогда такого не было и вот опять (привет strstream или unordered_set, регулярные выражения тихо плачут в сторонке). Одна надежда на оптимизации компилятором чел, ты свой нишевый кейс апроксимируешь на все юзкейсы с++ ты сам скидывал что у гугла есть обычный стайлгайд по плюсам где многое разрешено, а есть отдельный для хрома я готов ставить что количество человек которые пользуются первым раз в 10 больше, а то и в 100 соответственно схерали ты свое нишевое видение хочешь затащить в стандарт? для многих поддерживаемый код (за счет красивых абстракций в том числе) гораздо важнее чем 0-оверхед код

это как раз заслуга хорошей системы типов + того что стд и либы написаны так что используют эту систему типов что это значит? мне казалось что енамы это супер изи везде

это ты про раст? лул ну да, не про джс же тебя хорошая система типов так впечатлила? или ФПшные штуки типа рекордов и ошибки через резалт тайп?

это ты про раст? лул

Разве тема репликации и распределенных данных не сложнее? а вопрос перфоманса? может быть сидя с профилирощоком и зная текущий "bottle neck" не можешь родить, а что же сделать что бы отрабатывало условно не 7 а 3 сек. хотя с современными оптимизациями jit компиляторами такого быть не должно, да? чел время работы кода в этих 7-3 секундах поярдка <1% у тебя там ио ебаное (только если ты не делаешь числодробилку на jit-языке - тогда тебе язык надо менять епта) Разве тема репликации и распределенных данных не сложнее? ну это дизайн систем, инфраструктура. да но разраб то задачи решает а не просто код строчит так что это его прямая обязанность в этом шарить а вот в многопоточке скорее наоборот, хорошо если базу знаешь

Ок ты поймал меня Поздравляю В любом случае автору презентации стоило бы показывать код КОТОРЫЙ ВОСПРОИЗВОДИТСЯ А не В ТЕОРИИ МОЖЕТ ВОСПРОИЗВЕСТИСЬ на никогда не существовавших архитектурах ну в репозитории у него вот есть же пример с 2 потоками все тоже самое и воспроизводится ну на презентации да, не самый лучший пример получился

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

где это прописано? я не вижу в мемори ордер этого там прямо написано что чтения в другом порядке возможны https://en.cppreference.com/w/cpp/atomic/memory_order memory_order_acquire A load operation with this memory order performs the acquire operation on the affected memory location: no reads or writes in the current thread can be reordered before this load. All writes in other threads that release the same atomic variable are visible in the current thread (see Release-Acquire ordering below). memory_order_release A store operation with this memory order performs the release operation: no reads or writes in the current thread can be reordered after this store. All writes in the current thread are visible in other threads that acquire the same atomic variable (see Release-Acquire ordering below) and writes that carry a dependency into the atomic variable become visible in other threads that consume the same atomic (see Release-Consume ordering below). почему на 2х потоках тогда работает по другому? в одном потоке вообще тогда должно быть что ничего не было reordered потому что там есть запрет на реордеринг после записи и запрет на реордеринг перед чтением. почему воспроизводится? Разные есть варианты почему может быть так: 1) На этапе компилятора убирается полностью чтение переменной которая в том же потоке выставлена true и полностью убирается вообще вся проверка кондишена 2) Запись просходит по схеме lazy write то есть фактический write происходит как самая последняя операция 3) Может быть чтение переменной которая в том же потоке выставлена true все же происходит но читается из локального кэша а не глобальной памяти эти все кейсы не являются реордерингом который запрещен? ок, я видимо не совсем понимаю точные формальыне определения что является реордерингом а что нет тогда вопрос почему подобных оптимизаций, которые как мы выяснили не являются реордерингом который запрещен, не может произойти в кейсе с 4 потоками?

но код с 4мя тредами не корректный ты увтерждал что "этого не может произойти", но это может произойти, просто пока не нашлось архитектуры/компилятора который бы так работал где это прописано? я не вижу в мемори ордер этого там прямо написано что чтения в другом порядке возможны более того есть перестановки на уровне процессора там 2 чтения ты можешь в рефери прочитать по 0 в кота и в панду когда никто не стартовал, и протом прочитать по 1 когда оба финишировали. и будет баг ничто не гарантирует отстутсвия данного поведения

тоесть код не корректный хотя ты говорил что "автор дурак и код будет работать корректно"

что это гарантирует? там нету "последующих" чтений, там конкрурентные чтения, порядок между ними не определен ничем кроме rel/aq семантики на одном конкретном компиляторе и на одной конкретной архитектуре кто гарантирует что этого не произойдет в других условиях? попробуй обхяснить тогда зачем их столько? почему не оставить в с++ только 2 модификатора на запись и вообще убрать все модификаторы на чтение если "И как выглядит запись с любой другой memory_order:" "И как выглядит чтение вообще с любой memory_order:" ? ты понимаешь логику почему это сущесвтует и почему ты не прав в рассуждениях на счет гарантий ордеринга?

да но как это отвечает на изначальный вопрос про то почему проблема ордеринга не может произойти с интами? очевидно что выполнение на половину это не единственный источник проблемы ордеринга

ты говорил про атомарность инта объясни плс как из "все операции с инт атомарны" -> "так что такого случая произойти не может" я до сих пор не понимаю как атомарность инта связана с выстраиванием послежовательностей чтения-записи по 2+ переменным Более того если баг не воспроизводится, это не значит что его нет про что блять и речь бы мне объясни какая часть спеки гарантирует корректное поведение и более того, объясни почему это воспроизводится на 2х потоках? ведь код корректный и бага быть не должно далее ты привел что вроде как ты написал эквивалентный код на с++ и сделал вывод что это не возможно на основе того что конкретная версия компилятора, под конкретную архитектуру содержит одинаковый код. ты можешь гарантировать что другие версии компилятора и/или под другие архитектуры всегда будут выдавать такой же идентичный код? у тебя как раз проблема в том чтобы понять что гарантий нет. даже если сейчас все реализовано так что это эквивалентные операции, это не значит что завтра не выйдем проц М1 или новая оптимизация в компиляторе/процессоре которая не будет эквивалентной. тебе просто повезло в конкретном случае и опять же, я не понимаю причем здесь инт и его атомарность вообще блять Более того. у тебя в джаве может быть код так организован (на континуациях) что выполнить код рефери будет выполнен на том же треде и в итоге у тебя баг воспроизведется более того в спеке по плюсам дословно написано > The synchronization is established only between the threads releasing and acquiring the same atomic variable. Other threads can see different order of memory accesses than either or both of the synchronized threads. там напрямую написано что баг, который ты считаешь невозможен, возможен либо я не знаю о какой-то еще фичи плюсов которая упорядочет чтения-записи этих 2х переменных (cat и panda) и гарантирует что они будут прочитаны в одинаковом порядке так что я не вижу в чем ты прав кроме того что так совпало что код который не гарантированно корректный работает корректно в текущих условиях но возможно я что-то не знаю про атомарность интов в плюсах что начинает гарантировать порядок операций в req/aq для 2+ переменных

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

возьми в прокат ченить и пойми что тебе надо

типичный представитель снг ит комьюнити я на ромире смотрю. они рассчитывают по реальной корзине и что реально люди покупают. а не по установленной покупательской корзине мужчинками в костюмах. и еще на других источниках еще раз методология у офф статистики хуйня с моей точки зрения ты ссылки скинь уже, заебал а то какой-то ромир, какие-то другие исочники что за ромир такой хотябы?

ну 8 уже высокий порог, говорю же, таргет 4% который выше чем таргет развитых стран. это как раз темп развивающихся экономик 8% очень много. насколько я понимаю это и есть та самая грань трейдоффа когда допущена повышенная инфляция в угоду более динамичной экономики во 1х инфляция мешает людям жить и вызывает недовольство во 2х я не знаю точно как влияет высокая инфляция на экономику, но очевидно что гдето есть предел после которого предприятия переходят на бартер, потому что деньги обесцениваются пока идет банковская транзакция. даже если это было бы 20%, я думаю некоторые процессы в экономике будут искажаться тк лежащие/застрявшие деньги сгорают слишком быстро. точных обоснований и исследований на эту тему я не читал все еще разгребает это дерьмо кста оу май в какой момент мы начали ограничивать платформы? я например говорил про общий вид, с учетом всех платформ а не только избранных это все хорошо но ту конкретную цифру 17-20% ты окнкретно откуда из открытых источников взял? в этом вопрос был

эта функция делает два действия, читает и пишет два действия отдельно не являются атомарными по определению, поэтому и существует специальная инструкция сами запись и чтение всегда атомарны, тк меньше них сука уже ничего просто нет ща бы в 2к24м быть нарушителем SOLID, жителям города Сумы можно солид ложен

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

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

хотя точно также можно порассуждать что какой-то клерк или программист совершит ошибку и твои 5% по вкладу превратятся в 50% и поэтому все же стоит считать мат ожидание если они равны, то это эквивалентные решения (при прочих равных) формально - точно также код после рефакторинга может зависеть внутри себя на фазу луны и ты это не воспроизведешь пока не напоришься на фазу луны в момент запуска тестов. а тест будет зеленый 27 из 28 дней это звучит немного абсурдно, и вероятность того что такой код будет написан минимально, но возможна я даже могу представить себе пример - пришел джун, и внутри функции решил замерять и залогировать время выполнения, делает это через system.time.now() и ошибся в арифмитических знаках и теперь иногда для некоторых значений часов происходит деление на ноль и бросается исключение точно также ты это хуй воспроизведешь и никогда не узнаешь без анализа кода внутри или без падения на проде раз в тысячелетие так что формально разницы я не вижу то что это на "порядок" сложнее я согласен, настолько сложнее что почти нереально множество кейсов покрыть одному человеку за вменяемое время, также как и то что проще такой код не покрывать такими тестами, а изолировать от изменений + доказывать на бумаге. либо упрощать и покрывать тестами как вон выше предлагали с моками в общем я согласен с твоими доводами с прагматической точки зрения, но не согласен с формальной

точно также "найти все граничные случаи и обработать их в тесте". "вызвать на другом потоке" это просто один из корнер кейсов контекста вызова твоей функции но как говорили выше тебе придется обдрочить весь код клоками/слипами/моками чтобы выразить эти граничные случаи в тесте.

ничего не гарантировано. даже крах всей системы рф ("падение сбера без компенсаций по вкладам) возможен с вероятностью условные 0.001% в год если мат ожидания равны - то при прочих равных это эквивалентные решения я твой тезис понял, и в целом с сутью согласен формально ты не прав. тк мат ожидание у "вклад с 5% гарантированным" ниже чем 5% потому что ничего не гарантировано (есть вероятность p != 0 что вклад просрется), а верхняя доходность вклада уже ограничена 5%

нет ты не учитываешь альтернативные издержки (термин специфический, см определние из экономики) навар происходит не там где доходность не отрицательная, а там где наибольшее мат ожидание среди доступных альтернатив условно если у тебя есть акции с мат ожиданием (с учетом инфляции) 5% годовых, а вклады дают 1% годовых то при прочих равных навариваться надо на акциях а не на депозитах и не важно выше депозиты инфляции или нет да просто я не понимаю тогда тезиса про то что там конечное количество состояний которые ты МОЖЕШЬ перебрать, но не делаешь этого для многопотока все тоже самое, просто количество комбинаций больше на "порядок" и ты их точно также можешь перебрать

да ну ты прям перебираешь все комбинации всех состояний хотябы 1 функции? тоесть если передается инт, ты перебираешь все 2^32 состояний вручную и проверяешь результат каждой? это мы мы еще даже за рамки чистых функций не вышли а также более чем 1 интовый параметр многопоточный код тоже имеет конечное количество состояний и перебрать в ты их можешь тточо также как в однопоточном коде - только в своих мечтах