M
Вроде расстановки барьеров lfence/mfence по коду
SIMD инструкции требуют синхронизации?)
Size: a a a
2020 May 18
PK
MaxGraey
SIMD инструкции требуют синхронизации?)
При чем тут симд и параллелизм уровня повыше? В одном треде можно как угодно симдом пользоваться, тут же не про это речь?
AS
М. x86 (и все остальные, емнип) гарантирует отсутствие word tearing только на уровне байтов. Если нужно писать отдельные биты в байте без word tearing'a, то придётся синхронизироваться.
PK
М. x86 (и все остальные, емнип) гарантирует отсутствие word tearing только на уровне байтов. Если нужно писать отдельные биты в байте без word tearing'a, то придётся синхронизироваться.
Ага!
AS
Это довольно частое недоумение, поэтому я давеча целую врезку написал вот здесь: https://shipilev.net/jvm/objects-inside-out/#_data_types_and_their_representation
МБ
М. x86 (и все остальные, емнип) гарантирует отсутствие word tearing только на уровне байтов. Если нужно писать отдельные биты в байте без word tearing'a, то придётся синхронизироваться.
Так данные так разложены в памяти, что биты лежат отдельно. Например, первые биты лежат в одном массиве, а вторые в другом.
AS
Кхм. Ну, при таком определении "битов", да, конечно. Я-то думал, разговор про доступ к "первым"/"вторым" битам в конкретном машинном слове.
AD
Так данные так разложены в памяти, что биты лежат отдельно. Например, первые биты лежат в одном массиве, а вторые в другом.
тогда достаточно посчитать число нулевых бит в первом массиве, во втором и т.д.
AD
вырожденный случай сортировки подсчётом же, не?
AD
если я не ошибаюсь, тогда даже хранить сами биты не нужно
PK
тогда достаточно посчитать число нулевых бит в первом массиве, во втором и т.д.
Это в одну инструкцию делается, кстати
AD
Это в одну инструкцию делается, кстати
не везде есть эта инструкция
PK
не везде есть эта инструкция
Не везде и float есть)
PK
Так данные так разложены в памяти, что биты лежат отдельно. Например, первые биты лежат в одном массиве, а вторые в другом.
Ну и чтобы избегать false sharing, надо будет читать в память кешлайн, в котором ничего кроме этих "битов" нет, -- это неэффективно, когда тут разговоры о таком алгоритме
МБ
тогда достаточно посчитать число нулевых бит в первом массиве, во втором и т.д.
Ну... Это ж примитивный пример. В обработке сигналов есть более хитрые представления. Я, правда, не энаю, этотли самое имел в виду Пётр.
PK
Ну или к данными клеить их, разбивать их на buckets... Чем дальше в лес, тем толще партизаны
AD
Ну... Это ж примитивный пример. В обработке сигналов есть более хитрые представления. Я, правда, не энаю, этотли самое имел в виду Пётр.
не, ну так не честно) почти всегда есть случай, когда контр-интуитивный вариант будет оптимальным)
МБ
Ну и чтобы избегать false sharing, надо будет читать в память кешлайн, в котором ничего кроме этих "битов" нет, -- это неэффективно, когда тут разговоры о таком алгоритме
Ну и закэшлайните Вы себе сразу 512 битов. Хорошо же.
AD
Ну и закэшлайните Вы себе сразу 512 битов. Хорошо же.
видимо речь о том, где результаты подсчета хранить
PK
Но я так понял, реализацию этих алгоритмов никто не продумывает серьезно, и это чисто теоретические выкладки?