Vova

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

Кто о чем, а Zалупная пидораха все мечтает о бутылке в жопе и чтобы побольше всяких мусоров было. Лучше к каждому приставить личного вертухая, было бы вообще отлично! Уже было в Симпсонах

Обменяю валюту (евро или доллар) на рубли по курсу который Гугл выдает Банковскими переводами на карту / счет Если кому интересно

Как скажешь Вы игнорируете сообщения thousand cursed enemies. Настройки

СЕЙЧАС НА СТРАНИЦЕ ВСЕГО ПОЛЬЗОВАТЕЛЕЙ: 5 (4 ПОЛЬЗОВАТЕЛЯ, 1 ГОСТЬ) Vova gerkules.xO Frost.DvX phosphorique @gerkules.xO мышь ты че зашухерился? боишься на бутылку присесть что-ли?

Это у всех такой экспириенс Теперь попробуй не траву а эмпатогены - обычный секс покажется вообще хуйней скучной Стыдно за что? Ты ебанутый? Ты ебешься ради ее удовольствия или своего???

На продоте все общее

Оверхед большой. И оптимизацию ломает очень сильно. В чем блять оверхуед Ranged это пойнтер + размер или я что-то не понимаю? https://en.cppreference.com/w/cpp/ranges

конечно, ведь Ливан 8 месяцев север Израиля не обстреливает по кд (последние месяцы совсем охуели), скорее Ливан (Хезболла) щас так говорит а нас за щооо там и до наземной операции недалеко Работайте братья Когда Израиль доберется до Стамбула может перееду к вам жить А пока ебаная пустыня не очень интересует

все продумано на 10 шагов вперед пишешь все на std::shared_ptr/mutex/map/ranges и прочих "гуглнеодобряемых" вещах. приходит менеджер и говорит что нужно оптимизировать срочно, убираешь шаред птры лишние и требуешь премию ??? профит Видимо я отстал от жизни Какая проблема у ranges? В единственной компании где я писал много c++ 90% времени занимали прыжки по виртуальным функциям и перебор древа объектов сцены Думаю это кажется совсем неочевидным что использование базовой фичи виртуальные функции может быть bottleneck'ом но тем не менее

Ты че ебанутый, он без головы Ты че доктор? Я вот много полицейских видосов из США посмотрел, там часто бывает ситуация, когда в подозреваемого негра полисмен разряжает 2 обоймы экспансивных пуль, затем надевает на него наручники и начинает оказывать первую медицинскую помощь! Приезжает скорая помощь, грузят труп в машину и везут в больницу, где уже компетентный специалист устанавливает факт смерти. Потому что в США жизнь человека - наивысшая ценность и если есть хоть малейший шанс, то надо за нее бороться. Ну и в суде чтобы не доебались, что вы рано труп перестали реанимировать. Момент когда @y6u стал лучшим ироничным юзером обойдя @Товарищ Троцкий Бля да там на каждого заложника убили уже по 1000 палестинцев И все еще идут какие-то оправдяния почему юридически все легально

Тык вот почему у меня нет секса

Не увидел @101 в видео

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

где это прописано? я не вижу в мемори ордер этого там прямо написано что чтения в другом порядке возможны 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 потому что там есть запрет на реордеринг после записи и запрет на реордеринг перед чтением. почему воспроизводится? Блять я описал выше как это может происходит с 0 перестановок В том же треде запись в кэш происходит моментально а вот из кэша в общую память видимую другим тредам происходит с опозданием

где это прописано? я не вижу в мемори ордер этого там прямо написано что чтения в другом порядке возможны 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). Когда найдется сообщите Претензия что я слелал вывод в контексте конкретных архитектур процессоров звучит сомнительно учитывая что КОНКРЕТНЫЕ АРХИТЕКТУРЫ упомянуты в моем изначальном посте

тоесть код не корректный хотя ты говорил что "автор дурак и код будет работать корректно" Я что-то утверждал только про код с 4 тредами Вы все пытаетесь меня упрекнуть тем что на 2 тредах код воспроизводится но я ничего не говорил про код с 2 тредами изначально Перестановки кода компилятором запрещены даже с acquire release семантикой как минимум в с++ это так Более того там нечего переставлять как бы Мне повезло с вероятностью 100% и уверен повезет снова на любом компиляторе и архитектуре Пока что эту хуйню с 4 тредами никто нигде не воспроизвел мне продолжает везти

Разные есть варианты почему может быть так: 1) На этапе компилятора убирается полностью чтение переменной которая в том же потоке выставлена true и полностью убирается вообще вся проверка кондишена 2) Запись просходит по схеме lazy write то есть фактический write происходит как самая последняя операция 3) Может быть чтение переменной которая в том же потоке выставлена true все же происходит но читается из локального кэша а не глобальной памяти

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

Если бы операции чтения / присвания инта могли быть выполнены на половину у нас были бы проблемы. Пример когда такое может произойти в с++ struct Big {int64_t a,b,c,d,e,f,g,h,i,... , z;}; Big A, B; ... A = B; Последнее присваивание может исполниться на половину Никак Нужно смотреть на конкретный этот код презентации и что он делает Если один поток уже увидел изменения в переменной то и последующие чтения из других потоков это изменение тоже увидят - вот и все Можно посмотреть как выглядит запись с memory_order_seq_cst: mov eax, 12345678 xchg eax, DWORD PTR z[rip] И как выглядит запись с любой другой memory_order: mov DWORD PTR z[rip], 12345678 И как выглядит чтение вообще с любой memory_order: mov eax, DWORD PTR z[rip] То есть для чтение вообще не добавляются специальных инструкций а для запили с memory_order_seq_cst добавляют инструкцию "слить кэш в общую память"

никто даже не заикнулся про атомарность речь про последовательность событий и их возможные порядки с точки зрения наблюдателя (того кто их читает) мемори ордер это про ордер, а не про атомарность Я это и говорю - речь была про последовательность событий. @Grohuf дал ссылку на read-modify-write функцию и спрашивает зачем она нужна если запись int атомарная (я не утверждал что запись int атомарная ВСЕГДА это @Grohuf сам придумал снова). НУ КАК БЫ ДАЖЕ С ЛИНЕЙНОЙ ПОСЛЕДОВАТЕЛЬНОСТЬЮ СОБЫТИЙ И АТОМАРНОЙ ЗАПИСЬЮ read-modify-write НЕ СТАНОВЯТСЯ АТОМАРНЫМИ Пруф того что по логики долбаеба из атомарности записи int должна следовать атомарность read-modify-write: @Grohuf в следующий раз тащи сразу функцию на 100 строчек обложенную мьютексами и спрашивай зачем ее сделали

эта функция делает два действия, читает и пишет два действия отдельно не являются атомарными по определению, поэтому и существует специальная инструкция сами запись и чтение всегда атомарны, тк меньше них сука уже ничего просто нет хотя ладно, мб тут напиздел, помню были проблемы если память не выровнена, но надеюсь это приветы из прошлого Не помогай вове! Я тут причем? @Kant тебе ответил долбаебу что это функция нужна уже потому что она делает ДВА ДЕЙСТВИЯ даун Даже если ты всунешь по барьеру в кажду строчку кода ДВА ДЕЙСТВИЯ не стан вдруг атомарными: int exchange(std::atomic<int>& var, int new_value) { std::atomic_thread_fence(std::memory_order_seq_cst); int old_value = var.load(); std::atomic_thread_fence(std::memory_order_seq_cst); var.store(new_value); std::atomic_thread_fence(std::memory_order_seq_cst); return old_value; } Реально уже выглядит что ты сам вообще не отдупляешь как работают барьеры памяти о которых так много говоришь.