Программирование[11]

[Just.Doit]

Vova написал 6 минут назад:

Just.Doit написал 10 минут назад:

 

Vova написал 14 минут назад:

Перестановки кода компилятором запрещены даже с acquire release семантикой как минимум в с++ это так

где это прописано?

я не вижу в мемори ордер этого

там прямо написано что чтения в другом порядке возможны

 

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 потому что там есть запрет на реордеринг после записи и запрет на реордеринг перед чтением. почему воспроизводится?

Vova написал 22 минуты назад:

Just.Doit написал 1 час назад:

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

 

Разные есть варианты почему может быть так:

 

1) На этапе компилятора убирается полностью чтение переменной которая в том же потоке выставлена true и полностью убирается вообще вся проверка кондишена

 

2) Запись просходит по схеме lazy write то есть фактический write происходит как самая последняя операция

 

3) Может быть чтение переменной которая в том же потоке выставлена true все же происходит но читается из локального кэша а не глобальной памяти

эти все кейсы не являются реордерингом который запрещен?

ок, я видимо не совсем понимаю точные формальыне определения что является реордерингом а что нет

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

[Vova]

Just.Doit написал 12 минут назад:

Vova написал 21 минуту назад:

Just.Doit написал 24 минуты назад:

 

Vova написал 28 минут назад:

Перестановки кода компилятором запрещены даже с acquire release семантикой как минимум в с++ это так

где это прописано?

я не вижу в мемори ордер этого

там прямо написано что чтения в другом порядке возможны

 

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 перестановок

 

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

Изменено 12 июня пользователем Vova

[Just.Doit]

Vova написал 23 минуты назад:

Претензия что я слелал вывод в контексте конкретных архитектур процессоров звучит сомнительно учитывая что КОНКРЕТНЫЕ АРХИТЕКТУРЫ упомянуты в моем изначальном посте

ты про это?

ну ты привел лишь что "инт атомарны" и "на всех современных процессорах инты атомарны"

как из этого следует что ты говорил только про современные процессоры в контексте "такого случиться не может"

более того ты привел лишь то что инт атомарен на современных процессорах.

ничего не гвоорилось про то что невозможно нарушение порядка по причине других оптимизаций

 

твой тезис дословно следующий "это невозможно потому что инт атомарен, а инт атомарен (на всех современных процессорах) потому что цитата"

у тебя даже в рассуждениях нарушение логики

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

 

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

уже это не логично

 

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

 

Изменено 12 июня пользователем Just.Doit

[Vova]

Just.Doit написал 7 минут назад:

твой тезис дословно следующий "это невозможно потому что инт атомарен, а инт атомарен (на всех современных процессорах) потому что цитата"

у тебя даже в рассуждениях нарушение логики

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

 

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

уже это не логично

 

Ок ты поймал меня

 

Поздравляю

 

В любом случае автору презентации стоило бы показывать код КОТОРЫЙ ВОСПРОИЗВОДИТСЯ

 

А не В ТЕОРИИ МОЖЕТ ВОСПРОИЗВЕСТИСЬ на никогда не существовавших архитектурах

Изменено 12 июня пользователем Vova

[scarppy]

вова пососал

джаст ду ит как всегда утёр нос хейтерам

[Just.Doit]

Vova написал 18 часов назад:

Just.Doit написал 18 часов назад:

твой тезис дословно следующий "это невозможно потому что инт атомарен, а инт атомарен (на всех современных процессорах) потому что цитата"

у тебя даже в рассуждениях нарушение логики

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

 

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

уже это не логично

 

Ок ты поймал меня

 

Поздравляю

 

В любом случае автору презентации стоило бы показывать код КОТОРЫЙ ВОСПРОИЗВОДИТСЯ

 

А не В ТЕОРИИ МОЖЕТ ВОСПРОИЗВЕСТИСЬ на никогда не существовавших архитектурах

 

ну в репозитории у него вот есть же пример с 2 потоками

все тоже самое и воспроизводится

ну на презентации да, не самый лучший пример получился

Изменено 13 июня пользователем Just.Doit

[faceles5]

Arzanis написал 05.06.2024 в 20:54:

faceles5 написал 31.05.2024 в 14:59:

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

Надеюсь ты доволен. 
Рассорил крестовичков.
 

да я забыл, что мы на дотерском форуме . Впрочем, взрослые люди умеют вести полемику, а тут просто цирк развели, ну да ладно

p.s. с другой стороны "в споре рождается истина, в нем же и умирает", но не в этом 

p.s.s кста камунити от души за ответы, все равно было интересно почитать ваши рассуждения холивар

Изменено 14 июня пользователем faceles5

[Olololnet]

faceles5 написал 1 час назад:

Arzanis написал 05.06.2024 в 20:54:

faceles5 написал 31.05.2024 в 14:59:

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

Надеюсь ты доволен. 
Рассорил крестовичков.
 

да я забыл, что мы на дотерском форуме . Впрочем, взрослые люди умеют вести полемику, а тут просто цирк развели, ну да ладно

p.s. с другой стороны "в споре рождается истина, в нем же и умирает", но не в этом 

p.s.s кста камунити от души за ответы, все равно было интересно почитать ваши рассуждения холивар

 

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

[GoldRobot]

Olololnet написал 54 минуты назад:

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

На самом деле тут нечего доказывать.

Аксиома следующая:

* все в топике програмирования - подмножество группы ебланы;

* самый крутой - суез.

Изменено 14 июня пользователем GoldRobot

[Grohuf]

Olololnet написал 3 часа назад:

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

Разве тема репликации и распределенных данных не сложнее?

[faceles5]

Grohuf написал 26 минут назад:

Olololnet написал 3 часа назад:

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

Разве тема репликации и распределенных данных не сложнее?

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

Изменено 14 июня пользователем faceles5

[GoldRobot]

faceles5 написал 9 минут назад:

а что же сделать что бы отрабатывало условно не 7 а 3 сек. хотя с современными оптимизациями jit компиляторами такого быть не должно, да?

все продумано на 10 шагов вперед

пишешь все на std::shared_ptr/mutex/map/ranges и прочих "гуглнеодобряемых" вещах.

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

???

профит

[Grohuf]

GoldRobot написал 19 минут назад:

faceles5 написал 30 минут назад:

а что же сделать что бы отрабатывало условно не 7 а 3 сек. хотя с современными оптимизациями jit компиляторами такого быть не должно, да?

все продумано на 10 шагов вперед

пишешь все на std::shared_ptr/mutex/map/ranges и прочих "гуглнеодобряемых" вещах.

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

???

профит

Ну, как я уже говорил, коллеге пришлось делать патч в LLVM, ибо переписывать дерьмо других "коллег" - долго + они как владельцы могут быть возмущены обилием платформозависимого кода. Так что не всегда можно удалить тормозное std-шное говно из кода.

faceles5 написал 30 минут назад:

Grohuf написал 53 минуты назад:

Olololnet написал 4 часа назад:

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

Разве тема репликации и распределенных данных не сложнее?

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

Хуйня это. Профилируешь, находишь медленные участки, думаешь как ускорить. Иногда для того, чтобы раза в 2-3 ускорить стажерское гугловое говно особо напрягаться не надо. Достаточно вспомнить задачки с собеседований.

Изменено 14 июня пользователем Grohuf

[Olololnet]

Grohuf написал 1 час назад:

Olololnet написал 4 часа назад:

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

Разве тема репликации и распределенных данных не сложнее?

ну это дизайн систем, инфраструктура. 

[Just.Doit]

faceles5 написал 1 час назад:

Grohuf написал 2 часа назад:

Olololnet написал 5 часов назад:

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

Разве тема репликации и распределенных данных не сложнее?

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

 

чел

время работы кода в этих 7-3 секундах поярдка <1%

у тебя там ио ебаное

(только если ты не делаешь числодробилку на jit-языке - тогда тебе язык надо менять епта)

Olololnet написал 34 минуты назад:

Grohuf написал 2 часа назад:

Olololnet написал 5 часов назад:

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

Разве тема репликации и распределенных данных не сложнее?

ну это дизайн систем, инфраструктура. 

да

но разраб то задачи решает

а не просто код строчит

так что это его прямая обязанность в этом шарить

а вот в многопоточке скорее наоборот, хорошо если базу знаешь

 

Изменено 14 июня пользователем Just.Doit

[Olololnet]

Just.Doit написал 19 минут назад:

но разраб то задачи решает

а не просто код строчит

я запишу эту мудрость

[Tia]

писал фронт на джсе последние лет 5, тут по одной задаче понадобилось утилиты с бэка на фронте заюзать

посмотрел че к чему там в wasm, понял что надо на расте мутить, тем более часть утилок на расте написана

порешал там пару задач на литкоде чтобы в язык вкатиться +-

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

 

[Vova]

GoldRobot написал 7 часов назад:

faceles5 написал 7 часов назад:

а что же сделать что бы отрабатывало условно не 7 а 3 сек. хотя с современными оптимизациями jit компиляторами такого быть не должно, да?

все продумано на 10 шагов вперед

пишешь все на std::shared_ptr/mutex/map/ranges и прочих "гуглнеодобряемых" вещах.

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

???

профит

 

Видимо я отстал от жизни

 

Какая проблема у ranges?

 

В единственной компании где я писал много c++ 90% времени занимали прыжки по виртуальным функциям и перебор древа объектов сцены

 

Думаю это кажется совсем неочевидным что использование базовой фичи виртуальные функции может быть bottleneck'ом но тем не менее

[GoldRobot]

Vova написал 33 минуты назад:

Видимо я отстал от жизни

Какая проблема у ranges?

Оверхед большой. И оптимизацию ломает очень сильно.

[Vova]

GoldRobot написал 2 минуты назад:

Vova написал 36 минут назад:

Видимо я отстал от жизни

Какая проблема у ranges?

Оверхед большой. И оптимизацию ломает очень сильно.

 

В чем блять оверхуед

 

Ranged это пойнтер + размер или я что-то не понимаю?

 

https://en.cppreference.com/w/cpp/ranges