Тёмная тема
- samrrr
- Забанен
=A=L=X=
> типа ручных велосипедов на атомиках
Вообщето барьеры нужны когда ты хочешь получить большую скоросто чем с атомиками. Что для медленного паскаля совсем неважно.
samrrr
> Вообщето барьеры нужны когда ты хочешь получить большую скоросто чем с
> атомиками. Что для медленного паскаля совсем неважно.
лол. брал бы выше: "паскаль и так тормозной, барьеры ему не помогут" xD
skalogryz
> лол. брал бы выше: "паскаль и так тормозной, барьеры ему не помогут" xD
ему и кресты не помогут.
samrrr
> Вообщето барьеры нужны когда ты хочешь получить большую скоросто чем с
> атомиками.
Предположим ты через атомик охраняешь какой то ресурс, поменял его и "разлочил" атомик. Этого достаточно или нужно еще кое в чём убедиться?
Ой, точно, до "разлока" нужно же еще барьер вставить чтобы не словить нежданчика.
Нашел какие-то примеры с префетчем, правда не на Паскале. Небольшой тест, взятый с примеров в конце статьи показал, что фишка бесполезна чуть более, чем полностью:
То есть, никакого эффекта даже с явным выравниванием). Где-то еще читал, что современные процессоры уже на аппаратном уровне префетчат все, что только можно, поэтому заюзав Prefetch в лучшем случае можно добиться нулевого эффекта, а в худшем даже падения производительности). Но все еще не покидает надежда, что какой-то один процент задач все же может быть оптимизирован хотя бы на 10-20%.
Странно что даже в древнем Фортране есть интринсики префетчинга).
Ну а насчет барьеров я заодно и спросил, так как документации также нет внятной, ну и примерчики не помешали бы какие-то, хотя бы что-то подобное из приведенного мною выше.
skalogryz
> лол. брал бы выше: "паскаль и так тормозной, барьеры ему не помогут" xD
А я так и написал же.
=A=L=X=
> Предположим ты через атомик охраняешь какой то ресурс, поменял его и "разлочил"
> атомик. Этого достаточно или нужно еще кое в чём убедиться?
> Ой, точно, до "разлока" нужно же еще барьер вставить чтобы не словить
> нежданчика.
Атомики реализуются через барьеры. Каждый позыв атомика это барьеры. По крайней мере в С++ так.
ArtProg
> Ну а насчет барьеров я заодно и спросил, так как документации также нет
> внятной
Барьеры нужны для настоящих джедаев. Для тех, кто реально знает что делает этот самый барьер.
https://en.cppreference.com/w/cpp/atomic/atomic_thread_fence
samrrr, спасибо за ссылку!
ArtProg, обсуждали уже здесь, даже ссылки с информацией есть.
samrrr
> Атомики реализуются через барьеры. Каждый позыв атомика это барьеры. По крайней
> мере в С++ так.
В машкоде это просто разные вещи и в плюсах их смешали просто для удобства.
ArtProg
> Небольшой тест, взятый с примеров в конце статьи показал, что фишка бесполезна чуть более, чем полностью
Фишка полезная, если применять ее с умом. Вот мы тут экспериментировали.
У интела в оптимизейшон гвайде написано, что "софтварный" префетч может помогать если не справляется аппаратный дедуктор.
А не справляться он может в случае систематического, но хаотически выглядящего доступа к памяти.
Бесполезно улучшать так линейный допустим проход. Или даже два прохода подряд.
И да, главное что префетч должен быть сделан сильно загодя до того места где линейка кеша уже будет нужна и даже определение этого момента (или смещения предвыборки) - задача которую надо оптимизировать наживую на конкретной машине в конкретных условиях и нагрузке.
}:+()___ [Smile]>Вот мы тут экспериментировали.
Читал кстати, интересная тема. Пробовал на Паскале в Лазарусе ставить разные смещения к данным в той же Radix-сортировке, но толку было ноль.
Остальные ссылки читал, но без реально работающих примеров сложно понять, где именно Prefetch используется на Паскале также эффективно как и на C++ с его интринсиками.
Вобщем попробую еще поэкспериментировать со смещениями.
=A=L=X=
> В машкоде это просто разные вещи
https://github.com/microsoft/STL/blob/main/stl/inc/atomic#L171
Ну в коде стд это 2 барера вокруг вызова атомика. А теперь гони свои пруфы, если они у тебя есть.
samrrr
> А теперь гони свои пруфы, если они у тебя есть.
На x86 атомики это либо инструкции процессора снабжённые префиксом LOCK либо специфичные инструкции которые автоматически вменяют LOCK.
Например https://c9x.me/x86/html/file_module_x86_id_41.html
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.
Но как я выше писал это не гарантирует проблем с reordering само по себе - нужны барьеры.
И как нетрудно догадаться барьеры это тоже отдельные инструкции процессора, например https://mudongliang.github.io/x86/html/file_module_x86_id_170.html
Performs a serializing operation on all load-from-memory and store-to-memory instructions that were issued prior the MFENCE instruction. This serializing operation guarantees that every load and store instruction that precedes in program order the MFENCE instruction is globally visible before any load or store instruction that follows the MFENCE instruction is globally visible.
Это совершенно разные вещи как видно, но то, что их употребляют часто рядом в коде это не удивительно, а логично, ибо как я писал на прошлой странице:
Предположим ты через атомик охраняешь какой то ресурс, поменял его и "разлочил" атомик. Этого достаточно или нужно еще кое в чём убедиться?
Ой, точно, до "разлока" нужно же еще барьер вставить чтобы не словить нежданчика.
Это и лежит в основании того, что в плюсах атомики плотно связаны с барьерами, хотя можно указать ::none или как то так и никаких барьеров не будет.
С другой стороны до атомиков в стандарте всё это уже давно было нужно и обходились или ассемблерными вставками или https://docs.microsoft.com/en-us/cpp/intrinsics/readbarrier?view=msvc-170